INNSIKT: Lover å bedre nettleser­kompatibiliteten [Ekstra]

[Harald Brombach (digi.no)]

INNSIKT: Lover å bedre nettleser­kompatibiliteten [Ekstra]

[eloekset]

Omtalene har alltid vært at Edge gjør ting feil og Chrome gjør alt riktig. Webutviklerne har seg selv å takke for at Chromium nå i praksis har monopol på weben.

[Rune Lillesveen]

Det er ingen browsere som gjør det korrekt i forhold til spec, så vidt jeg kan se, men Firefox er nærmest.

outline-013.html til outline-016.html her tester negativ outline-offset: 

https://wpt.fyi/results/css/css-ui?label=experimental&label=master&aligned

[Rune Lillesveen]

Fikser Chrome her: https://chromium-review.googlesource.com/c/chromium/src/+/2283584

[tjavel]

Det er nesten litt skandale at Opera og Microsoft måtte gi opp browser motorene på grunn av at for mye vedlikhold å være kompatibel med websider - som først og fremst da er kompatible med Chrome.

Web-standardene er komplekse men det er nå et sett av byggeklosser som alle er definerte og burde være testbare med automatiserte testsnutter, dvs kjøre browser på en testside, ta et skjermbilde av hva nettleseren vise og så sammenligne.

En annen side av saken er å teste at browser motorne kaller Javascript event funksjoner og i riktig rekkefølge.

Noe av problemet er at HTML aldri var ment til å lage komplekse interaktive websider, tror det kan være bedre for nye sider der HTML5 gir kraftigere verktøy for å uttrykke det en ønsker å få til og ikke en masse hacks med floats eller whatnot og som like gjerne er avhengig av bugs i Chromium.

Har tittet litt på kildekoden til Chromium og så vidt jeg kan se så er den ikke strukturert på beste måte for å sikre at en takler alle kombinasjoner korrekt, så vidt jeg kunne se er den ganske brittle og blander flere ting (som layout og rendering) i samme klasser slik at det er fort gjort å legge inn fikser på feil logisk nivå, og da har en det gående med at en så et annet sted i koden igjen jobber rundt at man har lagt inn en fiks på feil sted osv for ingen har oversikten og koden er ikke strukturert slik at den gjenspeiler strukturen slik som beskrevet i standarden.

Da er det store mengder automatiserte tester som må til for Chromium er antakelig for stort til å refaktorere, og man ville i så fall ikke skrive det i C++ (sorry Bjarne).

 

EDIT: Det man antakeligvis ønsker er å ha singleton klasser i implementasjon av layout-motoren slik som 

LayoutADisplayInlineElementInsideADisplayBlockElement

og

LayoutADisplayBlockElementInsideAFlexGridElement osv

og så velger man riktig klasse ut i fra som er bestemt tilfelle som layoutmotoren skal utføre.

Man kan da gjøre override for de bestemte layout-situasjoner som er vanskelig å håndtere og som ellers fort knekker, og også gjøre dette på ett veldefinert sted i koden. Å velge riktig singleton er oversiktlig (display: inline i display: block element), man kan gjøre endringer isolert i layout motor uten påvirke annet.

Dette er noe som å skrive tilstandsmaskiner for de som kjenner til slike, det er lettere å ha oversikt over at en har dekt alle tilfeller enn å ha if-tester på en masse uavhengig bool tilstands-variabler for spesialtilfellene ala 'if (slik or else if not sånn or else if noe annet) '.

Endret 7. juli 2020 av tjavel