Ting Internet Explorer fikk riktig

"Microsoft får Internet Explorer tilbake på sporet."

Netscape Navigator 4

Det var ikke før Netscape släppte Navigator 4 (NS4) i midten av 1997 at en nettleser DOM tillot webutviklere å endre en side med JavaScript. Teknikken til å manipulere elementer med JavaScript og DOM ble kalt Dynamic HTML (DHTML). NS4s DHTML var sikkert et skritt fremover, men den proprietære og dårlig utformede lagbaserte DOM- og begrensede Cascading Style Sheet (CSS) støtter begrensede utviklere i hva de faktisk kunne oppnå.

Å få tilgang til elementer

Netscape implementerte ikke en full objektmodell. Bortsett fra DOM Level 0-funksjonalitet, kunne de eneste elementene en utvikler ha tilgang til, helt posisjonerte elementer, elementer, og elementer (de to sistnevnte elementene ble de facto posisjonert). Hver av disse elementene var representert av a Lag objekt i NS4s DOM. Netscape designet Lag objekter å være svært lik rammer (og dermed vindu) gjenstander. Hver Lag objektet hadde a dokument eiendom, som i utgangspunktet var et annet HTML-dokument. Som rammer, a Lag objektet kunne være nestet i en annen Lag objekt, gjør kode for å få tilgang til disse lagene ekstremt ordentlig som følgende:

var myLayer1 = document.layers ["myLayerId"]. document.layers ["mySecondLayerId"]; // eller var myLayer2 = document.myLayerId.document.mySecondLayerId;

Disse to kodelinjene gjør det samme: de får tilgang til Lag objekt med en id av mySecondLayerId som er nestet i et lag med en id av myLayerId. Ja, utviklere måtte gå ned laget "tre" for å få tilgang til nestede lag.

Dynamisk innhold

NS4s DOM tillot ikke opprettelse, innføring, flytting og fjerning av DOM-objekter, men fordi hvert lag utsatte en dokument objekt, kan en utvikler dynamisk endre lagets innhold ved å bruke skrive(), laste(), og Lukk() metoder. Selv om dette gir litt ekstra kraft til lagmodellen, begrenset det utviklere i hvordan de dynamisk kunne oppdatere en side. Nytt innhold må skrives eller lastes inn i et lag, og effektivt fjerne lagets eksisterende innhold. Unødvendig å si, de fleste utviklere unngått innholdsmanipulering og i stedet fokuserte på å endre lagets stil.

Endre stil

Webutvikling ved hjelp av NS4s DOM var smertefull og frustrerende.

Men stilen i NS4s DOM var en morsom ting. Mens nettleseren støttet CSS til en viss grad, Lag objekter ga ikke en API for utviklere for direkte tilgang til et lag stil attributt som dagens stil gjenstand. I stedet, Lag objekter utsatt et svært begrenset sett med egenskaper som endret lagets posisjon, synlighet, klipping og bakgrunnsfarge / bilde - ingenting annet, og verdien disse egenskapene godtok var også ganske begrenset. For eksempel aksepterte posisjonerings- og klippeegenskapene bare numeriske verdier; en utvikler kunne ikke spesifisere en enhet (for eksempel px, em, pt, etc). Et eksempel på en slik kode følger:

var myLayer = document.myLayerId.document.mySubLayerId; myLayer.top = 10;

Unødvendig å si, webutvikling ved hjelp av NS4s DOM var smertefull og frustrerende. NS4s ekstremt begrensede DHTML-funksjonalitet stammer fra begrensningene i NS4s gjengivelsesmotor (det kunne ikke reflow siden). Men hvorfor bruke så mye tid på Netscape's DOM, spesielt i en artikkel som skal dreie seg om IE? Hadde Netscape vunnet nettleserkrigen, ville dagens DOM være et evolusjonært skritt fra DOM presentert av Netscape i NS4. Mens dagens DOM er en standard fremsatt av W3C (og noen Netscape ideer implementeres i dagens standard), er dagens DOM sterkt påvirket av IE4s DOM.

IE4s DOM

Bare noen få måneder etter at Netscape släppte Navigator 4, utgav Microsoft den fjerde versjonen av IE. Det inkluderte også støtte for DHTML, men Microsofts implementering var langt forskjellig og overlegen til NS4. IE4 skryte mye bedre CSS-støtte og en mer komplett objektmodell for å få tilgang til og manipulere elementer og innhold på siden. Effekten av IE4s DOM var vidtgående; Faktisk kan en utvikler finne mange likheter mellom IE4s DOM og standard DOM.

Å få tilgang til elementer

"Microsoft forandret ansiktet av ikke bare front-end-utvikling, men nettutvikling som helhet?"

IE4s designere ønsket å slå nettleseren til en plattform for webapplikasjoner. Så de nærmet seg IE4s API som et operativsystem, og ga en nesten komplett objektmodell som representerte hvert element (og et elements attributter) som et objekt som kunne nås med et skriptspråk (IE4 støttet både JavaScript og VBScript).

I IE4s DOM var den primære måten å få tilgang til et bestemt element på siden, den proprietære alle[] samling, som inneholdt hvert element i dokumentet. Utviklere kan få tilgang til elementer med en numerisk indeks eller ved å spesifisere et element id eller Navn, som dette:

var myElement1 = document.all ["myElementId"]; // eller var myElement2 = document.all.myElementId;

Ved å bruke denne koden, kunne utviklere få tilgang til elementobjektet med et ID på myElementId uavhengig av hvor den eksisterte på siden. Dette er i sterk kontrast til Netscapes lagmodell der utviklere bare kunne få tilgang til lag gjennom lagets hierarki. Funksjonaliteten til document.all [ "elementId"] utviklet seg til standarden document.getElementById () metode. Men dette var ikke den eneste måten en utvikler kunne få tilgang til elementer på; man kan gå DOM-treet og berøre hvert element med barn [] samling og parentElement eiendom-forerunners til standarden childNodes [] og parentNode eiendommer.

I tillegg til å laste elementer som objekter, representerte IE4s DOM et elements attributter som egenskapene til elementobjektet. For eksempel, id, Navn, og stil Egenskaper kortlagt direkte til et element id, Navn, og stil attributter, henholdsvis. Dette designet ble standard.

Dynamisk innhold

Microsoft oppfant innerhtml eiendom.

Som Netscape ga Microsoft ikke en fullverdig API for å dynamisk legge til, flytte og fjerne nodene med JavaScript. De oppdaget imidlertid innerhtml egenskap for å få eller angi et elements innhold. I motsetning til Netscape Lag objektets skrive() og laste() metoder, innerhtml Egenskapen var ikke en helt eller ingenting løsning for å endre elementets innhold; en utvikler kunne bruke innerhtml for å tørke ut, erstatte eller legge til et elements innhold helt. For eksempel får følgende kode et elements innhold og endrer det:

var el = document.all.myElementId, html = el.innerHTML; el.innerHTML = html + "Hei, innerHTML";

Til denne dagen, den innerhtml eiendom er en hjørnestein av DHTML. Det er et effektivt middel for å legge til store mengder innhold på et element. Selv om det aldri formelt er inkludert i noen DOM-standard, implementerer alle store nettlesere en innerhtml eiendom.

Endre stil

Microsoft oppfunnet flere verktøy og design som utviklet seg til deler av standard DOM, men arbeidet de gjorde med IE4s stil-API ble standard med svært lite modifikasjon. Nøkkelen til å endre elementets stil i IE4 var stil eiendom, samme egenskap (og syntaks) som brukes av utviklere i dag.

DHTML endret webutvikling for alltid. Det var imidlertid IE4s DOM som presset teknologien (og webutvikling) fremover ved å være den primære innflytelsen på W3Cs DOM Level 1 og 2-spesifikasjon. IE4 revolusjonerte webutvikling i 1997, og IE ville gjøre det igjen noen få år senere.

IE revolusjonerer Ajax

Ajax blåste dørene åpne for webutvikling.

Før Ajax var Ajax, ble det kalt ekstern skripting, og utviklere som utnyttet kraften til ekstern skripting brukte skjulte rammer og iframes for klient-serverkommunikasjon. En skjult (i) ramme inneholdt vanligvis et skjema som ble dynamisk fylt ut og sendt inn via JavaScript. Serverens svar vil være et annet HTML-dokument som inneholder JavaScript som varslet hovedsiden som dataene ble mottatt og klar til bruk. Det var rå, men det virket.

Det var et alternativ, men: en liten kjent perle begravd i Microsofts MSXML 2.0-bibliotek. IE5, utgitt i mars 1999, inkluderte MSXML 2.0, og utviklere fant en komponent som heter XMLHTTP (det aktuelle grensesnittnavnet var IXMLHTTPRequest). Navnet er misvisende, som XMLHTTP objektfunksjoner mer som en enkel HTTP-klient enn noe annet. Ikke bare kan utviklere sende forespørsler med objektet, men de kunne overvåke forespørselenes status og hente serverens svar.

Naturlig, XMLHTTP begynte å erstatte den skjulte (i) rammeteknikken for klient-serverkommunikasjon. Et par år senere skapte Mozilla sitt eget objekt, modellert etter Microsofts XMLHTTP, og kalte det XMLHttpRequest. Apple fulgte med seg med deres XMLHttpRequest objekt i 2004, og Opera implementerte objektet i 2005.

Til tross for den voksende interessen, populariteten til XMLHTTP/XMLHttpRequest (kollektivt kjent som XHR her ute) eksploderte ikke til 2005 da Jesse James Garrett publiserte sin artikkel, "Ajax: en ny tilnærming til webapplikasjoner.?

Ajax blåste dørene åpne for webutvikling, og i forkant var JavaScript, XHR og DHTML, hvorav to var Microsofts oppfinnelser. Så hva skjedde? Hva forårsaket en nettleser som bokstavelig talt forandret hvordan webutviklere skriver webapplikasjoner for å bli banen på den moderne Internett?

Internet Explorer Fall

I 2003 var Internet Explorer totale markedsandel rundt 95%; Microsoft vant nettopp nettleserkrigen. Med ingen ekte konkurranse i webområdet flyttet Microsoft fokus fra nettleseren til .NET. Dette bekreftes av anførselstegn fra mange Microsoft-ansatte, men det mest fortellende er fra en CNET-artikkel med tittelen: Vil Ajax hjelpe Google til å rydde opp? I det ble Charles Fitzgerald, Microsofts daglig leder for plattformteknologi, sitert som å si:

?Det er litt deprimerende at utviklerne akkurat nå pakker hodet rundt disse tingene vi sendte i slutten av det 20. århundre [ed: DHTML og Ajax], men XAML er i en helt annen klasse. Denne andre ting er veldig kludgy, veldig vanskelig å feilsøke. Vi har sett noen ganske imponerende hack, men hvis du ser på hva XAML begynner å løse, er det et stort, stort skritt opp.?

Så i mai 2003 kunngjorde Microsoft at IE ikke lenger ville bli løslatt separat fra Windows (den utmerkede IE5 for Mac ble også hermetisert). Nettleseren vil fortsatt bli utviklet som en del av det Windows-operative utviklingssystemet, men Microsoft vil ikke frigjøre noen frittstående versjoner av IE. De satte seg hovedsakelig på ClickOnce, en teknologi som lar utviklere skrive konvensjonelle applikasjoner (ved hjelp av .NET selvfølgelig) og distribuere dem via nettet.

Men Internett fortsatte å utvikle seg i stien Microsoft opprinnelig satt sammen med IE4 og IE5, og Microsoft begynte å miste markedsandeler til Netscape's arving: Firefox. Utviklere skrev webapplikasjoner som levde i nettleseren, ikke i konvensjonelle applikasjoner via ClickOnce. Det tvunget Microsoft til å plukke opp IE, støv det av, og begynne å frigjøre frittstående versjoner igjen.

Microsoft fortsetter å Innovate

IE9, inneholder mye bedre standard støtte over hele linja.

De neste to versjonene, 7 og 8, var i stor grad evolusjonerende. IE7 inneholdt en rekke feilrettinger, den XMLHttpRequest identifikator (selv om det fremdeles skapte en XMLHTTP objekt fra MSXML-biblioteket), og forbedringer av brukergrensesnittet og sikkerheten.

IE8 var stort sett mer av det samme, bortsett fra at det var sandboxed hver tabulator - en funksjon som Google også implementerte i Chrome (Microsoft kunngjorde det først). Den isolerer hver fane i sin egen prosess, og øker sikkerheten og stabiliteten. Sandboxing blir standard i dagens browsere (Firefox mangler fortsatt muligheten), og den beveger seg også inn i rike av tillegg og plugin-moduler.

Microsoft får Internet Explorer tilbake på sporet.

Den nyeste versjonen, IE9, inneholder mye bedre standardstøtte på tvers av bordet, men det innoverer også med sin nye JIT-kompilerende JavaScript-motor (som bruker en egen CPU-kjerne hvis den er tilgjengelig og kan få tilgang til GPU) og den maskinvareaccelererte renderingsmotoren. Selv om JIT-kompilering av JavaScript-motorer ikke er nytt, kan IE9s evne til å laste kompilering på en egen kjerne parallelt med sidegengivelsen, være en oppnåelse som vil stimulere til mye nødvendig ytelse for webapplikasjoner. Dens hardware-akselerasjon evner viste seg nyttig når debuterte, og nå tilbyr Firefox og Chrome til en viss grad maskinvareakselerasjon.

Det er ikke nektet at Internet Explorer har forårsaket hodepine for webutviklere. Femårsrollet mellom IE6 og IE7 førte til at Microsoft skulle falle langt bak konkurransen, noe som gjør utviklingen på fronten mindre enn ideell. Men Microsoft får Internet Explorer tilbake på sporet. De formet webutvikling til det det er i dag; her håper de gjør det igjen.

Den neste versjonen av Internet Explorer, versjon 9, er planlagt å bli offisielt utgitt 14. mars 2011.