Browser, istoria e crucială pentru a răspunde la întrebări despre design. Putem construi un website la fel de rezilient ca World Wide Web? Vă invităm să parcurgeți articolul nostru despre website builder pentru un plus de informație.
În mod uimitor, puteți răsfoi website-uri realizate astăzi într-un browser creat acum trei decenii. Nu va exista niciun stil. Nu vor exista scripturi. Nici CSS, nici JavaScript nu existau la „nașterea” web-ului.
Cu siguranță nu au folosit cele mai bune instrumente de web design din prezent. Dacă a fost construit într-un mod robust, va avea sens chiar și când e vizualizat într-un browser antic. Puteți testa website-ul Jucării din Lemn, creat de compania noastră.
Pagina de web design a acestui blog e oferită cu sprijinul platformei de promovare online. Puteți accesa și secțiunile pentru turism, medical sau politică.
Browser: începuturile
La 12 martie 1989, un tânăr informatician pe nume Tim Berners-Lee a publicat o notă. Lucra la CERN, Organizația Europeană pentru Cercetare Nucleară.
Mii de oameni de știință care lucrau acolo aveau nevoie de o modalitate de colaborare prin internet. Berners-Lee avea o soluție potențială. El și-a publicat ideea sub titlul „Management-ul informațiilor: o propunere”.
Nu era tocmai o pagină iar diagramele erau complet de neînțeles. Dar a fost suficient pentru a începe proiectul. Acest proiect a devenit World Wide Web.
Într-un an de la publicarea propunerii sale inițiale, Berners-Lee a creat prima versiune de HTML. Mai apoi, a urmat primul server și primul browser. Browser-ul a fost numit, oarecum confuz, WorldWideWeb.
La 30 de ani de la propunere, un grup de designeri și dezvoltatori s-au reunit la CERN. Aceștia au recreat experiența utilizării primului browser.
Extinderea web-ului prin intermediul unui browser
Colaborarea științifică a fost primul caz de utilizare pentru web. Însă proiectul nu a fost conceput pentru a fi limitat la această utilizare. Berners-Lee știa că nu poate prezice modul în care va fi folosit web-ul în viitor.
El a conceput-o pentru a fi extensibilă.
Prima versiune a HyperText Markup Language avea doar o mână de elemente. Dar limbajul HTML e deschis pentru adăugarea de noi elemente.
De-a lungul timpului, am obținut mai multe câmpuri și mai multe elemente structurale. De exemplu, secțiunea și articolul, chiar mai multe medii precum audio, video și imagini receptive.
Niciuna dintre aceste adăugiri nu a introdus modificări de ultimă oră. Acest lucru se datorează modelului HTML de gestionare a erorilor.
Ce se întâmplă când un browser întâlnește un element HTML pe care nu îl înțelege? Redă orice este între tag-urile de deschidere și de închidere. Afișează conținutul, ignorând tag-urile pe care nu le înțelege.
Un browser nu generează o eroare
Ceea ce este interesant aici e ceea ce browser-ul nu face. Browser-ul nu generează o eroare. Browser-ul nu încetează să analizeze codul HTML imediat ce întâlnește un element pe care nu îl înțelege.
Acest tip de gestionare a erorilor laxe e un exemplu de principiu de proiectare. Este numit Principiul robusteții sau Legea lui Postel: „Fii conservator în ceea ce trimiți. Fii liber în ceea ce accepți”.
Browserele sunt foarte liberale în ceea ce acceptă când vine vorba despre HTML. Pe de o parte, poate fi destul de frustrant dacă sunteți un dezvoltator care vrea să izoleze o greșeală. Pe de altă parte, această slăbiciune a permis HTML să crească în timp, fără a intra în browsere mai vechi.
În primul deceniu al vieții web, HTML a cunoscut o creștere explozivă. Au fost adăugate elementele și atributele noi ale limbajului.
Unele adăugau o nouă granularitate semantică, dar altele nu aveau nimic de-a face cu semantica. Au fost introduse elemente și atribute pentru specificarea dimensiunilor fonturilor, culorilor și chenarelor.
HTML era destinat definirii structurii documentului. Era în pericolul de a fi „inundat” cu instrucțiuni de prezentare. Soluția a fost împărțirea structurii și prezentării în două limbaje diferite.
1. Stratul de prezentare
Håkon Wium Lie și Bert Bos și-au unit forțele pentru a lucra la Cascading Style Sheets. Folosind CSS, dezvoltatorii ar putea adăuga informații de prezentare fără ca acestea să fie amestecate cu HTML.
Odată cu sosirea CSS, HTML putea reveni la ceea ce făcea cel mai bine. Ne referim la a descrie structura conținutului unui document. Noua separare a preocupărilor a avut alte beneficii.
Un singur fișier CSS ar putea fi responsabil pentru un singur document HTML. Pe de altă parte, putea fi responsabil pentru mai multe documente HTML.
Modificarea stilului vizual al celor 100 de pagini diferite nu presupunea schimbarea fiecăruia. Schimbarea fișierului CSS unic a fost suficientă.
CSS are nevoie de informații privind stilizarea unor părți din HTML
Dar CSS are încă nevoie de un mod de a înțelege ce părți din HTML ar trebui să fie stilizate. Are un fel de „model mental” al modului în care părțile din HTML pot fi vizate pentru stilizare.
Modelul e reprezentat sub formă de selectoare. Folosind vocabularul selector CSS, dezvoltatorii pot viza elemente cu un anumit nume de etichetă, de clasă sau ID.
Vă puteți gândi la această modelare a unui document ca la un model de selectare a documentelor.
În mod crucial, CSS a adoptat același model de gestionare a erorilor ca HTML. Utilizați un selector pe care browser-ul nu îl înțelege?
Acesta va ignora declarațiile anexate și va trece la următorul selector. Browser-ul nu va emite o eroare. De asemenea, nu va opri analizarea fișierului CSS în acel moment și va refuza să meargă mai departe.
Utilizați o proprietate sau o valoare pe care browser-ul nu o înțelege? Va trece peste ea la următoarea declarație. S-a permis vocabularului CSS să crească în timp, fără a aștepta suportul universal al browser-ului.
Puteți utiliza noi selectoare, proprietăți și valori chiar dacă acestea nu sunt disponibile în fiecare browser. Browserele care nu suportă ignoră ceea ce nu înțeleg.
2. Stratul de comportament
Descrierea structurii și prezentarea unui document e împuternicitoare, dar are limitele sale. Folosind HTML și CSS, puteți crea pagini semantice frumoase, accesibile, dar sunt statice.
Interacțiunea e delimitată de vocabularul HTML. Link-urile și câmpurile de formular sunt interactive implicit. Dar, dacă doriți să extindeți interactivitatea HTML, aveți nevoie de un limbaj de scriptare.
În primele zile ale internetului, un inginer, Brendan Eich, a creat un limbaj de script pentru browser. Departamentul de marketing al companiei sale, Netscape, l-a numit JavaScript.
Se pare că JavaScript are legătură cu limbajul de programare Java. Nu! Pe atunci, Java era pregătit să preia lumea. Numirea acestui nou limbaj JavaScript a făcut să pară hip.
HTML și CSS sunt limbaje declarative. În loc să oferiți instrucțiuni pas cu pas, descrieți rezultatul dorit folosind vocabularul limbajului. De exemplu, elemente și atribute în HTML, selectoare, proprietăți și valori în CSS.
În plus, aceste limbaje declarative au o eroare slabă, făcându-le ușor de pornit. Dezavantajul e că veți fi întotdeauna limitat de vocabularul limbajului.
Un limbaj de scriptare este mai puternic
Vă permite să specificați cu precizie ce doriți să se întâmple. Dar acea putere și precizie vine cu un preț. Un limbaj de scriptare nu își permite să aibă aceeași gestionare laxă a erorilor ca un limbaj declarativ.
Dacă scrieți un cod JavaScript pe care un browser nu îl înțelege, acesta va declanșa o eroare.
Se va opri analizarea scriptului în acel moment și va refuza să se analizeze mai departe. Legea lui Postel nu e valabilă aici. Browser-ele nu sunt deloc liberale în ceea ce acceptă când vine vorba de JavaScript.
Gestionarea mai strictă a erorilor JavaScript înseamnă că dezvoltatorii trebuie să aibă mai multă grijă. Există un API de browser disponibil în JavaScript? Trebuie să vă gândiți la ce se va întâmpla într-un browser care nu a livrat încă acel API.
Browser-ul respectiv nu va ignora pur și simplu nicio parte din codul dvs. care utilizează noua funcție. În schimb, va trebui să testați existența API-ului.
Acest tip de „detectare a caracteristicilor” nu este necesar în limbajele declarative ale HTML și CSS. De fapt, e o parte necesară a scrierii unui JavaScript responsabil.
Browser: modelul obiectului documentului
CSS are un mod de a „vedea” o pagină HTML – un fel de model de selector de documente. JavaScript are un mod diferit de a expune structura unui document HTML.
Limbajul JavaScript folosește conceptul de programare al obiectelor pentru a expune API-urile. Browserele furnizează un obiect fereastră JavaScript care descrie fereastra curentă a browser-ului.
Pagina HTML din interiorul acelei ferestre este expusă printr-un alt obiect numit obiect document. Spre deosebire de CSS, JavaScript „vede” o pagină HTML prin acest Document Object Model sau DOM.
Când JavaScript a sosit pentru prima dată, browserele au fost livrate cu vocabulare DOM contradictorii. Netscape Navigator avea o modalitate de a descrie un document (document.layers).
Pe de altă parte, Internet Explorer Microsoft a folosit document.all în schimb. Dezvoltatorii au trebuit să își forțeze codul, folosind detectarea caracteristicilor. În acest mod, află ce cod să trimită către care browser. Era intolerabil.
Metode ca document.getElementsByTagName și document.getElementById au fost echivalentele JavaScript.
Interactivitate suplimentară a paginilor statice
Folosind JavaScript și DOM, dezvoltatorii au putut adăuga interactivitate suplimentară paginilor statice. Pentru început, interacțiunile au fost destul de elementare.
Rollover-urile de imagini erau populare. Atunci când utilizatorul își deplasa cursorul peste o imagine, JavaScript putea schimba imaginea. Validarea formularului a fost o altă utilizare obișnuită a JavaScript și a DOM.
Scripturile pot „asculta” evenimente, de exemplu, când un utilizator trimite un formular. Poate executa cod pentru a verifica dacă intrările sunt conforme cu anumite criterii.
Interesant este că ambele cazuri de utilizare pot fi acum realizate fără JavaScript. Dacă doriți să schimbați aspectul unui element atunci când utilizatorul îl blochează puteți utiliza :hover în CSS.
Doriți ca acele câmpuri de formular să permită doar anumite tipuri de valori? Puteți utiliza tipuri de intrare HTML5, cum ar fi adresa de e-mail, adresa URL și numărul.
Cazurile populare de utilizare au coborât din stratul puternic, dar fragil, de scriere. Au ajuns în cele declarative mai iertătoare, dar mai puțin puternice.
JQuery, AJAX și multe altele
Majoritatea modelelor de scriptare DOM implică găsirea unei anumite părți a unui document. Mai apoi, urmează executarea codului atunci când un anumit eveniment este declanșat.
Pentru „a găsi lucruri”, trebuia să folosiți metode DOM. Dar, la mijlocul anilor 2000, John Resig a creat o bibliotecă JavaScript. A facilitat dezvoltatorilor realizarea de scripturi DOM. El a numit-o jQuery.
Pe atunci existau multe alte biblioteci JavaScript (script.aculo.us sau MooTools). Ceea ce distinge jQuery a fost că permitea să „găsiți lucruri” folosind sintaxa selectorului CSS.
Dacă știați deja CSS, nu mai trebuia să învățați un vocabular separat pentru interacțiunea cu HTML. Acest lucru a fost extrem de eficient pentru designerii și dezvoltatorii care au înțeles HTML și CSS.
Pe de altă parte, au fost intimidați de curba de învățare mai abruptă a JavaScript. A fost atât de popular jQuery încât a influențat design-ul vocabularului DOM.
Acum puteți utiliza metoda document.querySelector într-un document HTML folosind selectoare CSS.
Odată cu creșterea jQuery, web-ul a înregistrat o creștere a widgeturilor interactive. Caruselele, ferestrele modale și meniurile fly-out au devenit obișnuite. În același timp, rețeaua era învăluită de „febra” Ajax.
Ajax permite documentului încărcat în prezent în fereastra browser-ului să trimită și să primească date. Informațiile venite de pe un server puteau fi transferate fără a actualiza întreaga pagină.
Acum, web-ul a devenit un mediu viabil pentru aplicații. G-mail și Google Maps au deschis drumuri, demonstrând că datorită JavaScript aproape orice este posibil.
Browser: JavaScript consumă internetul
Pe măsură ce aplicațiile au devenit din ce în ce mai complexe, bibliotecile JavaScript s-au extins. Mai întâi Angular și apoi React au codat o nouă abordare.
Trata JavaScript ca un strat separat de interacțiune care se află deasupra unui document HTML existent. Abordarea modernă întoarce acel model.
JavaScript devine element central. DOM-ul nu mai este generat din HTML existent. DOM-ul e generat de JavaScript. JavaScript injectează marcaj într-o pagină altfel goală.
Puteți folosi JavaScript pentru a injecta CSS direct în DOM în timpul rulării. Când există o separare a preocupărilor (structură, prezentare, comportament) faceți totul într-un singur limbaj.
Această putere vine cu un preț. Conținutul unei pagini e „injectat” cu JavaScript? Scriptul trebuie descărcat, analizat și executat înainte ca utilizatorul să vadă ceva.
Browserele sunt optimizate pentru a transmite în flux HTML, chiar și atunci când este incomplet. Aceasta nu este o opțiune cu JavaScript. Performanța suferă și, odată cu aceasta, experiența utilizatorului.
Gestionarea mai strictă a erorilor JavaScript îl face, de asemenea, periculos. Există o singură eroare în codul dvs. sau nu există suficientă funcție de detectare pentru a face față? Utilizatorii vor rămâne cu ochii în fața unui ecran gol.
Principiul puterii minime
Când Tim Berners-Lee lucra la proiectul său web, el a aplicat o serie de principii de proiectare. Acesta vorbea despre simplitate, toleranță (sub forma Legii Postel), design modular și principiul puterii minime.
Alegeți limbajul cel mai puternic adecvat pentru un scop dat.
Acest lucru pare un sfat neobișnuit, dar amintiți-vă că limbajele puternice au un preț: fragilitatea. Limbaje mai puțin puternice sunt mai iertătoare și mai răspândite.
Putem aplica principiul celei mai mici puteri când creăm produse și servicii pe web. JavaScript, Ajax și DOM sunt instrumente puternice. Folosiți-le în mod responsabil.
Pentru alte servicii de advertoriale și blog vă rugăm să intrați în contact cu noi.