Webbrowserens historie
Webbrowserens historie er afgørende for at besvare spørgsmål om moderne webdesign. I denne artikel vil vi undersøge svaret på spørgsmålet: kan du designe websteder så robuste som selve det verdensomspændende web? Vi dykker ned i verdenshistoriens historie for at finde ud af det.
Utroligt nok kan du gennemse websteder lavet i dag i en browser, der blev oprettet for tre årtier siden. Der vil ikke være nogen styling. Der vil ikke være nogen scripting. Hverken CSS eller JavaScript eksisterede ved fødslen af internettet, og de brugte bestemt ikke bedste værktøjer til webdesign omkring i dag. Men hvis et websted er blevet bygget på en robust måde (måske ved hjælp af en top webstedsbygger ), vil det stadig give mening, selv når det ses i en gammel webbrowser.
Fra begyndelsen
Den 12. marts 1989 offentliggjorde en ung computerforsker ved navn Tim Berners-Lee et notat. Han arbejdede hos CERN, Den Europæiske Organisation for Atomforskning. De tusinder af forskere, der arbejder der, havde brug for en måde at samarbejde over internettet på. Berners-Lee havde en mulig løsning. Han offentliggjorde sin idé under titlen Information Management: A Proposal.
Det var ikke ligefrem en side-turner, og diagrammerne var helt uforståelige. Men der var nok til at få projektet i gang. Dette projekt blev verdensomspændende. Inden for et år efter offentliggørelsen af sit oprindelige forslag oprettede Berners-Lee den første version af HTML, den første webserver og den første webbrowser. Browseren blev noget forvirrende navngivet WorldWideWeb.
Tredive år efter det oprindelige forslag til internet blev en gruppe designere og udviklere samlet i en uge på CERN for at genskabe oplevelsen af at bruge den første webbrowser nogensinde. Du kan se det endelige resultat her .
Udvidelse af internettet
Videnskabeligt samarbejde var den første anvendelsesmetode for internettet, men projektet var ikke designet til at være begrænset til denne brug. Berners-Lee vidste, at han ikke kunne forudsige, hvordan internettet ville blive brugt i fremtiden. Han designede det derfor til at være udvideligt.
Den første version af HyperText Markup Language havde bare en håndfuld elementer. Men HTML-sproget er åbent for nye elementer, der tilføjes. Over tid fik vi flere formfelter, flere strukturelle elementer som sektion og artikel og endnu flere medier som lyd, video og responsive billeder. Ingen af disse tilføjelser indførte brudende ændringer. Det er på grund af HTML-fejlhåndteringsmodellen.
Når en webbrowser støder på et HTML-element, som den ikke forstår, gengives det, hvad der er mellem åbnings- og lukningstaggene. Det viser indholdet, mens det ignoreres de tags, det ikke forstår. Hvad der er interessant her er, hvad browseren ikke gør. Browseren kaster ikke en fejl. Browseren holder ikke op med at analysere HTML'en, så snart den støder på et element, som den ikke forstår.
Denne form for slap fejlhåndtering er et eksempel på et designprincip kaldet Robusthedsprincippet eller Postels lov: 'Vær konservativ i det, du sender. Vær liberal i det, du accepterer. '
Browsere er meget liberale i, hvad de accepterer, når det kommer til HTML. På den ene side kan dette være ret frustrerende, hvis du er en udvikler, der prøver at isolere en fejl i din HTML. På den anden side har denne løshed gjort det muligt for HTML at vokse over tid uden at bryde i ældre browsere.
I det første årti af internettet levede HTML en eksplosiv vækst. Nye elementer og attributter blev føjet til sproget. Nogle af disse tilføjelser tilføjede ny semantisk granularitet, men andre havde absolut intet at gøre med semantik. Elementer og attributter til angivelse af skrifttypestørrelser, farver og kanter blev introduceret. HTML, som var beregnet til at definere dokumentstruktur, så ud til at være i fare for at blive oversvømmet med præsentationsinstruktioner. Løsningen var at opdele struktur og præsentation på to forskellige sprog.
01. Præsentationslaget
Håkon Wium Lie og Bert Bos gik sammen om at arbejde på Cascading Style Sheets. Ved hjælp af CSS kunne udviklere tilføje præsentationsoplysninger uden at have blandet det med HTML.
Med ankomsten af CSS kunne HTML vende tilbage til at gøre, hvad det gør bedst: at beskrive strukturen i et dokuments indhold. Den nye adskillelse af bekymringer havde andre fordele. En enkelt CSS-fil kunne være ansvarlig for et HTML-dokument, eller det kunne være ansvarlig for flere HTML-dokumenter: 10, 20, 100 HTML-sider kunne alle henvise til det samme typografiark. Tilpasning af den visuelle stil på de 100 forskellige sider involverede ikke længere ændring af hver eneste. Det var nok at ændre den enkelte CSS-fil.
Men CSS har stadig brug for en eller anden måde at forstå, hvilke dele af HTML det skal styles. Det har en slags 'mental model' af, hvordan dele af HTML kan målrettes til styling. Denne model er repræsenteret i form af vælgere. Ved hjælp af CSS's valgordforråd kan udviklere målrette mod elementer med et bestemt tagnavn, klassenavn eller ID. Du kan tænke på denne måde at modellere et dokument på som at være som en dokumentvælgermodel.
Afgørende, CSS vedtog den samme fejlhåndteringsmodel som HTML. Hvis du bruger en vælger, som webbrowseren ikke forstår, ignorerer den de vedlagte erklæringer og springer videre til den næste vælger. Webbrowseren kaster ikke en fejl. Det stopper ikke med at analysere CSS-filen på det tidspunkt og nægter at gå længere.
Ligeledes, hvis du bruger en egenskab eller værdi, som browseren ikke forstår, springer den over den og går videre til næste erklæring. Dette har gjort det muligt for CSS at vokse over tid uden at vente på universel browsersupport. Du kan bruge nye vælgere, egenskaber og værdier, selvom de ikke er tilgængelige i hver browser. De ikke-understøttende browsere ignorerer det, de endnu ikke forstår. De er liberale i, hvad de accepterer, hvilket forhåbentlig betyder mindre afhængighed af dine tekniske tjenester webhosting service.
02. Adfærdslaget
At beskrive strukturen og præsentationen af et dokument er bemyndigende, men det har sine grænser. Ved hjælp af HTML og CSS kan du lave smukke, tilgængelige, semantiske websider, men de er statiske. Interaktion er afgrænset af HTMLs ordforråd. Links og formularfelter er som standard interaktive, men hvis du vil udvide interaktiviteten af HTML, har du brug for et script-sprog.
I de tidlige dage af internettet oprettede en ung ingeniør ved navn Brendan Eich et scriptingsprog til webbrowsere. Marketingafdelingen i hans firma, Netscape, kaldte det JavaScript. Det er et forfærdeligt navn. Det lyder som JavaScript har noget at gøre med Java-programmeringssproget. Det gør det ikke. Men dengang var Java klar til at overtage verden. Navngivning af dette nye sprog JavaScript fik det til at lyde hip.
HTML og CSS er erklærende sprog. I stedet for at give trinvise instruktioner beskriver du det ønskede resultat ved hjælp af sprogets ordforråd (elementer og attributter i HTML, vælgere, egenskaber og værdier i CSS). På plussiden har disse deklarative sprog den løse fejlhåndtering, der gør dem relativt lette at komme i gang med. Men på ulempen vil du altid være begrænset af sprogets ordforråd.
Et script-sprog er mere kraftfuldt. Det giver dig mulighed for at specificere præcist, hvad du vil skal ske. Men den kraft og præcision har en pris. Et skriptsprog har ikke råd til at have den samme slappe fejlhåndtering som et deklarativt sprog. Hvis du skriver noget JavaScript, som en browser ikke forstår, kaster browseren en fejl. Det stopper med at analysere scriptet på det tidspunkt og nægter at analysere yderligere. Postels lov gælder ikke her. Browsere er slet ikke liberale i, hvad de accepterer, når det kommer til JavaScript.
JavaScript's strengere fejlhåndtering betyder, at udviklere skal være mere forsigtige, når de skriver det. Hvis der er en bestemt browser-API, der er tilgængelig i JavaScript, skal du overveje, hvad der vil ske i en browser, der endnu ikke har sendt den API. Denne browser ignorerer ikke bare dele af din kode, der bruger den nye funktion. I stedet skal du teste for eksistensen af API. Denne form for 'funktionsdetektering' er ikke nødvendig på de erklærende sprog i HTML og CSS, men det er en nødvendig del af at skrive ansvarlig JavaScript.
Dokumentobjektmodellen
CSS har en måde at 'se' en HTML-side på - en slags dokumentvælgermodel. JavaScript har en anden måde at eksponere strukturen i et HTML-dokument på. JavaScript-sproget bruger programmeringskonceptet af objekter til at eksponere API'er. Browsere giver for eksempel et vindueobjekt til JavaScript, der beskriver det aktuelle browservindue. HTML-siden inde i vinduet eksponeres gennem et andet objekt, der kaldes dokumentobjektet. I modsætning til CSS, med dets ordforråd for vælgere, 'ser' JavaScript en HTML-side gennem denne dokumentobjektmodel eller DOM.
Under de dårlige gamle dage i browser-krigene i 1990'erne, da JavaScript først ankom til scenen, blev browsere leveret med modstridende DOM-ordforråd. Netscape Navigator havde en måde at beskrive et dokument på - dokument.lag - mens Microsofts Internet Explorer bruges document.all i stedet. Udviklere måtte forkaste deres kode ved hjælp af funktionsdetektering for at finde ud af, hvilken kode der skulle sendes til hvilken browser. Det var utåleligt.
Til sidst konvergerede browsere til et standardiseret ordforråd til DOM-scripting. Metoder som document.getElementsByTagName og document.getElementById var JavaScript-ækvivalenterne for elementvælgerne og ID-vælgerne i CSS.
Ved hjælp af JavaScript og DOM var udviklere i stand til at tilføje ekstra interaktivitet til deres ellers statiske sider. Til at begynde med var interaktionerne ret grundlæggende. Billedoverførsler var populære: da brugeren flyttede markøren hen over et billede, kunne JavaScript bytte billedet ud. Formularvalidering var en anden almindelig brug af JavaScript og DOM. Scripts kan 'lytte' til begivenheder - som når en bruger indsender en formular - og udføre kode for at kontrollere, at indgangene overholder bestemte kriterier.
Interessant nok kan begge disse brugssager nu udføres uden JavaScript (hvilket betyder, at en bredere vifte af aktiver kan bruges, og du skal bruge top Sky lagring at gemme dem i). Hvis du vil ændre, hvordan et element ser ud, når brugeren mouser det, kan du bruge det : svæver i CSS. Hvis du vil have formularfelter, der kun tillader bestemte typer værdier, kan du bruge HTML5-inputtyper som e-mail, URL og nummer. Disse populære brugssager er kommet ned fra det kraftfulde - men skrøbelige - skriptlag til de mere tilgivende - men mindre kraftfulde - deklarative lag.
JQuery, AJAX og mere
De fleste DOM-scriptmønstre - som billedoverførsler og formvalidering - involverer at finde en bestemt del af et dokument og derefter udføre kode, når en bestemt begivenhed udløses. Du kan sammenfatte disse mønstre som: 'Find ting og gør ting til det'.
For at 'finde ting' var du nødt til at bruge DOM-metoder. Men i midten af 2000'erne oprettede John Resig et JavaScript-bibliotek for at gøre det lettere for udviklere at lave DOM-scripting. Han kaldte det jQuery.
Der var mange andre JavaScript-biblioteker på det tidspunkt - script.aculo.us, MooTools og mere. Det, der udmærker sig ved jQuery, var, at det gjorde det muligt for dig at 'finde ting' ved hjælp af selektorens syntaks for CSS. Hvis du allerede kendte CSS, behøvede du ikke længere at lære et separat ordforråd for at interagere med HTML. Dette var enormt bemyndigende for designere og udviklere, der forstod HTML og CSS, men blev skræmt af JavaScript's stejlere indlæringskurve. jQuery var så populær, at det påvirkede designet af DOMs ordforråd. Du kan nu bruge document.querySelector metode til at 'finde ting' i et HTML-dokument ved hjælp af CSS-vælgere.
Med stigningen i jQuery så Internettet en stigning i interaktive widgets. Karuseller, modevinduer og flymenuer blev almindelige. På samme tid blev nettet fejet af Ajax-feber. Ajax er en JavaScript-teknik, der gør det muligt for dokumentet, der aktuelt er indlæst i browservinduet, at sende og modtage data fra en webserver uden at opdatere hele siden. Nu var internettet et bæredygtigt medium til applikationer. Gmail og Google Maps førte an og demonstrerede, at - takket være JavaScript - næsten alt er muligt på nettet.
JavaScript spiser internettet
Da webapplikationer voksede mere og mere komplekse, udvidede JavaScript-bibliotekerne deres anvendelsesområde. Først angular og derefter React kodede en ny tilgang. I stedet for at behandle JavaScript som et separat interaktionslag, der sidder oven på et eksisterende HTML-dokument, vender den moderne tilgang denne model på hovedet. JavaScript bliver kernen. DOM genereres ikke længere fra eksisterende HTML - DOM genereres i stedet for JavaScript. JavaScript indsprøjter markering på en ellers tom side. Du kan endda bruge JavaScript til at indsprøjte CSS lige ind i DOM ved runtime. Hvor der engang var en adskillelse af bekymringer - struktur, præsentation og adfærd - nu kan du gøre alt på et sprog.
Denne kraft har en pris. Hvis indholdet af en webside injiceres med JavaScript, skal scriptet downloades, parses og udføres, før brugeren ser noget. Browsere er optimeret til at streame HTML, selv når den er ufuldstændig. Det er ikke en mulighed med JavaScript. Ydeevne lider og dermed brugerens oplevelse.
Den strengere fejlhåndtering af JavaScript gør det også farligt. Hvis der kun er en fejl i din kode, eller hvis der ikke er tilstrækkelig funktionsdetektering til at håndtere ældre browsere, forbliver brugerne stirrende på en tom skærm.
Princippet om mindst magt
Da Tim Berners-Lee arbejdede på sit verdensomspændende webprojekt, anvendte han en række designprincipper: enkelhed, tolerance (i form af Postels lov), modulært design og princippet om mindst magt: 'Vælg det mindst kraftfulde sprog, der er passende til et bestemt formål '. Se det her .
På forsiden af dette virker det som usædvanligt råd, men husk, at stærke sprog har en pris: skrøbelighed. Mindre magtfulde sprog er mere tilgivende og mere udbredt.
Vi kan anvende princippet om mindst magt, når vi opretter produkter
og tjenester på nettet. Som webtilgængelighedsekspert Derek Featherstone udtrykker det: 'I webfront-end-stakken - HTML, CSS, JavaScript og ARIA - hvis du kan løse et problem med en enklere løsning lavere i stakken, skal du gøre det. Det er mindre skrøbelig, mere idiotsikker. Det virker bare. '
JavaScript, Ajax og DOM er kraftfulde værktøjer. Brug dem ansvarligt.
Læs mere:
