De dingen die Internet Explorer heeft gedaan

"Microsoft krijgt Internet Explorer weer op de rails."

Netscape Navigator 4

Pas toen Netscape medio 1997 Navigator 4 (NS4) uitbracht, kon een browser met DOM-webontwikkelaars een pagina met JavaScript wijzigen. De techniek om elementen te manipuleren met JavaScript en de DOM werd Dynamic HTML (DHTML) genoemd. NS4's DHTML was zeker een stap voorwaarts, maar de eigen en slecht ontworpen op lagen gebaseerde DOM en de beperkte Cascading Style Sheet (CSS) ondersteunen beperkte ontwikkelaars in wat ze eigenlijk kunnen bereiken.

Toegang tot elementen

Netscape heeft geen volledig objectmodel geïmplementeerd. Afgezien van DOM Level 0-functionaliteit waren de enige elementen die een ontwikkelaar kon gebruiken absoluut gepositioneerde elementen, elementen, en elementen (de laatste twee elementen waren de facto gepositioneerd). Elk van deze soorten elementen werd vertegenwoordigd door een Laag object in de DOM van NS4. Netscape ontworpen Laag objecten lijken sterk op frame (en dus venster) objecten. Elk Laag object had een document eigenschap, wat eigenlijk een ander HTML-document was. Zoals frames, a Laag object kan in een andere worden genest Laag object, het maken van code om toegang te krijgen tot die lagen extreem uitgebreid, zoals het volgende:

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

Deze twee regels code doen hetzelfde: ze krijgen toegang tot de Laag object met een ID kaart van mySecondLayerId dat is genest in een laag met een ID kaart van myLayerId. Ja, ontwikkelaars moesten de laag "tree" aflopen om geneste lagen te benaderen.

Dynamische inhoud

NS4's DOM stond niet toe dat DOM-objecten gemaakt, ingevoegd, verplaatst en verwijderd werden, maar omdat elke laag een document object, kan een ontwikkelaar de inhoud van een laag dynamisch wijzigen met behulp van de schrijven(), laden(), en dichtbij() methoden. Hoewel dit wat extra kracht geeft aan het laagmodel, beperkte het ontwikkelaars in de manier waarop ze een pagina dynamisch konden bijwerken. Nieuwe inhoud moet in een laag worden geschreven of in een laag worden geladen, waardoor de bestaande inhoud van de laag daadwerkelijk wordt verwijderd. Onnodig te zeggen dat de meeste ontwikkelaars inhoudsmanipulatie vermeden en in plaats daarvan de nadruk legden op het veranderen van de stijl van een laag.

Van stijl veranderen

Webontwikkeling met de DOM van NS4 was pijnlijk en frustrerend.

Maar de stijl in de DOM van NS4 was grappig. Hoewel de browser CSS tot op zekere hoogte ondersteunt, Laag objecten leverden geen API op voor ontwikkelaars om direct toegang te krijgen tot de lagen stijl attribuut zoals vandaag stijl voorwerp. In plaats daarvan, Laag objecten hebben een zeer beperkte set eigenschappen blootgelegd die de positie, zichtbaarheid, clipping en achtergrondkleur / afbeelding van een laag veranderden - niets anders, en de waarde die deze eigenschappen accepteerden, was ook vrij beperkt. De positionering en clipping-eigenschappen accepteerden bijvoorbeeld alleen numerieke waarden; een ontwikkelaar kon geen eenheid specificeren (zoals px, em, pt, enz.). Een voorbeeld van een dergelijke code volgt:

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

Onnodig te zeggen dat webontwikkeling met de DOM van NS4 pijnlijk en frustrerend was. De extreem beperkte DHTML-mogelijkheden van NS4 komen voort uit de beperkingen van de rendering-engine van NS4 (deze kon de pagina niet opnieuw plaatsen). Maar waarom zou je zoveel tijd besteden aan de DOM van Netscape, vooral in een artikel dat zou moeten gaan over IE? Als Netscape de browseroorlog had gewonnen, zou de DOM van vandaag een evolutionaire stap zijn van de DOM gepresenteerd door Netscape in NS4. Terwijl de DOM van vandaag een standaard is die door de W3C naar voren is gebracht (en sommige Netscape-ideeën zijn geïmplementeerd in de huidige standaard), wordt de DOM van vandaag zwaar beïnvloed door DOM van DOS..

DOM van IE4

Slechts een paar maanden nadat Netscape Navigator 4 had uitgebracht, bracht Microsoft de vierde versie van IE uit. Het bevatte ook ondersteuning voor DHTML, maar De implementatie van Microsoft was heel anders en superieur aan NS4. IE4 kon bogen op veel betere CSS-ondersteuning en een completer objectmodel voor toegang tot en manipulatie van elementen en inhoud op de pagina. Het effect van de DOM van IE4 was verreikend; in feite kan een ontwikkelaar veel overeenkomsten vinden tussen de DOM van IE4 en de standaard DOM.

Toegang tot elementen

"Microsoft veranderde het aanzien van niet alleen front-end ontwikkeling, maar webontwikkeling als geheel?"

De ontwerpers van IE4 wilden de browser veranderen in een platform voor webapplicaties. Dus benaderden ze de IE4-API als een besturingssysteem dat een bijna compleet objectmodel opleverde dat elk element (en de kenmerken van een element) representeerde als een object dat kon worden benaderd met een scriptingtaal (IE4 ondersteunde zowel JavaScript als VBScript).

In de DOM van IE4 was het primaire middel om toegang te krijgen tot een bepaald element op de pagina het eigendom allemaal[] verzameling, die elk element in het document bevatte. Ontwikkelaars kunnen toegang krijgen tot elementen met een numerieke index of door elementen van een element op te geven ID kaart of naam, zoals dit:

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

Met behulp van deze code konden ontwikkelaars toegang krijgen tot het elementobject met een ID van myElementId ongeacht waar het zich op de pagina bevond. Dit staat in schril contrast met het laagmodel van Netscape, waarin ontwikkelaars alleen toegang hebben tot lagen via de hiërarchie van de laag. De functionaliteit van document.all [ "elementID"] uitgegroeid tot de standaard document.getElementById () methode. Maar dit was niet de enige manier waarop een ontwikkelaar toegang kon krijgen tot elementen; men zou de DOM-boom kunnen lopen en elk element raken met de kinderen[] verzameling en parentElement vastgoed-voorlopers naar de standaard childNodes [] en parentNode eigenschappen.

Naast het laden van elementen als objecten, vertegenwoordigde de DOM van IE4 de kenmerken van een element als eigenschappen van het elementobject. Bijvoorbeeld de ID kaart, naam, en stijl eigenschappen die rechtstreeks zijn toegewezen aan die van een element ID kaart, naam, en stijl attributen, respectievelijk. Dit ontwerp werd standaard.

Dynamische inhoud

Microsoft heeft de innerHTML eigendom.

Net als Netscape bood Microsoft geen volwaardige API om knooppunten met JavaScript dynamisch toe te voegen, te verplaatsen en te verwijderen. Ze hebben echter wel het innerHTML eigenschap om de inhoud van een element te verkrijgen of in te stellen. In tegenstelling tot Netscape's Laag voorwerpen schrijven() en laden() methoden, de innerHTML property was geen alles-of-niets-oplossing voor het wijzigen van de inhoud van een element; een ontwikkelaar zou kunnen gebruiken innerHTML om de inhoud van een element volledig weg te vagen, te vervangen of toe te voegen. De volgende code krijgt bijvoorbeeld de inhoud van een element en wijzigt deze:

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

Tot op de dag van vandaag, de innerHTML eigendom is een hoeksteen van DHTML. Het is een efficiënt middel om grote hoeveelheden inhoud aan een element toe te voegen. Hoewel het nooit formeel is opgenomen in een DOM-standaard, implementeert elke grote browser een innerHTML eigendom.

Stijl aanpassen

Microsoft bedacht verschillende tools en ontwerpen die evolueerden naar stukjes van de standaard DOM, maar het werk dat ze deden met IE4's style API werd standaard met zeer weinig aanpassingen. De sleutel tot het veranderen van de stijl van een element in IE4 was de stijl property, dezelfde eigenschap (en syntaxis) die vandaag door ontwikkelaars wordt gebruikt.

DHTML heeft de webontwikkeling voor altijd veranderd. Het was echter de DOM van IE4 die de technologie (en webontwikkeling) vooruit duwde door de primaire invloed te zijn op de DOM Level 1 en 2-specificatie van de W3C. IE4 heeft een revolutie teweeggebracht in de ontwikkeling van het web in 1997, en IE zou dat enkele jaren later opnieuw doen.

IE revolutioniseert Ajax

Ajax blies de deuren open voor webontwikkeling.

Voordat Ajax Ajax was, werd dit externe scripting genoemd, en ontwikkelaars die gebruik maakten van de kracht van externe scripting gebruikten verborgen frames en iframes voor client-servercommunicatie. Een verborgen (i) frame bevatte meestal een formulier dat dynamisch werd ingevuld en verzonden via JavaScript. Het antwoord van de server zou een ander HTML-document zijn met JavaScript dat de hoofdpagina meldde dat de gegevens werden ontvangen en gereed voor gebruik. Het was grof, maar het werkte.

Er was echter een alternatief: een onbekend juweel begraven in de MSXML 2.0-bibliotheek van Microsoft. IE5, uitgebracht in maart 1999, bevatte MSXML 2.0 en ontwikkelaars vonden een component genaamd XMLHTTP (de feitelijke interfacenaam was IXMLHTTPRequest). De naam is misleidend, zoals de XMLHTTP object functioneert meer als een eenvoudige HTTP-client dan iets anders. Niet alleen konden ontwikkelaars verzoeken met het object verzenden, maar ze konden ook de status van de verzoeken controleren en het antwoord van de server ophalen.

Van nature, XMLHTTP begon de verborgen (i) kadertechniek voor client-servercommunicatie te vervangen. Een paar jaar later creëerde Mozilla zijn eigen object, gemodelleerd naar dat van Microsoft XMLHTTP, en noemde het XMLHttpRequest. Apple volgde het voorbeeld met hun XMLHttpRequest object in 2004, en Opera heeft het object in 2005 geïmplementeerd.

Ondanks zijn groeiende interesse, de populariteit van XMLHTTP/XMLHttpRequest (hierna gezamenlijk XHR genoemd) is pas in 2005 ontploft toen Jesse James Garrett zijn artikel publiceerde,? Ajax: een nieuwe aanpak van webapplicaties.?

Ajax blies de deuren open voor webontwikkeling, en was in de voorhoede JavaScript, XHR en DHTML - twee daarvan waren de uitvindingen van Microsoft. Dus wat gebeurde er? Wat veroorzaakte een browser die letterlijk veranderde hoe webontwikkelaars webapps schrijven om de vloek van het moderne web te worden?

Fall van Internet Explorer

Tegen 2003 bedroeg het totale marktaandeel van Internet Explorer ongeveer 95%; Microsoft heeft officieel de browser-oorlog gewonnen. Zonder echte concurrentie in de webruimte verschoof Microsoft hun focus van de browser naar .NET. Dit wordt bevestigd door citaten van veel Microsoft-medewerkers, maar het meest sprekende is van een CNET-artikel getiteld: "Zal Ajax Google helpen opruimen?" Hierin citeerde Charles Fitzgerald, general manager van platformtechnologieën van Microsoft, het volgende:

?Het is een beetje deprimerend dat ontwikkelaars nu net hun hoofd omwikkelen met deze dingen die we in de late 20e eeuw hebben verzonden [ed: DHTML en Ajax], maar XAML bevindt zich in een hele andere klas. Deze andere dingen zijn erg kludgy, erg moeilijk om te debuggen. We hebben een aantal behoorlijk indrukwekkende hacks gezien, maar als je kijkt naar wat XAML begint op te lossen, is het een grote, belangrijke stap omhoog.?

Dus in mei 2003 kondigde Microsoft aan dat IE niet langer los van Windows zou worden uitgebracht (de uitstekende IE5 voor Mac was ook ingeblikt). De browser zou nog steeds worden ontwikkeld als onderdeel van het zich ontwikkelende Windows-besturingssysteem, maar Microsoft zou geen afzonderlijke versies van IE vrijgeven. Ze wedden voornamelijk op ClickOnce, een technologie waarmee ontwikkelaars conventionele applicaties kunnen schrijven (uiteraard met .NET) en deze via het web kunnen verspreiden..

Maar het web bleef evolueren op het pad dat Microsoft oorspronkelijk had ingesteld met IE4 en IE5, en Microsoft begon marktaandeel te verliezen aan de erfgenaam van Netscape: Firefox. Ontwikkelaars waren webtoepassingen aan het schrijven die in de browser woonden, niet in conventionele applicaties via ClickOnce. Dat dwong Microsoft om IE op te pakken, af te stoffen en losstaande versies opnieuw uit te brengen.

Microsoft blijft innoveren

IE9 bevat veel betere standaardondersteuning over de hele linie.

De volgende twee versies, 7 en 8, waren grotendeels evolutionair. IE7 bevat verschillende bugfixes, de XMLHttpRequest identifier (hoewel het nog steeds een XMLHTTP object uit de MSXML-bibliotheek) en verbeteringen in de gebruikersinterface en beveiliging.

IE8 was grotendeels hetzelfde, behalve dat het elk tabblad sandboxed - een functie die Google ook in Chrome implementeerde (Microsoft heeft dit eerst aangekondigd). Het isoleert elk tabblad in zijn eigen proces, waardoor de beveiliging en stabiliteit toenemen. Sandboxing wordt standaard in browsers van tegenwoordig (Firefox mist nog steeds de mogelijkheid), en het komt ook op het gebied van add-ons en invoegtoepassingen.

Microsoft krijgt Internet Explorer weer op het goede spoor.

De nieuwste versie, IE9, biedt een veel betere standaardondersteuning over de hele linie, maar hij innoveert ook met zijn nieuwe JIT-compilerende JavaScript-engine (die een afzonderlijke CPU-kern gebruikt als deze beschikbaar is en toegang heeft tot de GPU) en de hardwareversnelde rendering-engine. Hoewel JIT-compilatie van JavaScript-engines niet nieuw is, is de mogelijkheid van IE9 om compilatie te offloaden naar een afzonderlijke kern naast de pagina-rendering een prestatie die de broodnodige prestaties voor webapplicaties zal stimuleren. De mogelijkheden voor hardwareversnelling bleken nuttig te zijn bij het debuteren, en nu bieden Firefox en Chrome tot op zekere hoogte hardwareversnelling.

Het valt niet te ontkennen dat Internet Explorer hoofdpijn heeft veroorzaakt voor webontwikkelaars. De vijf jaar durende pauze tussen IE6 en IE7 zorgde ervoor dat Microsoft ver achterbleef bij de concurrentie, waardoor front-end ontwikkeling minder dan ideaal was. Maar Microsoft krijgt Internet Explorer weer op het goede spoor. Ze hebben webontwikkeling gevormd tot wat het nu is; hier is de hoop dat ze dit opnieuw doen.

De volgende versie van Internet Explorer, versie 9, staat gepland voor 14 maart 2011.