Jump to content
Harald Brombach (digi.no)

INNSIKT: Lover å bedre nettleser­kompatibiliteten [Ekstra]

Recommended Posts

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.

Share this post


Link to post

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) '.

Edited by tjavel

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...