Sent i 2012 modtog mobilplatformstrateg Peter-Paul Koch sponsorering for QuirksMode.org, som han sagde ville sætte ham i stand til at bruge mere tid på at undersøge webstandarder og arbejde på kompatibilitetstabeller, der ville blive delt med webplatform.org.
I løbet af weekenden gik CSS-vælgere til mobilborde live. Koch har også undersøgt CSS-kolonner yderligere og opdaget, at der er nogen vej at gå med hensyn til implementering.
Vi talte med Koch om hans arbejde, hvordan hans tests skrives, og hvorfor udviklere bør være mere forsigtige med hensyn til test på motorbasis.
.net: Du lægger en stor indsats i dine mobilborde. Er dette noget, der ikke blev gjort i denne udstrækning andre steder?
PPK: Nej, det gøres ikke rigtig. Tabellerne der kommer tættest på mine er dem af Max Firtman, og de fokuserer på HTML5 API'er.
Jeg tror ikke på at automatisere browsertest eller scoringer, og derfor tæller jeg ikke rigtig tests som HTML5-testen. Så har vi Can I Use…, hvilket er nyttigt, men sommetider ikke giver korrekt browserinformation.
Så vidt jeg ved, er jeg stadig den, der udfører de mest detaljerede tests - og den eneste, der udgiver testsider såvel som resultater.
.net: Hvordan går du hen til at skrive testene?
PPK: Langsomt! Nogle gange er det ikke let at finde ud af, hvad der menes i en specifikation, især når der kun er to implementeringer, der subtilt (eller vildt) er forskellige. Heldigvis har jeg stor erfaring med browser-testskrivning, og så ved jeg, hvordan man kan forhindre almindelige faldgruber.
For eksempel så det først ud som om Opera Mini ikke understøttede CSS-klasser, men det er naturligvis vrøvl. Problemet viste sig at være, at jeg tester for støtte fra klasser ved at give et testelement font-stil: kursiv. Mange Opera Minis understøtter ikke den stil. Fordi jeg havde stødt på dette før, vidste jeg, at jeg var nødt til at ændre testformat. Og MeeGo-browseren understøtter ikke font-variant: små bogstaver. Samme historie.
I øvrigt giver JavaScript stadig kursiv når du beder Opera Mini om skrifttype værdi. Det beviser, at du ikke kan automatisere disse tests: du skal se på siden og afgøre, om den bruger en kursiv skrifttype.
.net: I din seneste artikel om vælgere og kolonner angiver du, at browsere, der bruger den samme WebKit-build, har varierende kompatibilitet. Fremhæver dette yderligere, hvordan devs skal være forsigtige med hensyn til banebrydende teknikker og mere strengt teste på tværs af enheder?
PPK: Yup. Der er ingen WebKit på mobil. Der er mindst tolv forskellige browsere (undtagen versioner, der bruger WebKit som deres gengivelsesmotor), men de ligner ikke nødvendigvis hinanden.
Det bedste eksempel er -webkit-kolonne-span-erklæring. Det viser sig, at WebKit droppede support for nylig. Dette er det mærkeligste kompatibilitetsproblem, jeg nogensinde har stødt på, fordi det ikke er muligt at binde support til specifikke WebKit-versioner. Så support til denne erklæring er et rod, og det faktum, at en browser bruger WebKit, siger nøjagtigt ingenting.
