Sakerna Internet Explorer fick rätt

"Microsoft får Internet Explorer tillbaka på rätt spår."

Netscape Navigator 4

Det var först när Netscape släppte Navigator 4 (NS4) i mitten av 1997 att en webbläsares DOM gjorde det möjligt för webbutvecklare att ändra en sida med JavaScript. Tekniken att manipulera element med JavaScript och DOM kallades Dynamisk HTML (DHTML). NS4: s DHTML var verkligen ett steg framåt, men det proprietära och elakt utformade lagerbaserade DOM- och begränsade Cascading Style Sheet (CSS) -stöd begränsade utvecklare i vad de faktiskt skulle kunna åstadkomma.

Åtkomst till element

Netscape implementerade inte en hel objektmodell. Bortsett från DOM Level 0-funktionalitet kunde de enda element som en utvecklare åtkomst var absolut positionerade element, element, och element (de senare två elementen placerades de facto). Var och en av dessa typer av element representerades av a Lager objekt i NS4: s DOM. Netscape designad Lager objekt som liknar ramar (och sålunda fönster) föremål. Varje Lager objektet hade a dokumentera egendom, vilket i princip var ett annat HTML-dokument. Gilla ramar, a Lager objektet kan vara näst i en annan Lager objekt, vilket gör att kod för att komma åt de här lagren är extremt verbal som följande:

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

Dessa två kodkod gör samma sak: de får tillgång till Lager objekt med en id av mySecondLayerId som är näst i ett lager med en id av myLayerId. Ja, utvecklare måste gå ner i lagret "träd" för att få tillgång till kapslade lager.

Dynamiskt innehåll

NS4: s DOM gjorde det inte möjligt att skapa, infoga, flytta och ta bort DOM-objekt, men eftersom varje lager exponerade en dokumentera objekt, kan en utvecklare dynamiskt ändra ett lager innehåll genom att använda skriva(), ladda(), och stänga() metoder. Även om detta ger lite extra kraft till lagermodellen, begränsade den utvecklarna hur de dynamiskt kan uppdatera en sida. Nytt innehåll måste skrivas eller laddas i ett lager, vilket effektivt tar bort lagrets befintliga innehåll. Det var självklart att de flesta utvecklare undvikde innehållshantering och istället fokuserade på att ändra lagerets stil.

Ändra stil

Webbutveckling med NS4: s DOM var smärtsamt och frustrerande.

Men stilen i NS4: s DOM var en rolig sak. Medan webbläsaren stödjer CSS i viss utsträckning, Lager objekt gav inte ett API för utvecklare att direkt komma åt ett lager stil attribut som dagens stil objekt. Istället, Lager objekt exponerade en mycket begränsad uppsättning egenskaper som ändrade lagrets position, synlighet, klippning och bakgrundsfärg / bild - inget annat, och det värde som dessa egenskaper accepterade var också ganska begränsade. Till exempel accepterade positionerings- och klipningsegenskaperna endast numeriska värden; en utvecklare kunde inte ange en enhet (som px, em, pt, etc). Ett exempel på sådan kod följer:

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

Naturligtvis, webbutveckling med NS4: s DOM var smärtsamt och frustrerande. NS4: s extremt begränsade DHTML-kapacitet beror på gränserna för NS4: s återgivningsmotor (det kunde inte återföra sidan). Men varför spendera så mycket tid på Netscape's DOM, speciellt i en artikel som ska vara om IE? Hade Netscape vunnit webbläsarkriget, skulle dagens DOM vara ett evolutionärt steg från DOM presenterat av Netscape i NS4. Medan dagens DOM är en standard som utarbetats av W3C (och några Netscape-idéer implementeras i dagens standard), påverkas dagens DOM starkt av IE4: s DOM.

IE4: s DOM

Bara några månader efter att Netscape släppte Navigator 4 släppte Microsoft den fjärde versionen av IE. Det ingår också stöd för DHTML, men Microsofts implementering var mycket annorlunda och överlägsen NS4. IE4 skrytte mycket bättre CSS-stöd och en mer komplett objektmodell för att komma åt och manipulera element och innehåll på sidan. Effekten av IE4: s DOM var långtgående; Faktum är att en utvecklare kan hitta många likheter mellan IE4: s DOM och standard DOM.

Åtkomst till element

"Microsoft förändrade ansiktet av inte bara front-end-utveckling, utan webbutveckling som helhet?"

IE4: s designers ville att webbläsaren skulle bli en plattform för webbapplikationer. Så de närmade sig IE4: s API som ett operativsystem, vilket gav en nästan komplett objektmodell som representerade varje element (och ett elements attribut) som ett objekt som kunde nås med ett skriptspråk (IE4 stödde både JavaScript och VBScript).

I IE4: s DOM var det primära sättet att komma åt ett visst element på sidan den proprietära Allt[] samling, som innehöll varje element i dokumentet. Utvecklare skulle kunna få tillgång till element med ett numeriskt index eller genom att ange ett element id eller namn, så här:

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

Med hjälp av denna kod kan utvecklarna komma åt elementobjektet med ett ID på myElementId oavsett var den fanns inom sidan. Detta står i stark kontrast till Netscapes lagermodell där utvecklare bara kunde få tillgång till lager genom lagrets hierarki. Funktionaliteten hos document.all [ "elementId"] utvecklats till standarden document.getElementById () metod. Men det var inte det enda sättet som en utvecklare kunde få tillgång till. man kan gå DOM-trädet och röra varje element med barn[] insamling och parentElement fastighetsmottagare till standarden childNodes [] och parent egenskaper.

Förutom att ladda element som objekt, representerade IE4: s DOM ett elements attribut som egenskaper hos elementobjektet. Till exempel, id, namn, och stil egenskaper mappade direkt till ett element id, namn, och stil attribut. Denna design blev standard.

Dynamiskt innehåll

Microsoft uppfann innerhtml fast egendom.

Liksom Netscape gav Microsoft inte ett komplett API för att dynamiskt lägga till, flytta och ta bort noder med JavaScript. De uppfann emellertid innerhtml egenskap för att få eller ställa in ett elements innehåll. Till skillnad från Netscape Lager objekt skriva() och ladda() metoder, innerhtml egendom var inte en helt eller ingenting lösning för att ändra ett elements innehåll; en utvecklare kan använda innerhtml att helt radera, ersätta eller lägga till ett elements innehåll. Till exempel får följande kod ett elements innehåll och ändrar det:

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

Till denna dag, den innerhtml egendom är en hörnsten av DHTML. Det är ett effektivt sätt att lägga till stora mängder innehåll på ett element. Även om det aldrig formellt har inkluderats i någon DOM-standard, implementerar alla större webbläsare en innerhtml fast egendom.

Ändra stil

Microsoft uppfann flera verktyg och mönster som utvecklats till delar av standard DOM, men det arbete de gjorde med IE4s stil API blev standard med mycket liten modifikation. Nyckeln till att ändra ett elements stil i IE4 var stil egendom, samma egenskap (och syntax) som används av utvecklare idag.

DHTML ändrade webbutveckling för alltid. Det var emellertid IE4: s DOM som drivit tekniken (och webbutveckling) framåt genom att vara det primära inflytandet på W3C: s DOM Level 1 och 2-specifikation. IE4 revolutionerade webbutveckling 1997, och IE skulle göra det igen några år senare.

IE revolutionerar Ajax

Ajax blåste dörrarna öppna för webbutveckling.

Innan Ajax var Ajax kallades det fjärranslutna skript och utvecklare som utnyttjade kraften i fjärrskrivning använde dolda ramar och iframes för klient-server kommunikation. En dold ram (i) innehöll vanligtvis en form som fylldes i dynamiskt och skickades via JavaScript. Serverns svar skulle vara ett annat HTML-dokument som innehåller JavaScript som meddelade huvudsidan som data mottogs och redo att använda. Det var rå, men det fungerade.

Det var ett alternativ, dock: en liten känd pärla begravd i Microsofts MSXML 2.0-bibliotek. IE5, som släpptes i mars 1999, inkluderade MSXML 2.0, och utvecklare hittade en komponent som heter XMLHTTP (det aktuella gränssnittsnamnet var IXMLHTTPRequest). Dess namn är vilseledande, som XMLHTTP objekt fungerar mer som en enkel HTTP-klient än vad som helst annat. Inte bara kan utvecklare skicka förfrågningar med objektet, men de kunde övervaka önskemålens status och hämta serverns svar.

Naturligtvis, XMLHTTP började ersätta den dolda (i) ramtekniken för klient-serverkommunikation. Några år senare skapade Mozilla sitt eget objekt, modellerat efter Microsofts XMLHTTP, och kallade den XMLHttpRequest. Apple följde med deras XMLHttpRequest objekt 2004, och Opera genomförde objektet 2005.

Trots det växande intresset, populariteten av XMLHTTP/XMLHttpRequest (kollektivt känd som XHR här ute) exploderade inte fram till 2005 när Jesse James Garrett publicerade sin artikel, "Ajax: en ny metod för webbapplikationer.?

Ajax blåste dörrarna öppna för webbutveckling, och i framkant var JavaScript, XHR och DHTML-två var Microsofts uppfinningar. Så vad hände? Vad orsakade en webbläsare som bokstavligen ändrade hur webbutvecklare skriver webbapplikationer för att bli banan på den moderna webben?

Internet Explorer Fall

År 2003 var Internet Explorer totala marknadsandel omkring 95%; Microsoft vann officiellt webbläsarkriget. Med ingen verklig konkurrens i webbutrymme skiftade Microsoft sitt fokus från webbläsaren till .NET. Detta bekräftas av citat från många Microsoft-anställda, men det mest berättande är från en CNET-artikel som heter "Kommer Ajax hjälpa Google att städa upp ?? I det citerades Charles Fitzgerald, Microsofts generaldirektör för plattformsteknologier som följande:

?Det är lite deprimerande att utvecklare just nu sätter in sina huvuden kring dessa saker som vi skickade i slutet av 1900-talet [ed: DHTML och Ajax], men XAML är i en helt annan klass. Dessa andra saker är mycket kludgy, mycket svårt att felsöka. Vi har sett några ganska imponerande hackar, men om du tittar på vad XAML börjar lösa är det ett stort, stort steg upp.?

Så i maj 2003 meddelade Microsoft att IE inte längre skulle släppas separat från Windows (den utmärkta IE5 för Mac var också konserverad). Webbläsaren skulle fortfarande utvecklas som en del av det utvecklande Windows-operativsystemet, men Microsoft skulle inte släppa några fristående versioner av IE. De satsade främst på ClickOnce, en teknik som tillåter utvecklare att skriva konventionella applikationer (med .NET förstås) och distribuera dem via webben.

Men webben fortsatte att utvecklas i den väg som Microsoft ursprungligen satt med IE4 och IE5, och Microsoft började förlora marknadsandelar till Netscape's arving: Firefox. Utvecklare skrev webbprogram som levde i webbläsaren, inte i konventionella applikationer via ClickOnce. Det tvingade Microsoft att hämta IE, damma av det och börja släppa fristående versioner igen.

Microsoft fortsätter att Innovate

IE9, innehåller mycket bättre standardstöd över hela linjen.

De två följande versionerna 7 och 8 var i stor utsträckning evolutionära. IE7 innehöll en mängd olika buggfixar, XMLHttpRequest identifieraren (även om den fortfarande skapade en XMLHTTP objekt från MSXML-biblioteket) och förbättringar av användargränssnittet och säkerhet.

IE8 var i stort sett mer av samma, förutom att det var sandboxed varje flik - en funktion som Google också implementerade i Chrome (Microsoft tillkännagav det först). Det isolerar varje flik i sin egen process, vilket ökar säkerheten och stabiliteten. Sandboxning blir standard i dagens webbläsare (Firefox saknar fortfarande möjligheten), och den flyttar också in i riken till tillägg och plugin-program.

Microsoft får Internet Explorer tillbaka på rätt spår.

Den senaste versionen, IE9, innehåller mycket bättre standardstöd över hela linjen, men det innoverar också med sin nya JIT-compilering JavaScript-motor (som använder en separat CPU-kärna om den är tillgänglig och kan komma åt GPU) och dess hårdvaruaccelererade återgivningsmotor. Medan JIT-kompilering av JavaScript-motorer inte är nytt, kan IE9: s förmåga att avlasta kompilering till en separat kärna parallellt med sidan rendering vara en prestation som kommer att stimulera till mycket nödvändig prestanda för webbapplikationer. Dess hårdvaruaccelerationsförmågor visade sig vara användbara när debuterade, och nu erbjuder Firefox och Chrome i viss utsträckning hårdvaruacceleration.

Det förnekas inte att Internet Explorer har orsakat huvudvärk för webbutvecklare. Femårsperioden mellan IE6 och IE7 orsakade att Microsoft skulle falla långt efter tävlingen, vilket gör utveckling av fronten mindre än idealisk. Men Microsoft får Internet Explorer tillbaka på rätt spår. De formade webbutveckling till vad det är idag; här hoppas de gör det igen.

Nästa version av Internet Explorer, version 9, är planerad att vara officiellt släppt den 14 mars 2011.