# Webbläsare ## Vad det är En webbläsare är programmet som tar emot en adress, hämtar det servern skickar tillbaka och gör om det till en sida som någon kan läsa, scrolla i och klicka på. Många utvecklare säger browser, och i vardagligt tal räcker det med webbläsaren. Chrome, Safari, Firefox och Edge är namnen på ikonerna, men under dem finns betydligt färre program än namnen låter ana. I HTML-standarden står ordet browser sällan. Där heter det _user agent_, programvaran som agerar för läsarens räkning, och större delen av texten är en förteckning över vad en user agent ska göra med en sida. Tre av de skyldigheterna förklarar det mesta av vad en webbläsare finns till för. Den första är att tolka märkningen. Standarden ger regler för hur HTML-dokument ska tolkas oavsett om de är syntaktiskt korrekta eller inte, så en sluttagg som saknas eller ett element på fel plats stoppar inte sidan. Varje webbläsare som följer standarden lagar samma trasiga märkning till samma träd av element. Därför visas en slarvig sida ändå, och därför kan felen i den ligga obemärkta i flera år. Den andra är händelseloopen. Klick, tangenttryck, timrar, svar från nätverket, skript och uppritningen av nästa bildruta ställer sig i kö och turas om. Ett skript som håller loopen i två sekunder håller samtidigt upp klick, inmatning och nästa uppritning, och det är just det någon menar när de säger att sidan har hängt sig. Den tredje är att hålla webbplatser isär. Standarden definierar ett ursprung (origin) som ett schema, en värd och en port, och en site som schemat plus den registrerbara delen av domännamnet. Ett skript från ett ursprung som sträcker sig in i dokumentet från ett annat får ett säkerhetsfel tillbaka, inte innehållet. Det mesta av det som skyddar fliken med banken från fliken med nyheter är den regeln, och webbläsaren upprätthåller den vid varje åtkomst. Delen som utför arbetet kallas _motorn_. De flesta webbläsare som används i dag bygger på en av tre: Blink i Chrome, Edge och en lång rad andra, WebKit i Safari och Gecko i Firefox. Ett nytt webbläsarnamn betyder oftast ett nytt skal kring en av dem, med eget adressfält, egna inställningar och egen synkronisering, men med samma regler för hur en sida läses och ritas. Två grannar blandas ofta ihop med webbläsaren. En sökmotor är en webbplats som webbläsaren öppnar när adressfältet får ord i stället för en adress. En _webview_ är en webbläsarmotor som byggts in i en annan app, med adressfältet och de flesta kontrollerna bortplockade. Testverktygen lägger till en tredje, den _huvudlösa_ webbläsaren (headless), som ritar sidor som ingen tittar på så att ett skript kan kontrollera dem. ## Varför det spelar roll En server kan skicka exakt rätt byte och läsaren ändå få en oläslig sida, eftersom det en person ser är vad webbläsaren gjorde av de byten, med personens egna inställningar ovanpå. Det är i webbläsaren som arbetet bedöms, och det får fyra följder för hur du bygger och testar. **Testa motorer, inte varumärken.** En testplan med fyra webbläsarnamn kan mycket väl täcka två motorer två gånger och missa den tredje helt. Den lista som är till nytta namnger motorerna, och därtill de plattformar där samma motor beter sig annorlunda: en telefon med liten skärm och pekinmatning, eller en utskriftsdialog. **Läsarens inställningar hör till sidan.** En webbläsare bär med sig ett önskat färgschema, en begäran om minskad rörelse, en zoomnivå, en standardstorlek för text och ibland ett översättningslager ovanpå allt. En sida som struntar i det är gjord för en enda konfiguration hos en enda person, och oftast är det personen som byggde den. **Funktioner efterfrågas, de antas inte.** Motorerna får ny CSS och nya gränssnitt vid olika tidpunkter. En sida som behöver något som bara vissa motorer klarar kan fråga motorn direkt: CSS har `@supports`, och ett skript kan testa om en egenskap finns innan det använder den. User agent-strängen är en dålig ersättning, eftersom webbläsarna länge har formulerat den delvis för att likna varandra, så att äldre kod som sniffar efter namn skulle släppa in dem. **Regler i webbläsaren är en artighet.** Validering av formulär, en inaktiverad kontroll och en dold länk körs alla i ett program som läsaren äger och kan ändra. De gör den ärliga vägen lättare att gå, men de stoppar ingen som öppnar utvecklarverktygen eller hoppar över sidan helt. Allt som skyddar pengar, data eller åtkomst kontrolleras därför en gång till på servern. ## Så ser det ut i praktiken Den här webbplatsen stryker under sina länkar med skip-ink, inställningen som bryter linjen där den annars skulle korsa en nedstapel. I Chromium såg luckorna rätt ut. Uppmätta i en riktig Safari i åtta gångers förstoring var de ungefär sex gånger smalare, och orsaken visade sig vara en defekt i WebKit: ett enda snitt som deklarerade ett icke-latinskt teckenintervall försämrade skip-ink för hela familjen. Lösningen blev ett omdöpt familjenamn i typsnittsstacken. Redogörelsen för [understrykningen i Safari och typsnittsdelmängden bakom den](/sv/notes/safari-underline-font-subset/) slutar i den lärdom som den här artikeln hellre sätter först: en skip-ink-mätning är bara sann för den motor som gjorde den. Tabellen, diagnosen och den första lösningen var alla Chromium, och skärmbilden som öppnade fallet igen kom från en människa som tittade på sidan. Utskrift är nästa ställe där motorerna går isär. [Utskriftsstilmallen på 637 rader](/sv/portfolio/built-a-637-line-print-stylesheet-136/) dokumenterar fyra motorbeteenden som fällor, var och en knuten till en verklig defekt. Den första gäller viewport-enheter, som en webbläsare vid utskrift mäter mot arkets sidruta och en annan mot fönstret, och därför tappade varje rad en tredjedel när sidan skrevs ut från ett brett fönster. Element med fast position ritas ut på varje ark. Etiketter som färgats för det mörka standardtemat kom ut vitt på vitt hos läsare vars webbläsare föredrog mörkt. En flex- eller grid-ruta som paginerade medier inte kan dela gav ett tomt första ark. Kontrollen som vaktar allt detta kör sex kombinationer av papper och orientering under båda inställningarna för färgschema och räknar de faktiska sidorna, och sidan noterar fortfarande en motor som struntar i reglerna för horungar och änkor. Det tredje fallet hittades av läsare, inte av ett test. När webbplatsen gick ut som [en onion-spegel i Tor på en läsbar adress](/sv/portfolio/published-the-site-as-a-tor-onion-mirror-on-a-readable-168/), satt de första läsarna i en annan webbläsarmotor, en som saknar den scrollstyrda animation som sidfoten byggde på, och varenda en av dem fick kolofonen målad tvärs över förstasidan. Defekten fanns lika mycket på den vanliga webbplatsen; det krävdes en publik på en annan motor för att den skulle synas. ## Var det går fel - **En sida provas i webbläsaren på utvecklarens skrivbord och förklaras klar.** Varje vana hos den enda motorn blir ett dolt antagande. Botemedlet är en kort matris med en webbläsare per motor, plus en telefon, där varje rättelse mäts i alla innan den kallas klar. - **Koden läser webbläsarens namn och gissar vad den klarar.** Gissningen slår fel för varje webbläsare som lånar en annans etikett, och den åldras med varje ny version. Att fråga efter funktionen lämnar beslutet hos motorn, och regeln utanför blocket är det som alla andra motorer får, så den ska vara det säkra läget: ```css .footer { position: static; } @supports (animation-timeline: scroll()) { .footer { animation: settle linear both; animation-timeline: scroll(); } } ``` - **Element utan egen stil ärver webbläsarens standardvärden.** Rubriker, marginaler och framför allt formulärkontroller kommer med varje motors inbyggda stilmall, och de stilmallarna skiljer sig åt. En design som såg färdig ut kan ha lutat sig mot en enda motors val utan att någon har fattat de besluten. - **En regel som bara gäller i sidan behandlas som om den gällde överallt.** En knapp som gråats ut av ett skript, ett fält som bara tar siffror, en länk som döljs för den som saknar abonnemang: var och en håller bara för läsare som lämnar sidan som den skickades. Servern gör om varje kontroll som spelar roll. - **Länkar öppnas inuti någon annans app.** En länk som trycks i en chatt eller ett socialt flöde hamnar ofta i en inbyggd webbläsare eller en webview, ofta med egen lagring, så den som är inloggad i sin vanliga webbläsare kommer fram som en främling. Flöden som lämnar över till en annan app eller räknar med en befintlig session behöver testas från de ingångarna också. ## Läs mer - [NIST CSRC Glossary: web browser](https://csrc.nist.gov/glossary/term/web_browser) — två korta definitioner hämtade ur NIST:s publikationer, varav den ena är den raka ”client software used to view Web content”. - [HTML Standard: Parsing HTML documents](https://html.spec.whatwg.org/multipage/parsing.html) — reglerna varje webbläsare följer för att göra om märkning, trasig eller inte, till samma träd. - [HTML Standard: Event loops](https://html.spec.whatwg.org/multipage/webappapis.html#event-loops) — hur inmatning, skript, nätverkssvar och rendering turas om på en och samma loop. - [HTML Standard: Loading web pages](https://html.spec.whatwg.org/multipage/browsers.html) — ursprung, sites och reglerna som hindrar en sida från att läsa en annan. - [WebKit Bugzilla: bug 255159](https://bugs.webkit.org/show_bug.cgi?id=255159) — motorns egen rapport om skip-ink-defekten som beskrivs ovan.