Lucrurile Internet Explorer au dreptate

Este browserul pe care toată lumea îl iubește - uneori justificabil. Ceea ce a fost cel mai inovator browser a devenit ghimpul în toate părțile dezvoltatorului din față. În mijlocul tulburărilor și plângerilor pe care dezvoltatorii de astăzi le aruncă la Internet Explorer, ceea ce nu se aude adesea este modul în care Microsoft a schimbat fața nu numai a dezvoltării front-end, ci și a dezvoltării web în ansamblu.

Căderea IE nu este o poveste neobișnuită; de fapt, este oarecum aceeași poveste ca și Netscape. Compania din spatele browser-ului de top se înmulțește, browserul stagnează și apare un nou campion. Este un ciclu repetitiv, unul cu care Mozilla se confruntă din nou într-o oarecare măsură (dar asta este o altă poveste pentru un alt moment).


Influența IE4 asupra DOM

Înainte de browserele de versiune 4, JavaScript a fost utilizat în principal pentru prelucrarea datelor simple (validarea formularului). Ca atare, paginile web au fost în principal statice. În timp ce o pagină ar putea fi generată dinamic de către aplicațiile de pe server, pagina nu a putut interacționa cu utilizatorul. Această limitare a existat din cauza modelului obiect de document neadecvat al browserului (DOM), care este interfața de programare a aplicațiilor (API) dezvoltatorilor JavaScript care permite accesul și manipularea elementelor individuale din pagină. DOM-ul care exista înainte de browserele versiunii 4 este denumit frecvent DOM Level 0. Implementările DOM Level 0 permit dezvoltatorilor acces la

, , și elemente, dar este vorba despre asta.

"Microsoft primește din nou Internet Explorer pe drumul cel bun."

Netscape Navigator 4

Abia în momentul în care Netscape a lansat Navigator 4 (NS4) la mijlocul anului 1997, DOM-ul browser-ului a permis dezvoltatorilor web să modifice o pagină cu JavaScript. Tehnica manipulării elementelor cu JavaScript și DOM a fost numită Dynamic HTML (DHTML). DHTML-ul lui NS4 a fost cu siguranță un pas înainte, însă DOM-ul pe bază de straturi propriu-zis și prost conceput și stilul limită de cascadă limitat (CSS) sprijină dezvoltatorii restricționați în ceea ce pot realiza.

Accesarea elementelor

Netscape nu a implementat un model de obiect complet. În afară de funcționalitatea DOM Level 0, singurele elemente pe care un dezvoltator le-ar putea accesa au fost elemente absolut poziționate, elemente, și elemente (ultimele două elemente au fost poziționate de facto). Fiecare dintre aceste tipuri de elemente au fost reprezentate de a Strat obiect în DOM NS4. Proiectat de Netscape Strat obiecte care sunt foarte asemănătoare obiectelor de cadru (și astfel fereastră). Fiecare Strat obiect a avut un document proprietate, care a fost, în principiu, un alt document HTML. Ca niște cadre, a Strat obiect ar putea fi imbricate în altul Strat obiect, făcând codul pentru a accesa aceste straturi extrem de verbose, cum ar fi următoarele:

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

Aceste două linii de cod fac același lucru: accesează Strat obiect cu un id de mySecondLayerId care este îmbrăcat într-un strat cu un id de myLayerId. Da, dezvoltatorii trebuiau să meargă pe "copac" pentru a accesa straturile imbricate.

Conținut dinamic

NS4 DOM nu a permis crearea, inserarea, mutarea și eliminarea obiectelor DOM, ci pentru că fiecare strat a fost expus a document obiect, un dezvoltator ar putea schimba dinamic conținutul unui strat folosind scrie(), sarcină(), și închide() metode. În timp ce acest lucru oferă o putere suplimentară modelului de strat, acesta a limitat dezvoltatorii în modul în care ar putea actualiza dinamic o pagină. Un nou conținut ar trebui să fie scris sau încărcat într-un strat, eliminând efectiv conținutul existent al stratului. Inutil să spun că majoritatea dezvoltatorilor au evitat manipularea conținutului și, în schimb, s-au axat pe schimbarea stilului unui strat.

Schimbarea stilului

Dezvoltarea pe web folosind DOM NS4 a fost dureroasă și frustrantă.

Dar stilul din DOM NS4 a fost un lucru amuzant. În timp ce browser-ul a sprijinit CSS într-o oarecare măsură, Strat obiectele nu au furnizat un API pentru dezvoltatorii care să poată accesa direct un strat stil atributul de azi stil obiect. In schimb, Strat obiectele expuse unui set foarte limitat de proprietăți care au modificat poziția unui strat, vizibilitatea, tăierea și culoarea de fundal / imaginea - nimic altceva, iar valoarea acestor proprietăți acceptate a fost, de asemenea, destul de limitată. De exemplu, proprietățile de poziționare și tăiere acceptă numai valori numerice; un dezvoltator nu a putut specifica o unitate (cum ar fi px, em, pt, etc). Un exemplu de astfel de cod urmează:

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

Inutil să mai spunem că dezvoltarea web folosind DOM NS4 a fost dureroasă și frustrantă. Capabilitățile DHTML extrem de limitate ale NS4 provin din limitările motorului de randare al lui NS4 (nu a putut reîmprospăta pagina). Dar de ce petreceti atat de mult timp pe DOM Netscape, mai ales intr-un articol care ar trebui sa fie despre IE? Dacă Netscape a câștigat războiul browserului, DOM de astăzi ar fi un pas evolutiv din DOM prezentat de Netscape în NS4. În timp ce DOM-ul de astăzi este un standard introdus de W3C (și unele idei Netscape sunt implementate în standardul de astăzi), DOM de astăzi este puternic influențată de DOM IE4.

IE4 DOM

Doar câteva luni după lansarea aplicației Netscape Navigator 4, Microsoft a lansat versiunea a patra a IE. De asemenea, a inclus suport pentru DHTML, dar Implementarea Microsoft a fost mult diferită și superioară față de NS4. IE4 sa bucurat de mult mai mult suport CSS și un model de obiect mai complet pentru a accesa și manipula elementele și conținutul paginii. Efectul DOM IE4 a fost foarte mare; de fapt, un dezvoltator poate găsi multe asemănări între DOM IE4 și standardul DOM.

Accesarea elementelor

"Microsoft a schimbat fața nu numai de dezvoltare front-end, dar dezvoltarea web ca un întreg?"

Designerii de la IE4 au dorit să transforme browserul într-o platformă pentru aplicațiile Web. Așa că au abordat API-ul lui IE4 ca pe un sistem de operare - oferind un model de obiect aproape complet care reprezenta fiecare element (și atributele unui element) ca un obiect care poate fi accesat cu un limbaj de scripting (IE4 este compatibil atât cu JavaScript, cât și cu VBScript).

În DOM IE4, mijlocul principal de accesare a unui anumit element în pagină a fost proprietatea toate[] colecție, care conținea fiecare element din document. Dezvoltatorii pot accesa elemente cu un index numeric sau prin specificarea unui element id sau Nume, asa:

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

Utilizând acest cod, dezvoltatorii pot accesa obiectul element cu un id de myElementId indiferent de locul în care a existat în cadrul paginii. Acest lucru este în contrast puternic cu modelul stratului Netscape, în care dezvoltatorii puteau accesa doar straturile prin ierarhia stratului. Funcționalitatea document.all [ "elementId"] a evoluat în standard document.getElementById () metodă. Dar acest lucru nu a fost singurul mod în care un dezvoltator putea accesa elemente; se poate merge copac DOM și atinge fiecare element cu copii [] colectare și parentElement proprietate-precursori la standard childNodes [] și parentNode proprietăţi.

În plus față de încărcarea elementelor ca obiecte, DOM IE4 a reprezentat atributele unui element ca proprietăți ale obiectului element. De exemplu, id, Nume, și stil proprietăți mapate direct la elementele unui element id, Nume, și stil atribute, respectiv. Acest design a devenit standard.

Conținut dinamic

Microsoft a inventat innerHTML proprietate.

La fel ca Netscape, Microsoft nu a furnizat un API complet pentru a adăuga, muta și elimina dinamic noduri cu JavaScript. Cu toate acestea, ei au inventat innerHTML proprietate pentru a obține sau a seta conținutul unui element. Spre deosebire de Netscape Strat obiecte scrie() și sarcină() metode, innerHTML proprietatea nu era o soluție totală sau totală pentru modificarea conținutului unui element; un dezvoltator ar putea folosi innerHTML pentru a șterge complet, a înlocui sau a adăuga la conținutul unui element. De exemplu, următorul cod primește conținutul unui element și îl modifică:

var el = document.all.myElementId, html = el.innerHTML; el.innerHTML = html + "Bună ziua, interiorHTML";

Până în prezent, innerHTML proprietatea este o piatră de temelie a DHTML. Este un mijloc eficient de a adăuga cantități mari de conținut unui element. Chiar dacă nu a fost niciodată inclusă oficial în niciun standard DOM, fiecare browser major implementează un innerHTML proprietate.

Modificarea stilului

Microsoft a inventat mai multe instrumente și desene care au evoluat în bucăți din standardul DOM, însă munca pe care au făcut-o cu API-ul stilului IE4 a devenit standard cu foarte puține modificări. Cheia pentru schimbarea stilului unui element în IE4 a fost stil proprietate, aceeași proprietate (și sintaxă) folosită astăzi de dezvoltatori.

DHTML a schimbat dezvoltarea web pentru totdeauna. A fost totuși DOM-ul IE4 care a împins tehnologia (și dezvoltarea web) înainte fiind influențarea primară a specificațiilor W3C DOM Level 1 și 2. IE4 a revoluționat dezvoltarea web în 1997, iar IE ar face acest lucru din nou câțiva ani mai târziu.


IE Revoluționează Ajax

Ajax a suflat ușile deschise pentru dezvoltarea web-ului.

Înainte de Ajax a fost Ajax, a fost numit scripting de la distanță, iar dezvoltatorii care folosesc puterea de scripting la distanță folosesc cadre ascunse și iframe pentru comunicarea client-server. Un cadru ascuns (i) conține, de obicei, un formular completat dinamic și trimis prin JavaScript. Răspunsul serverului ar fi un alt document HTML care conține JavaScript care a notificat pagina principală pe care datele au fost primite și gata de utilizare. A fost brut, dar a funcționat.

A existat însă o alternativă: o bijuterie puțin cunoscută îngropată în biblioteca Microsoft MSXML 2.0. IE5, lansat în martie 1999, a inclus MSXML 2.0, iar dezvoltatorii au găsit o componentă numită XMLHttp (numele real al interfeței a fost IXMLHTTPRequest). Numele său este înșelător, ca XMLHttp obiectul funcționează mai mult ca un simplu client HTTP decât orice altceva. Nu numai că dezvoltatorii pot trimite cereri cu obiectul, dar pot monitoriza starea solicitărilor și pot prelua răspunsul serverului.

Natural, XMLHttp a început să înlocuiască tehnica ascunsă (i) a cadrului pentru comunicarea client-server. Câțiva ani mai târziu, Mozilla a creat propriul obiect, modelat după Microsoft XMLHttp, și a sunat-o XMLHttpRequest. Apple a urmat exemplul cu ei XMLHttpRequest obiect în 2004, iar Opera a implementat obiectul în 2005.

În ciuda interesului său în creștere, popularitatea XMLHttp/XMLHttpRequest (colectiv cunoscută sub numele de XHR aici) nu a explodat până în 2005, când Jesse James Garrett și-a publicat articolul "Ajax: o nouă abordare a aplicațiilor web".?

Ajax a suflat ușile deschise pentru dezvoltarea web-ului, iar în prima linie au fost JavaScript, XHR și DHTML - două dintre acestea fiind invenții ale Microsoft. Deci ce s-a întâmplat? Ce a provocat un browser care a schimbat literal modul în care dezvoltatorii web scriu aplicații web pentru a deveni banii webului modern?


Căderea Internet Explorer

Până în 2003, cota de piață totală a Internet Explorer era de aproximativ 95%; Microsoft a câștigat oficial războiul browserului. Cu nici o concurență reală în spațiul Web, Microsoft și-a schimbat focalizarea de la browser la .NET. Acest lucru este confirmat de citate de la mulți angajați Microsoft, dar cel mai plin de cuvinte este dintr-un articol CNET intitulat? Va ajuta Ajax să curețe Google? În acesta, Charles Fitzgerald, managerul general al Microsoft pentru tehnologiile de platformă, a fost citat spunând:

?Este puțin cam deprimant că dezvoltatorii își înfășoară capul în jurul acestor lucruri pe care le-am expediat la sfârșitul secolului al XX-lea [ed: DHTML și Ajax], dar XAML este într-o altă clasă. Acest lucru este foarte cludgy, foarte greu de depanat. Am văzut câteva hack-uri destul de impresionante, dar dacă te uiți la ceea ce XAML începe să rezolve, este un pas major, major.?

Astfel, în mai 2003, Microsoft a anunțat că IE nu va mai fi lansată separat de Windows (excelentul IE5 pentru Mac a fost, de asemenea, conservat). Browserul ar fi dezvoltat în continuare ca parte a sistemului de operare Windows care se dezvoltă, însă Microsoft nu va lansa versiuni independente ale IE. Ei pariau în primul rând pe ClickOnce, o tehnologie care permite dezvoltatorilor să scrie aplicații convenționale (folosind .NET desigur) și să le distribuie pe Web.

Dar Web-ul a continuat să evolueze pe calea Microsoft inițial stabilită cu IE4 și IE5, iar Microsoft a început să-și piardă cota de piață pentru moștenitorul lui Netscape: Firefox. Dezvoltatorii scriau aplicații web care trăiau în browser, nu în aplicații convenționale prin ClickOnce. Aceasta a forțat Microsoft să ridice IE, să-l oprească și să înceapă să versize din nou versiuni independente.


Microsoft continuă să inoveze

IE9, include un suport mult mai bun pentru standarde.

Următoarele două versiuni, 7 și 8, au fost în mare măsură evolutive. IE7 conține o varietate de remediere a erorilor, XMLHttpRequest identificatorul (deși a creat încă un XMLHttp obiect din biblioteca MSXML) și îmbunătățiri ale interfeței și securității.

IE8 a fost, în mare măsură, mai mare, cu excepția faptului că a împrăștiat fiecare tab-o funcție pe care Google a implementat-o ​​și în Chrome (Microsoft a anunțat-o mai întâi). Izolează fiecare filă în propriul proces, sporind securitatea și stabilitatea. Sandboxing devine standard în browserele de astăzi (Firefox încă nu are capacitatea) și se mișcă și în domeniul accesoriilor și pluginurilor.

Microsoft primește din nou Internet Explorer.

Cea mai recentă versiune, IE9, include suporturi de standarde mult mai bune, dar de asemenea inovează cu noul său motor de compilare JIT (care utilizează un nucleu separat CPU dacă este disponibil și poate accesa GPU-ul) și motorul său de redare accelerat hardware. În timp ce motoarele JavaScript de compilare JIT nu sunt noi, capacitatea IE9 de a descărca compilarea pe un nucleu separat în paralel cu redarea paginilor este o realizare care va stimula performanța mult mai mare pentru aplicațiile web. Abilitățile hardware-accelerare s-au dovedit utile atunci când au debutat, iar acum Firefox și Chrome oferă o accelerație hardware într-o oarecare măsură.

Nu se poate nega faptul că Internet Explorer a cauzat dureri de cap pentru dezvoltatorii web. Viteza de cinci ani dintre IE6 și IE7 a determinat Microsoft să se situeze în spatele competiției, făcând ca dezvoltarea front-end să fie mai puțin decât ideală. Dar Microsoft primește din nou Internet Explorer. Ei au format dezvoltarea web la ceea ce este astăzi; aici sperăm să o facă din nou.

Următoarea versiune a Internet Explorer, versiunea 9, este programată să fie lansată oficial pe 14 martie 2011.