Ce este HTML. Istoria creației. limbaj HTML. Istoria dezvoltării

Istoria dezvoltării HTML

În 1989, Tim Berners-Lee a propus conducerii Centrului Internațional pentru Energie Înaltă (CERN) un proiect pentru un sistem hipertext distribuit, pe care l-a numit World Wide Web (WWW). Ideea originală a sistemului a fost să folosească un sistem de navigație hipertext pentru a combina toate resursele de informații ale CERN într-un singur sistem de informații. Tehnologia s-a dovedit a fi atât de reușită încât a dat impuls dezvoltării unuia dintre cele mai populare sisteme informatice globale din lume. Aproape în mintea majorității utilizatorilor rețelei globale de computere Internet, această rețea în sine este asociată cu trei tehnologii informaționale principale:

· poștă electronică (e-mail);

· Arhive de fișiere FTP;

· World wide web.

Mai mult, cea mai recentă tehnologie trece treptat pe primul loc.

Succesul tehnologiei World Wide Web este determinat de doi factori principali: simplitatea și utilizarea familiei TCP/IP de protocoale de internetworking (Transmission Control Protocol, Internet Protocol), care stau la baza Internetului.

Aproape toți utilizatorii de Internet au avut simultan ocazia să se încerce ca creatori și cititori de materiale informative publicate pe World Wide Web. Dar popularitatea internetului în sine se datorează în mare măsură apariției World Wide Web, deoarece a fost prima tehnologie de rețea care a oferit utilizatorului o interfață simplă și modernă pentru accesarea unei varietăți de resurse de rețea. Simplitatea și ușurința în utilizare au dus la creșterea numărului de utilizatori WWWși a atras atenția structurilor comerciale. Apoi, procesul de creștere a numărului de utilizatori a devenit o avalanșă, iar acest lucru continuă și astăzi.

În același timp, tehnologia în sine a fost extrem de simplă în stadiul inițial. Cert este că la dezvoltarea diferitelor componente ale tehnologiei (limbaj de marcare hipertext HTML, protocol de schimb de informații hipertext HTTP, specificații de dezvoltare a software-ului aplicației CGI etc.), s-a presupus că calificările autorilor resurselor informaționale și echipamentele lor informatice vor fie minim.

Una dintre componentele tehnologiei pentru crearea unui sistem de hipertext distribuit pe World Wide Web a fost limbajul de marcare hipertext HTML, dezvoltat de Tim Berners-Lee pe baza limbajului standard de marcare generalizată (SGML). Daniel W. Connolly a scris o definiție a tipului de document pentru acesta - o descriere formală a sintaxei HTML în termeni SGML.

Dezvoltatorii HTML au reușit să rezolve două probleme:

· oferă designerilor de baze de date hipertext un mijloc simplu de creare a documentelor;

· face acest instrument suficient de puternic pentru a reflecta ideile existente atunci despre interfața cu utilizatorul a bazelor de date hipertext.

Prima problemă a fost rezolvată prin alegerea unui model de etichetare pentru descrierea documentului. Acest model este utilizat pe scară largă în sistemele de pregătire a documentelor pentru tipărire. Un exemplu de astfel de sistem este binecunoscutul limbaj de marcare a documentelor științifice TeX, propus de Societatea Americană de Matematică, și programele pentru interpretarea acestuia.

limbaj HTML vă permite să marcați un document electronic care este afișat pe ecran cu un nivel de imprimare de design; documentul rezultat poate conține o mare varietate de etichete, ilustrații, fragmente audio și video și așa mai departe. Limbajul include instrumente dezvoltate pentru a crea diferite niveluri de titluri, selecții de fonturi, diverse liste, tabele și multe altele.

Al doilea punct important care a influențat soarta HTML a fost că un fișier text obișnuit a fost ales ca bază. Alegerea a fost făcută sub influența următorilor factori:

· un astfel de fișier poate fi creat în orice editor de text de pe orice platformă hardware din mediul oricărui sistem de operare;

· în momentul în care a fost dezvoltat HTML, exista un standard american pentru dezvoltarea sistemelor informaționale de rețea - Z39.50, în care un fișier text simplu în codificare LATIN1 era specificat ca unitate de stocare, care corespunde ASCII SUA.

Astfel, o bază de date hipertext în concept WWW este un set de fișiere text marcate în HTML, care determină forma de prezentare a informațiilor (markup) și structura conexiunilor dintre aceste fișiere și alte resurse de informații (legături hipertext). Legăturile hipertext, stabilind conexiuni între documentele text, au început treptat să unească o mare varietate de resurse informaționale, inclusiv sunet și video; Ca urmare, a apărut un nou concept - hipermedia.

Această abordare presupune prezența unei alte componente a tehnologiei - un interpret de limbă. Pe World Wide Web, funcțiile de interpret sunt împărțite între serverul Web al bazei de date hipertext și interfața cu utilizatorul. Serverul, pe lângă accesarea documentelor și procesarea legăturilor hipertext, asigură preprocesarea documentelor, în timp ce interfața cu utilizatorul interpretează constructele de limbaj legate de prezentarea informațiilor.

Prima versiune a limbajului (HTML 1.0) a avut ca scop prezentarea limbajului ca atare, unde descrierea capacităților sale era mai degrabă de natură consultativă. A doua versiune a limbajului (HTML 2.0) a înregistrat practica de utilizare a constructelor sale. Versiunea ++ (HTML++) a introdus noi funcții, extinzând setul de etichete HTML pentru a afișa informații științifice și tabele, precum și îmbunătățirea stilului de aspect al imaginilor și textului. Versiunea 3.2 a reușit să simplifice toate inovațiile și să le armonizeze cu practica existentă. HTML 3.2 vă permite să utilizați tabele, să executați cod Java, să includeți text în jurul graficelor și să afișați superscripte și subscripte.

Acum, World Wide Web Consortium (W3C) - o organizație internațională care pregătește și distribuie documentație pentru descrierea noilor versiuni de HTML - a publicat deja materiale privind specificația HTML 4.01. Pe lângă capacitățile de marcare a textului, multimedia și hypertext care existau deja în versiunile anterioare de HTML, versiunea 4.01 include instrumente multimedia suplimentare, limbaje de programare, foi de stil și instrumente simplificate pentru imprimarea imaginilor și documentelor. Puteți utiliza limbaje de scripting, cum ar fi JavaScript, Java și VBScript, pentru a gestiona scripturile de navigare pe site-uri web (o bază de date hipertext găzduită pe World Wide Web).

Creșterea complexității HTML și apariția limbajelor de programare au dus la faptul că dezvoltarea site-urilor Web a devenit o chestiune extrem de profesională, necesitând specializare în domenii de activitate și studiu constant al noilor tehnologii Web. Dar puterea Internetului permite utilizatorilor care cunosc elementele de bază ale HTML să-și creeze și să găzduiască propriile site-uri Web fără cheltuieli mari. Cursul propus este conceput pentru astfel de utilizatori.

Traducere

HTML este limbajul care unește World Wide Web. Cu doar un set de etichete simple, omenirea a reușit să creeze un sistem incomparabil de pagini și site-uri Web interconectate: de la Amazon, eBay și Wikipedia, până la bloguri personale și site-uri dedicate pisicilor care arată ca Hitler.

HTML5 este cea mai recentă versiune a acestui limbaj. Dar, în ciuda faptului că va aduce cu sine schimbări semnificative și noi oportunități, nu se poate spune că acest lucru se întâmplă pentru prima dată și că limbajul nu s-a dezvoltat în niciun fel înainte. S-a dezvoltat și s-a îmbunătățit în mod constant și de la începuturile sale.

La fel ca World Wide Web în general, HTML - HyperText Mark-up Language - este creația lui Sir Tim Berners-Lee. În 1991, a scris o lucrare intitulată „Etichete HTML”, în care a descris puțin mai puțin de două duzini de etichete pe care le-a propus pentru marcarea paginilor web.

Ideea de a folosi cuvinte de cod în paranteze triunghiulare pentru aceasta, însă, nu i-a aparținut lui Sir Tim. Un astfel de sistem exista deja la acea vreme și era folosit în SGML (Standard Generalized Markup Language), iar în loc să inventeze ceva de la zero, Sir Tim a considerat mai rațional să ia ca bază soluțiile existente. O abordare similară a fost utilizată pe parcursul întregului proces de dezvoltare a HTML5.

De la IEFT la W3C: drumul către HTML 4

Nu a existat niciodată o versiune de HTML 1. Prima specificație oficială a fost HTML 2.0, publicată de IETF (Internet Engineering Task Force). Multe dintre caracteristicile limbajului descrise în această specificație s-au bazat pe dezvoltări terță parte deja utilizate. De exemplu, etichetați pentru inserarea imaginilor în pagini a fost implementat în browserul principal la acea vreme (vorbim despre 1994) browserul Mosaic, iar apoi a migrat pur și simplu la standardul pentru HTML 2.0.

Bagheta IEFT a fost preluată ulterior de W3C (World Wide Web Consortium), care s-a ocupat de toate versiunile ulterioare de HTML. În a doua jumătate a anilor 90 s-a desfășurat o activitate activă de revizuire și modificare a specificațiilor, care în cele din urmă (mai precis, în 1999) a dat naștere HTML 4.01.

După aceasta, a venit primul punct de cotitură cheie din istoria HTML-ului.

XHTML 1: HTML ca XML

Noua versiune a limbajului de marcare după HTML 4.01 a fost numită XHTML 1.0. „X” din nume a reprezentat eXtreme, iar dezvoltatorii web au fost obligați să își încrucișeze brațele în fața lor de fiecare dată când rosteau cuvântul.

Nu, desigur că nu. De fapt, „x” înseamnă eXtensible („extensibil”), iar încrucișarea brațelor era opțională.

Specificația în sine pentru XHTML 1.0 nu a fost diferită de HTML 4.01. Nu au fost adăugate etichete sau parametri noi - singura diferență a fost în regulile de sintaxă. În timp ce în HTML dezvoltatorii li s-a oferit libertate deplină în ceea ce privește stilul de scriere a codului, în XHTML li s-a cerut să adere la regulile limbajului XML - mult mai rigid și mai intolerant la libertăți - pe care s-au bazat majoritatea tehnologiilor dezvoltate de Consorțiu. .

Regulile stricte, însă, au venit la îndemână. Ei i-au încurajat pe programatori să adere la un singur stil, de exemplu - să scrie toate etichetele și parametrii exclusiv cu litere mici, în timp ce în HTML ați putea face asta după cum doriți.

Lansarea XHTML 1.0 a coincis cu suportul sporit al browserelor moderne pentru foile de stil - CSS - și sintaxa strictă a XHTML a câștigat un loc în comunitatea dezvoltatorilor cu reputația ca cea mai bună modalitate de a scrie cod de marcare.

Apoi a fost XHTML 1.1.

Dacă versiunea 1.0 a fost doar HTML realizată sub XML, atunci XHTML 1.1 este deja XML real, pur. În sensul că nu mai era posibil să i se aplice tip mime text/htmlși trebuia să desemneze documentul ca format XML. Cu toate acestea, în acel caz, cel mai popular browser la acea vreme - Internet Explorer - nu ar fi putut să-l afișeze, așa că utilizarea acestui limbaj în practică nu era clar o opțiune.

Se părea că W3C, în dezvoltarea sa, începea să piardă legătura cu realitatea în care trăia World Wide Web.

XHTML 2: nu, nu se mai încadrează în nicio poartă

Dacă personajul lui Dustin Hoffman din The Graduate ar fi un web designer, W3C ar avea un singur cuvânt să-i spună: XML.

Consorțiul era încrezător că HTML devenise învechit după versiunea 4 și a început să lucreze la XHTML 2, al cărui scop era să conducă web-ul către un viitor luminos XML. Și deși numele a rămas același, noua versiune nu a avut absolut nimic de-a face cu XHTML 1. Mai mult, nu a fost intenționată să fie compatibilă cu predecesorii săi și cu versiunile mai vechi de HTML (și, prin urmare, cu tot conținutul web existent). În schimb, ar fi trebuit să introducă un limbaj nou, curat, lipsit de orice vestigii ale specificațiilor anterioare.

Cu alte cuvinte, a fost o prostie.

Split: W(HATWG) TF?

În rândul Consorțiului se pregătea o răscoală. Era evident că urma să conducă dezvoltarea standardelor – deși noi, curate și frumoase – dar complet neresponsive la nevoile comunității moderne de web designeri și dezvoltatori. Opera, Apple și Mozilla nu au fost în mod clar mulțumiți de acest lucru, deoarece se așteptau la ceva complet diferit - mai mult accent pe formatele care extind posibilitățile de a crea aplicații web.

Începutul modificărilor a fost făcut în 2004 la una dintre întâlniri. Ian Hickson, care la acea vreme era angajat al Opera Software, a înaintat o propunere de dezvoltare a HTML la un nivel care să permită folosirea limbajului pentru aplicații web. Oferta a fost respinsă.

Rebelii dezamăgiți au fost forțați să se desprindă de Consorțiu și să formeze propriul lor grup: Web Hypertext Application Technology Working Group, sau pe scurt WHATWG.

De la aplicații web 1.0 la HTML5

Modul în care a funcționat WHATWG a fost oarecum diferit de cel al W3C. La W3C se ridică probleme, se discută, iar decizia finală se ia prin vot popular. În WHATWG se ridică și se discută și probleme, dar deciziile finale cu privire la ceea ce este inclus în caietul de sarcini și ce nu revin redactorului-șef, Ian Hickson.

La prima vedere, poate părea că sistemul W3C este mai democratic și mai onest, dar practica arată că disputele nesfârșite și certurile interne încetinesc teribil procesul de dezvoltare. În WHATWG, unde toată lumea poate contribui, dar șeful are ultimul cuvânt, lucrurile se mișcă mult mai repede. Redactorul-șef, însă, nu are absolut putere - un grup select de înalți funcționari îi poate contesta decizia în cazul improbabil în care aceasta o va cere.

Inițial, WHATWG s-a concentrat pe două specificații - Web Forms 2.0 și Web Apps 1.0 - ambele destinate a fi extensii la HTML. Dar, de-a lungul timpului, au fost combinate într-unul comun, numit simplu HTML5.

Reuniune

În timp ce WHATWG lucra pe HTML5, W3C a continuat să se încurce cu XHTML 2. Acest lucru nu înseamnă că toată ideea avea să se dea rahat. S-a scufundat încet și încet în el.

În octombrie 2006, Sir Tim Berners-Lee a recunoscut pe blogul său că ideea de a muta web-ul de la HTML la XML a fost stupidă. Câteva luni mai târziu, W3C a emis un nou ghid pentru HTML Working Group: s-a decis cu înțelepciune ca versiunile viitoare de HTML să se bazeze pe munca WHATWG, mai degrabă decât să facă ceva de la zero.

Toate aceste inversări și schimbări de curs au dus la o situație oarecum confuză. Pentru o vreme, W3C a lucrat simultan la două limbaje de marcare complet incompatibile - XTHML 2 și HTML 5 (notă, cu un spațiu) - în timp ce WHATWG, o organizație separată, lucra la specificația HTML5 (fără spațiu) care urma să devină baza unei alte specificații în W3C. Hreanul va crește aici, ce este. Ar fi fost mai ușor să ne dăm seama de succesiunea evenimentelor din Memento și din lucrările lui David Lynch.

XHTML este mort, trăiește sintaxa XHTML

Situația a început să devină mai clară în 2009, când W3C a anunțat că nu vor mai fi actualizări pentru XHTML 2. În esență, ei tocmai au recunoscut oficial că formatul era mort de la naștere.

Cu toate acestea, într-un mod ciudat, în loc să treacă neobservată, moartea XHTML 2 a dat naștere unui fel de fierbere rău intenționată. Oponenții XML au transformat știrile într-un apel de a abandona XHTML 1, deși asta, după cum știm, nu avea nimic în comun cu XHTML 2. La rândul lor, susținătorii XHTML 1, adepți ai sintaxei stricte, erau îngrijorați de faptul că HTML5 va legitima din nou aspectul neglijent.

Acesta din urmă, însă, nu ar trebui să pară o problemă serioasă - așa cum vom lua în considerare mai târziu, fiecare are dreptul de a alege gradul de strictețe al sintaxei HTML5 pentru sine.

Dezvoltare HTML5

Starea actuală a HTML5 nu este la fel de tulbure ca înainte, dar nici nu este foarte transparentă.

Două organizații lucrează în prezent la acest format. WHATWG dezvoltă specificația pe baza principiului „rulați mai întâi, testați mai târziu”. Grupul de lucru HTML W3C, la rândul său, ia această specificație și o supune unui proces de „testare mai întâi, apoi rulare”. După cum puteți vedea, o astfel de cooperare cu greu poate fi numită puternică și eficientă. Dar cel puțin, întrebarea „a pune sau a nu pune un spațiu” în numele standardului pare să fi fost rezolvată (nu este necesar să o pun, dacă este cazul - HTML5).

Cea mai mare îngrijorare în acest moment pentru designerii web care au încercat deja unele dintre capacitățile noului limbaj este întrebarea „Când va fi gata?” Într-un interviu, Ian Hickson a menționat 2022 ca dată la care HTML5 va primi statutul de „recomandare propusă”. Acest lucru a provocat un val de indignare în rândul designerilor, din moment ce nu aveau idee ce înseamnă „propunerea de recomandare”, dar știau sigur că nu aveau destule degete pentru a număra câți ani mai aveau de așteptat până în 2022.

Dacă te uiți la asta, indignarea este nefondată. În acest caz, „recomandarea propusă” înseamnă că, până în acest moment, browserele ar trebui să aibă suport complet pentru toate caracteristicile lingvistice. În acest caz, vizarea 2022 este chiar prea îndrăzneață; Știm cu toții că pentru multe browsere le-a fost greu să ajungă din urmă chiar și standardele existente. Luați Internet Explorer, care a durat mai mult de zece ani pentru a începe chiar să accepte eticheta. .

Data la care într-adevăr trebuie să fim conștienți că este anul 2012, când HTML5 va primi statutul de „recomandare candidat”, adică specificația a fost finalizată și, ca atare, standardul este gata.

Dar, desigur, acest lucru nu va însemna că toate acestea vor fi imediat disponibile pentru utilizare - va trebui să monitorizați modul în care browserele adaugă treptat suport pentru anumite funcții și să începeți să le utilizați pe măsură ce apar. A fost exact același lucru cu CSS 2.1, de fapt: am început să profităm de capacitățile acestui standard, deoarece browserele includeau suport pentru acesta fragmentar. Dacă am fi preferat să așteptăm ca ei să o implementeze în întregime, tot am fi așteptat.

Cu alte cuvinte, nu va exista un moment în care poți spune „Bang, a venit timpul pentru HTML5!” Dar poți începe să lucrezi cu ei acum. Din fericire, această limbă s-a născut nu printr-o revoluție, ci în procesul de evoluție și se bazează pe ceea ce a fost creat înainte de ea. Deci, putem spune că dacă utilizați versiuni anterioare de HTML, utilizați deja HTML5.

Cuprins: 1. Introducere în limbajul HTML Introducere în limbajul HTML. 2. Istoricul creării HTML Istoric al creării HTML. 3. Concepte de bază ale limbajului HTML Concepte de bază ale limbajului HTML 4. Structura unui document Web.Structura unui document Web. 5. Inserarea unui comentariu Inserarea unui comentariu 6. Exemplu de document HTML Exemplu de document HTML. 7. Etichete de formatare a textului. Etichete de formatare a textului. 8. Tag-uri pentru controlul aspectului unei pagini Web Tag-uri pentru controlul aspectului unei pagini Web 9. Tag Tag 10. Culoarea fundalului și a textului Culoarea fundalului și a textului 11. Liste Liste 12. Pagină web cu obiecte grafice Pagină web cu grafică obiecte.

Introducere în limbajul HTML HTML este un limbaj de marcare a documentelor în mediul WEB. Ceea ce vedeți atunci când vizualizați o pagină pe Internet este interpretarea de către browser a textului HTML. Pentru ca browserul să afișeze corect formatarea, de exemplu text, de ex. a împărțit-o în paragrafe, citate evidențiate, titluri, liste etc. trebuie să i se spună cumva că acesta este un titlu, acesta este un paragraf etc. Este exact ceea ce face limbajul html. Pentru a vedea codurile HTML ale unei pagini de pe Internet, faceți clic dreapta pe pagină și selectați Vizualizare sursă (sau „Vizualizare cod HTML”) din meniul derulant. Conţinut

Istoria creării HTML (Hyper Text Markup Language) Câteva date: 1945: 1945: Omul de știință american, consilier științific al președintelui Vannevar Bush exprimă ideea hipertextului Anul: 1968: Douglas Engelbart demonstrează activitatea link-urilor hipertext în le-a creat procesor de text. Conţinut

Anii 1960: Anii 1960: angajații IBM au creat limbajul GML (General Markup Language), care a fost destinat utilizării pe computerele din familia IBM. Limbajul GML a fost extins ulterior, iar în anii 80 a fost standardizat de ISO (International Organization for Standardization). Acest mod de marcare puternic și versatil, numit SGML (Standard General Markup Language), a fost folosit de Departamentul Militar al SUA pentru documentația tehnică în anii 1980: fizicianul Tim Berners-Lee, angajat al CERN (Centrul European de Cercetare Nucleară), în The baza limbajului dezvoltat a fost limbajul SGML și tehnicile de lucru cu hipertextul, motiv pentru care numele limbajului pe care l-a creat - HTML - este conectat. Noul limbaj a folosit constructele de bază ale SGML pentru a descrie documente și legături hipertext. Câteva date: Cuprins

Termenul „hipertext” a fost inventat pentru prima dată de Ted Nelson în 1969. Hipertextul este un document electronic care conține link-uri către alte documente. Conţinut

Structura unui document Web. ..., Întregul conținut al fișierului paginii de Internet este conținut într-un container... care indică browserului că acest text este un document HTML și poate conține etichete pe care browserul trebuie să le identifice, să le recunoască și să le interpreteze. O pagină tipică de Internet (HEAD)(BODY) O pagină tipică de Internet constă din două părți: un antet (HEAD) și un corp (BODY). Conţinut

Structura unui document Web. începutul containerului de document HTML începutul containerului antet începutul liniei container - titlul paginii ... linia titlului paginii sfârşitul rândului containerului - titlul paginii sfârşitul containerului titlului începutul paginii corpul containerului ... corpul (tot conţinutul) sfârşitul paginii de corp de pagină container sfârșitul containerului de document HTML Această structură de bază în cea mai simplă formă poate fi prezentată clar după cum urmează: Cuprins

Structura unui document Web. Șirul de titlu pe care îl specificați va fi afișat în titlul ferestrei browser atunci când această pagină este vizualizată în ea, precum și (după ce pagina este postată pe Internet) în listele furnizate de serverele de căutare. Conţinut

Etichete de formatare a textului. afișează textul cu caractere aldine. afișează textul cu caractere cursive afișează textul cu font subliniat. și afișați textul cu o linie orizontală prin el. afișează textul într-un font mai mare decât porțiunea neetichetată a textului afișează textul inclus într-un font mai mic decât restul textului: mută textul sub nivelul liniei și îl afișează într-un font mai mic. Recomandat pentru tipărirea indicilor matematici: deplasează textul deasupra nivelului liniei și îl afișează într-o dimensiune mai mică a fontului. Această etichetă poate fi folosită pentru a specifica puterile numerelor: Conținut

Etichetă O etichetă vă permite să schimbați fontul pe care browserul îl folosește pentru a vizualiza o pagină Web. O etichetă poate avea următorii parametri: FACE – specifică numele fontului în care va fi afișat textul. SIZE – setează dimensiunile fonturilor în unități convenționale de la 1 (cel mai mic) la 7 (cel mai mare). Este în general acceptat că o dimensiune normală a fontului corespunde unei valori de 3. CULOARE – setează culoarea fontului, care poate fi specificată folosind nume standard sau un set de cifre hexazecimale. Conţinut

Culoarea fundalului și a textului Știm deja cum să schimbăm culoarea textului, dar pentru a face acest lucru trebuia să o includem în etichete de font, iar acest lucru nu este întotdeauna convenabil. Uneori, este mai bine să setați culoarea textului pentru întregul document. De asemenea, puteți seta o imagine de fundal. Iată atributele necesare: BACKGROUND – definește imaginea pentru a „umple” fundalul. Valoarea este specificată ca o adresă URL completă sau numele unui fișier cu o imagine în format GIF sau JPG (mai multe despre asta mai târziu). BGCOLOR – definește culoarea de fundal a documentului. TEXT – determină culoarea textului din document. Toate sunt înregistrate pentru elementul BODY. Valorile culorilor sunt specificate fie printr-o valoare hexazecimală RGB, fie printr-una dintre cele 16 culori de bază. Conţinut

Culoare de fundal și text Exemplu: Acest text va fi roșu pentru că am schimbat culoarea textului în eticheta BODY și acum tot textul de pe pagină va fi roșu implicit. Acest paragraf va avea text verde pentru că l-am împachetat în etichete de font și am dat este culoarea corespunzătoare. Acum textul va fi din nou roșu Cuprins

Liste Fiecare element de listă începe cu o etichetă.Limbajul HTML oferă un set special de etichete pentru prezentarea informațiilor sub formă de liste de următoarele tipuri: Marcatori (); Numerotat(/); lista de definiții (/). Termen. Definiția sa... Cuprins

Pagina web cu obiecte grafice. Imaginile sunt parte integrantă a oricărui site de pe Internet. Sunt folosite peste tot, așa că haideți să ne dăm seama ce este. Există trei tipuri de fișiere imagine care pot fi inserate în paginile dvs.: GIF (Graphics Interchange Format) JPG/JPEG (Joint Photographic Experts Group) PNG (Portable Network Graphics) Conținut

Pagina web cu obiecte grafice. Câteva cuvinte despre formate: GIF - folosește doar 256 de culori și, în consecință, este mai potrivit pentru desene cu un număr mic de nuanțe. Acest format acceptă transparența imaginii. JPEG este un format de imagine care folosește până la un milion de culori. Folosit de obicei pentru fotografii și grafică de înaltă calitate (cu un număr mare de nuanțe). PNG este un format relativ nou. Depășește JPEG și GIF în multe privințe: milioane de culori și compresie eficientă. De asemenea, susține transparența. În ce format să luați imaginile depinde de dvs., dar încercați să obțineți o calitate maximă cu o dimensiune minimă. Conţinut

Pagina web cu obiecte grafice. Pentru a plasa imagini în documente HTML, utilizați o etichetă al cărei parametru SRC specifică locația fișierului imagine. De exemplu: - imaginea aflată în fișierul picture.gif va fi plasată în documentul HTML; - o imagine va fi plasată în documentul HTML, aflat în fișierul Tile.bmp, care se află în folderul Imagini, aflat în același folder cu documentul HTML. Conţinut

Pagina web cu obiecte grafice. Când includeți o imagine într-un document, puteți specifica locația acestuia în raport cu text sau alte elemente ale paginii. Metoda de aliniere a imaginii este specificată de valoarea parametrului ALIGN al etichetei. Mai jos sunt câteva valori posibile pentru acest parametru: LEFT Potrivește imaginea în marginea din stânga a ferestrei. Textul se înfășoară în jurul imaginii din partea dreaptă. DREAPTA Imaginea este apăsată în marginea dreaptă a ferestrei. Textul se înfășoară în jurul imaginii din partea stângă. Conţinut

Traducere: Vlad Merzhevich

Am găsit recent un citat de la dezvoltatorii Mozilla despre tensiunile din jurul dezvoltării standardelor:

Implementările și specificațiile trebuie să curgă împreună într-un dans grațios. Nu doriți ca implementarea să se întâmple înainte ca specificația să fie terminată, deoarece oamenii vor deveni dependenți de detaliile implementării și asta va împiedica specificația. Cu toate acestea, nici nu doriți ca specificația să fie finalizată înainte de implementare, atunci autorii vor începe să experimenteze implementarea atunci când aveți nevoie de feedback. Există o tensiune inevitabilă aici, dar trebuie doar să oscilăm în alegere până la final.

Păstrați acest citat în minte și permiteți-mi să vă explic despre ascensiunea HTML5.

tipuri MIME

Această carte este despre HTML5, nu despre versiunile anterioare de HTML și nu despre versiunile de XHTML. Dar pentru a înțelege istoria HTML5 și motivația din spatele acestuia, trebuie mai întâi să înțelegeți câteva puncte tehnice. În special, tipurile MIME.

De fiecare dată când browserul dvs. solicită o pagină, serverul web trimite „anteturi” înainte de a trimite codul real al paginii. Aceste anteturi sunt în general invizibile, deși există instrumente pentru dezvoltatori web care le fac vizibile dacă sunteți interesat. Anteturile sunt importante deoarece spun browserului dvs. cum să interpreteze marcajul paginii. Cel mai important antet se numește Content-Type și arată astfel:

Tip de conținut: text/html

„text/html” se numește „tipul de conținut” sau „tipul MIME” al paginii. Acest antet definește doar ce este de fapt resursa și cum să o afișeze. Imaginile au propriile lor tipuri MIME (image/jpeg pentru JPEG, image/png pentru PNG etc.). Fișierele JavaScript au propriul lor tip MIME. CSS au propriul lor tip MIME. Toate au propriul lor tip MIME. Internetul rulează pe tipuri MIME.

Desigur, în realitate totul este mult mai complicat. Prima generație de servere web (vorbesc despre servere web din 1993) nu a trimis antetul Content-Type pentru că nu exista (nu a fost inventat până în 1994). Din motive de compatibilitate, la revenirea datei la 1993, unele browsere populare ignoră anteturile tip Content în anumite circumstanțe (aceasta se numește „sniffing de conținut”). Dar, de regulă, tot ceea ce ați vizualizat vreodată pe Web - pagini HTML, imagini, scripturi, videoclipuri, PDF-uri etc. - v-a fost oferit cu un anumit tip MIME în antetul Content-Type.

Pune-ți pălăria deoparte deocamdată. Vom reveni la asta mai târziu.

O lungă digresiune asupra modului în care sunt realizate standardele

De ce folosim element ? Aceasta nu este o întrebare pe care o auzi în fiecare zi. Evident, cineva a creat-o. Aceste lucruri nu apar din senin. Fiecare element, fiecare atribut, fiecare caracteristică HTML pe care ați folosit-o vreodată - cineva le-a creat, a decis cum ar trebui să funcționeze și a scris totul. Acești oameni nu sunt zei și nu sunt fără cusur. Sunt oameni obișnuiți. Oameni inteligenți, sunt sigur. Dar doar oameni.

Unul dintre lucrurile grozave despre standardele open source este că te poți întoarce în timp și poți răspunde la diferite întrebări. Discuțiile au loc prin intermediul unei liste de corespondență, care sunt de obicei arhivate și disponibile public. Așa că am decis să fac puțină „arheologie poștală” pentru a încerca să răspund la întrebarea „De ce folosim elementul ?. Trebuie să mă întorc la înainte de a exista o organizație numită World Wide Web Consortium (W3C). M-am întors în primele zile ale web-ului, când puteai număra numărul de servere web pe două mâini și poate pe o pereche de degete de la picioare.

Există o serie de greșeli de scriere în citatele următoare. Am decis să le las neatinse pentru acuratețea istorică.

Aș dori să sugerez o nouă etichetă HTML suplimentară:

Argument necesar SRC="url"

Acesta este numele bitmap-ului sau al fișierului grafic pentru browserul care încearcă să-l tragă pe web și să îl interpreteze ca o imagine, care trebuie inclusă în text atunci când eticheta este creată.

(Nu există nicio etichetă de închidere aici, este doar o singură etichetă.)

Browserele trebuie să fie flexibile în ceea ce privește formatele grafice pe care le acceptă. Xbm și Xpm sunt bine acceptate, de exemplu. Dacă browserul nu poate interpreta un anumit format, poate face tot ce dorește (X Mosaic va scoate un bitmap ca substituent în mod implicit).

Acest lucru va necesita funcționalitate pentru X Mosaic, funcționează pentru noi și l-am folosit cel puțin pe plan intern. Desigur, sunt deschis la sugestii cu privire la modul în care ar trebui să fie tratat acest lucru în HTML, dacă aveți o idee mai bună decât cea sugerată, vă rugăm să-mi spuneți. Îmi dau seama că am scris vag despre formatele de imagine, dar nu văd nicio alternativă decât să spun doar „lasă browserul să facă ce poate” și să aștept soluția perfectă (MIME, într-o zi, poate).

Am ceva similar în Midas 2.0 (folosit aici la SLAC și care urmează să fie lansat public săptămâna aceasta), cu excepția faptului că numele sunt toate diferite și există un argument suplimentar NAME="name". Are aproape exact aceeași funcționalitate ca și eticheta IMG pe care o sugerați, de exemplu.

Ideea din spatele parametrului nume ar permite browserului să instaleze imagini „încorporate”. Dacă numele se potrivește cu imaginea „încorporată”, atunci acesta este folosit în loc să mergeți și să obțineți imaginea. numele poate acționa și ca un indiciu pentru browserele „mod linie” pentru a pune un caracter în locul imaginii.

Nu mi-a păsat prea mult de parametri sau de numele etichetelor, dar ar avea sens să folosesc aceleași lucruri. Nu îmi pasă foarte mult de abrevieri, așa că de ce nu IMAGE= și SOURCE=. Prefer în continuare ICONA pentru că este mai simplă decât IMAGINE și ar trebui să fie mică, dar poate ICONA este un cuvânt supraîncărcat?

Midas este un alt browser timpuriu, un contemporan al lui X Mosaic. Este multiplatformă și rulează pe Unix și VMS. SLAC se referă la Stanford Linear Accelerator Center, acum SLAC National Accelerator Laboratory, care a rulat primul server web din SUA (de fapt, primul server web din afara Europei). Când Tony a scris această postare, SLAC era cel mai vechi de pe WWW, având găzduit cinci pagini pe serverul său web timp de 441 de zile.

Tony continuă:

În timp ce suntem pe tema noilor etichete, am o altă idee, o etichetă oarecum similară pe care aș dori să o susțin în Midas 2.0. Practic cam asa:

Ideea este că cel de-al doilea document este inserat în primul document în locul în care apare această etichetă. În principiu, respectivul document poate fi orice, dar scopul principal este acela de a permite imaginilor (în acest caz de dimensiuni arbitrare) să fie încorporate în documente. Din nou, ideea este că odată cu apariția HTTP2, formatele documentelor incluse vor fi discutate separat.

La câteva ore după ce Tony a trimis mesajul, Tim Berners-Lee a răspuns.

M-am gândit că ilustrațiile vor fi prezentate astfel:

Ilustrare

unde valorile raportului denotă

EMBED Introduceți aici dacă este disponibil
PREZENT Afișează când este prezentat documentul original

Rețineți că puteți avea diferite combinații ale acestora, iar dacă browserul nu acceptă niciunul, nu îl strica.

[I] pot vedea că aceasta este folosită ca metodă de selectare a unei pictograme prin link-uri imbricate. Hmmm. Dar nu mi-ar plăcea o etichetă specială.

Această propunere nu a fost implementată, dar atributul rel este încă aici.

Ar fi bine dacă ar exista o modalitate de a specifica tipul de conținut, de ex.

Dar sunt complet dispus să trăiesc cu cerința ca să specific tipul de conținut prin extensia de fișier.

Această propunere nu a fost implementată, dar Netscape a adăugat ulterior suport pentru încorporarea obiectelor media cu elementul .

Deși imaginile sunt în partea de sus a listei mele de dorințe, în mijlocul tipurilor din browserele WWW, nu cred că ar trebui să adăugăm pe rând cârlige specifice media. Ce sa întâmplat cu entuziasmul pentru utilizarea mecanismului MIME?

Acesta nu este un înlocuitor pentru viitoarea utilizare a MIME ca mecanism standard pentru documente; oferă implementarea necesară și simplă a funcționalității care este necesară indiferent de MIME.

Să uităm de MIME pentru moment dacă aceasta este o problemă efemeră. Obiecția mea a fost la discuția despre „cum vom sprijini imaginile inline” mai degrabă decât „cum vom susține imaginile inline în medii”.

În caz contrar, cineva într-o săptămână va sugera „inserați o etichetă nouă " pentru audio.

Nu ar trebui să fie multe cheltuieli atunci când treceți de la ceva generic.

În retrospectivă, preocupările lui Jay par justificate. A durat puțin peste o săptămână, dar în sfârșit au fost adăugate elemente noi la HTML5

Răspunzând postării inițiale a lui Jay, Dave Ragett a spus:

Exact! Vreau să mă uit la întreaga gamă de imagini/linii posibile de tip de artă împreună cu o discuție despre format. Tim a menționat despre suportul pentru zonele pe care se poate face clic din interiorul imaginilor, acest lucru este de asemenea important.

De fapt, poate ar trebui să ne gândim la un limbaj de grafică procedurală de uz general, cu ajutorul căruia putem insera hyperlinkuri arbitrare atașate pictogramelor, imaginilor, textului sau mai mult. A mai văzut cineva capacitățile Intermedia în acest sens?

Verificați alte sisteme care au aceste concepte (destul de valoroase), Andrew și Slate. Andrew este construit cu _inserții_, fiecare dintre ele are mai multe tipuri interesante, cum ar fi text, bitmap, grafică, animație, mesaje, foi de calcul etc. Conceptul de imbricare recursivă arbitrară este prezent, astfel încât o inserție de orice fel poate fi imbricată în orice alt tip care acceptă imbricarea. De exemplu, un insert poate fi încorporat oriunde în textul unui widget text, sau în orice zonă dreptunghiulară a unui widget de desen sau în orice celulă a unei foi de calcul.

Iată părerea mea. Cel mai bun mod de a reda imagini pe WWW este utilizarea MIME. Sunt sigur că PostScript acceptă deja subtiparea MIME și face o treabă foarte bună de a combina textul și grafica.

Dar nu se poate face clic, zici? Da ai dreptate. Bănuiesc că răspunsul la aceasta este deja în Display PostScript. Chiar dacă nu este adăugat la PostScript standard, acest lucru este banal. Definiți o comandă de legătură care specifică o adresă URL și utilizează calea curentă ca zonă închisă pentru buton. Deoarece PostScript este bun la a face față căilor, crearea unui buton personalizat este trivială.

Display PostScript a fost o tehnologie de redare a ecranului dezvoltată în comun de Adobe și NeXT.

Această propunere nu a fost implementată, dar ideea că cel mai bun mod de a repara HTML este înlocuirea lui cu ceva complet diferit încă mai apare din când în când.

HTTP2 permite unui document să conțină orice tip cu care utilizatorul a spus că poate lucra, nu doar tipurile MIME înregistrate. Deci poți experimenta. Da, cred că există un caz pentru PostScript cu hipertext. Nu știu dacă Display PostScript este suficient. Știu că Adobe încearcă să-și creeze propriul „PDF” centrat pe PostScript, care va avea link-uri și va putea fi citit de către vizualizatorul proprietar.

Cred că un limbaj de suprapunere comun pentru link-uri (bazat pe Hytime?) ar permite standardelor de hipertext și grafică/video să evolueze separat, ceea ce le-ar ajuta pe ambele.

Lăsați eticheta IMG să includă INCLUDE și lăsați-o să se refere la un tip de document arbitrar. Sau EMBED dacă INCLUDE sună ca cpp include, astfel încât oamenii să poată furniza cod sursă SGML pentru analiza linie cu linie - nu așa cum este prevăzut.

Înapoi la imaginile inline din nou - sunt aproape de lansarea Mosaic 0.10 care acceptă imagini GIF și XBM așa cum am menționat mai devreme...

Nu suntem pregătiți să acceptăm INCLUDE/EMBED în acest moment... Deci probabil că vom merge cu (nu ICONA, deoarece nu toate imaginile inline pot fi numite în mod rezonabil pictograme). În prezent, imaginile inline nu vor conține în mod explicit un tip de conținut; în viitor, intenționăm să sprijinim acest lucru (împreună cu o adaptare generală MIME). De fapt, rutina de citire a imaginilor pe care o folosim în prezent descoperă formatul din mers, așa că extensia fișierului nu este atât de importantă.

Linie continuă

Sunt extrem de pasionat de toate aspectele acestei conversații de aproape 17 ani, care a dus la crearea unui element HTML care a fost folosit pe aproape fiecare pagină web publicată vreodată. Să luăm în considerare:

HTTP încă există. HTTP a evoluat cu succes de la 0.9 la 1.0 și mai târziu la 1.1. Și încă se dezvoltă.
HTML încă există. Acesta este un format de date rudimentar - nici măcar nu acceptă imagini în linie! - dezvoltat cu succes în 2.0, 3.2, 4.0. HTML este o linie continuă. O linie strâmbă, noduri, încurcate, desigur. Au existat multe „ramuri moarte” în arborele evolutiv, locuri în care oamenii cu gândire standard s-au devansat (și i-au depășit pe autori și interpreți). Dar cu toate acestea. Suntem aici în 2010, iar paginile web din 1990 sunt încă afișate în browserele moderne. Tocmai am încărcat unul în browserul telefonului meu mobil pe cel mai recent Android și nici măcar nu mi-a cerut să „Vă rugăm să așteptați până când este importat formatul moștenit...”.
HTML a fost întotdeauna o conversație între dezvoltatorii de browsere, autori, tociștii standardelor și alți oameni care pur și simplu apar și vor să vorbească despre parantezele unghiulare. Cele mai de succes versiuni de HTML au fost „specificații retro”, ajungând din urmă cu lumea în timp ce încercau să o împingă în direcția corectă. Oricine vă spune că HTML ar trebui să fie „curat” (probabil ignorând dezvoltatorii browserului sau ignorând autorii sau ambele) este pur și simplu dezinformat. HTML nu a fost niciodată curat și toate încercările de a-l curăța au eșuat spectaculos și sunt egalate doar de încercările de a-l înlocui.
Niciunul dintre browserele din 1993 nu există sub nicio formă recunoscută. Netscape Navigator a fost abandonat în 1998 și rescris de la zero pentru a crea Mozilla Suite, din care Firefox s-a desprins apoi. Internet Explorer a început ca un umil „de unde să începem” în „Microsoft Plus!” pentru Windows 95”, unde a venit la pachet cu câteva teme desktop și un joc de pinball.
Unele dintre sistemele de operare din 1993 încă există, dar niciunul dintre ele nu este relevant pentru web-ul modern. Majoritatea oamenilor „conștienți” accesează Internetul pe un PC care rulează Windows 2000 sau o versiune ulterioară, un Mac care rulează Mac OS X, un PC care rulează Linux delicios sau un dispozitiv portabil precum un iPhone. În 1993, Windows era la versiunea 3.1 (și concura cu OS/2), Mac-urile rulau System 7, Linux era distribuit prin Usenet.
Unii oameni sunt încă implicați și încă participă la ceea ce acum numim pur și simplu „standarde web”. Au trecut aproape 20 de ani acum. Și unii au fost implicați în precursorii HTML-ului, începând cu anii 1980 și mai devreme.
Apropo de predecesori... Cu popularitatea supremă a HTML și a web-ului, este ușor să-i uiți pe cei care au modelat designul formatelor și sistemelor moderne. Andrew? Intermedia? HyTime? Și HyTime nu a fost un proiect de cercetare antediluvian, a fost un standard ISO. A fost aprobat pentru uz militar. Era o mare afacere. Și puteți citi singur despre asta... .

Dar nimic din toate acestea nu răspunde la întrebarea inițială: de ce folosim elementul ? De ce nu element ? Sau element ? De ce nu hyperlinkuri cu un atribut include sau o combinație de valori rel? De ce element ? Este foarte simplu pentru că Marc Andreessen l-a implementat și codul implementat a câștigat.

Asta nu înseamnă că toate codurile implementate au câștigat, până la urmă au fost implementate și Andrew și Intermedia și HyTime. Codul este necesar, dar nu suficient pentru succes. Cu siguranță nu vreau să spun că implementarea codului înainte de lansarea standardului este cea mai bună soluție. Element Brand nu definește formate grafice de bază; nu specifică cum ar trebui să curgă textul în jurul acestuia; nu acceptă text alternativ sau conținut alternativ pentru browserele mai vechi. Și 17 ani mai târziu, încă ne luptăm cu adulmecarea conținutului și este încă o sursă de vulnerabilități nebunești de securitate. Și puteți urmări totul în urmă cu 17 ani, prin Marele Război al browserelor, până la 25 februarie 1993, când Marc Andreessen a remarcat în mod casual: „MIME, într-o zi, poate” și apoi și-a implementat codul indiferent de situație.

Cronologia dezvoltării HTML din 1997 până în 2004

În decembrie 1997, World Wide Web Consortium (W3C) a publicat HTML 4.0 și a închis prompt Grupul de lucru HTML. La mai puțin de două luni mai târziu, un grup de lucru W3C separat a publicat XML 1.0. La trei luni după aceea, cei care conduc W3C au organizat un atelier numit „Shaping the Future of HTML” pentru a răspunde la întrebarea: „W3C a abandonat HTML?” Acesta a fost răspunsul lor:

În timpul discuției, s-a decis că extinderea ulterioară a HTML 4.0 ar fi dificilă, ca și cum am fi convertit 4.0 în aplicații XML. Calea propusă vă va elibera de restricții pentru a începe o nouă viață cu următoarea generație de HTML bazată pe un set de etichete XML.

W3C a relansat Grupul de lucru HTML pentru a crea acest „set de etichete XML”. Primul lor pas în decembrie 1998 a fost să elaboreze o specificație intermediară care pur și simplu a transformat HTML în XML fără a adăuga elemente sau atribute noi. Această specificație a devenit ulterior cunoscută sub numele de „XHTML 1.0”. Acesta a definit un nou tip MIME pentru documentele XHTML - application/xhtml+xml. Cu toate acestea, pentru a facilita migrarea paginilor HTML4 existente, acesta a inclus și Anexa C, care „rezuma liniile directoare de proiectare pentru autorii care doresc ca documentele lor XHTML să fie redate pe agenții utilizatori HTML existenți”. Anexa C vă spune că permite autorului așa-numitelor pagini „XHTML” să le servească în continuare cu tipul MIME text/html .

Următorul obiectiv au fost formularele web. În august 1999, același grup de lucru HTML a publicat prima versiune a formularelor extinse XHTML. Ea a stabilit așteptări în primul paragraf:

După o analiză atentă, Grupul de lucru HTML a stabilit că obiectivele următoarei generații de formulare nu sunt aceleași cu menținerea compatibilității cu browserele concepute pentru versiunile anterioare de HTML. Scopul nostru este să asigurăm puritatea noului model de formulare (XHTML Extended Forms) pe baza unui set de cerințe clar definite. Aceste cerințe sunt descrise în acest document și se bazează pe experiența cu o gamă largă de aplicații de formulare.

Câteva luni mai târziu, „XHTML Extended Forms” a fost redenumit „XForms” și mutat în propriul grup de lucru. Acest grup a lucrat în paralel cu HTML Working Group și a publicat în cele din urmă prima versiune a XForms 1.0 în octombrie 2003.

Între timp, odată cu trecerea la XML complet, Grupul de lucru HTML și-a pus ochii pe crearea „următoarei generații de HTML”. În mai 2001, a publicat prima revizuire a XHTML 1.1, care a adăugat doar câteva caracteristici minore peste XHTML 1.0, dar a închis și lacuna „Apendicele C”. Începând cu versiunea 1.1, toate documentele XHTML trebuie să fie difuzate cu tipul MIME application/xhtml+xml.

Tot ce știi despre XHTML este greșit

De ce sunt atât de importante tipurile MIME? De ce tot revin la ei? Trei cuvinte: tratarea draconiană a erorilor. Browserele au fost întotdeauna indulgenți cu HTML. Dacă ați creat o pagină HTML, dar ați uitat eticheta, browserul va afișa în continuare pagina (unele etichete determină implicit finalizarea si inceputul ). Ar trebui să presupuneți imbricarea ierarhică a etichetelor - acestea sunt închise în ordine inversă - dar dacă creați cod ca , browserele se vor descurca (într-un fel sau altul) și vor continua fără a afișa un mesaj de eroare.

După cum v-ați putea aștepta, faptul că HTML rupt funcționează în browsere a permis autorilor să creeze pagini HTML rupte. O mulțime de pagini sparte. Potrivit unor estimări, peste 99% dintre paginile HTML de pe Web astăzi conțin cel puțin o eroare. Dar, deoarece aceste erori nu forțează browserele să afișeze mesaje de eroare vizibile, nimeni nu le remediază vreodată.

W3C a văzut asta ca pe o problemă fundamentală cu web-ul și s-a apucat să o rezolve. XML, publicat în 1997, s-a desprins de tradiția de a ierta clienții și a decretat că toate programele care consumă XML trebuie să trateze așa-numitele erori de „sintaxă” ca fiind fatale. Acest concept de eșec la prima greșeală a devenit cunoscut sub numele de „tratarea erorilor draconiene”, similar liderului grec Draco, care a instituit pedeapsa cu moartea pentru cea mai mică încălcare a legilor sale. Când W3C a reformulat HTML ca un vocabular XML, a impus ca toate documentele transmise cu noul tip MIME application/xhtml+xml să fie supuse unei gestionări draconice a erorilor. Dacă există cel puțin o eroare de sintaxă în pagina XHTML - cum ar fi o etichetă uitată sau etichete de început și de sfârșit imbricate incorect - browserele nu vor avea de ales decât să oprească procesarea și să afișeze un mesaj de eroare utilizatorului final.

Această idee nu este populară peste tot. Cu o rată de eroare estimată la 99% pe paginile existente, probabilitatea extinsă de a fi afișate erori pentru utilizatorul final și lipsa de noi funcții în XHTML 1.0 și 1.1, autorii ignoră în mare măsură application/xhtml+xml pentru a justifica costul. Dar asta nu înseamnă că au ignorat XHTML ca întreg. Oh, cu siguranță nu. Anexa C la specificația XHTML 1.0 a dat autorilor lumii o lacună: „Faceți ceva care să semene cu sintaxa XHTML, dar lăsați-l să fie transmis cu tipul MIME text/html”. Și exact asta au făcut mii de dezvoltatori web: au „actualizat” sintaxa XHTML, dar au continuat să redeze cu tipul MIME text/html.

Chiar și astăzi, milioane de pagini web revendică XHTML. Ele încep cu un tip de document XHTML pe prima linie, folosesc nume de etichete cu minuscule, ghilimele în jurul atributelor și adaugă o bară oblică după elementele goale precum
Și

. Dar doar o mică parte din aceste pagini sunt servite cu tipul MIME application/xhtml+xml, care include gestionarea draconiană a erorilor XML. Orice pagină transmisă cu tipul MIME text/html - indiferent de tipul de document, sintaxă sau stilul de codificare - va fi analizată de un parser HTML indulgent, ignorând în tăcere orice eroare de marcare și nu alertează niciodată utilizatorii finali (sau pe oricine altcineva), chiar dacă pagina este tehnică. spart.

XHTML 1.0 a inclus această lacună, dar XHTML 1.1 a închis-o, iar XHTML 2.0 neterminat a continuat tradiția de a solicita o gestionare draconiană a erorilor. Acesta este motivul pentru care există miliarde de pagini care pretind a fi XHTML 1.0 și doar câteva care pretind a fi XHTML 1.1 (sau XHTML 2.0). Deci folosești de fapt XHTML? Verificați tipul MIME (de fapt, dacă nu știți ce tip MIME utilizați, aproape vă pot garanta că utilizați și text/html ). Atâta timp cât nu treceți paginile dvs. cu tipul MIME application/xhtml+xml , așa-numitul „XHTML” este XML numai în nume.

Viziune competitivă

În iunie 2004, W3C a organizat un workshop despre aplicații web și documente compuse. La acest atelier au participat reprezentanți de la trei browsere, o companie de dezvoltare web și alți membri W3C. Grupuri de părți interesate, inclusiv Fundația Mozilla și Opera Software, și-au subliniat viziunile concurente pentru viitorul web: evoluția standardului HTML 4 existent include noi capabilități pentru dezvoltatorii moderni de aplicații web.

Următoarele șapte principii reflectă ceea ce considerăm cele mai importante cerințe pentru această lucrare.
Compatibilitate inversă, cale de migrare clară Tehnologiile aplicațiilor web ar trebui să se bazeze pe tehnologii familiare autorilor și să includă HTML, CSS, DOM și JavaScript. Caracteristicile de bază ale unei aplicații web ar trebui făcute folosind comportamentul, scripturile și foile de stil în IE6 astăzi, astfel încât autorii să aibă o cale clară de migrare. Orice soluție care nu poate fi folosită de agentul utilizator actual fără pluginurile necesare probabil nu poate avea succes. Gestionarea erorilor de wellness Gestionarea erorilor în aplicațiile web ar trebui să fie definită la un nivel de granularitate în care agenții utilizator nu ar trebui să-și inventeze propriile mecanisme de gestionare a erorilor sau să facă inginerie inversă a altor agenți utilizator. Utilizatorii nu trebuie să fie supuși erorilor de proprietate. Specificațiile trebuie să specifice comportamentul exact de recuperare pentru fiecare scenariu de eroare posibil. Tratarea erorilor ar trebui definită în principal în termeni de recuperare grațioasă a erorilor (ca în CSS), mai degrabă decât ca o eșec evident și catastrofal (ca în XML). Utilizare practică Fiecare funcție care intră în specificația unei aplicații web trebuie să fie justificată de utilizarea practică. Reversul nu este întotdeauna adevărat: fiecare caz de utilizare nu garantează neapărat o nouă caracteristică. Este de preferat să folosiți argumente bazate pe site-uri reale în care autorii au folosit anterior o soluție proastă pentru a ocoli limitarea. Scripturile rămân, dar ar trebui evitate acolo unde se poate utiliza un marcaj convenabil. Scripturile ar trebui să fie neutre pentru dispozitiv și vizualizare cât mai mult posibil pe anumite dispozitive (de exemplu, dacă nu sunt incluse în XBL). Trebuie evitată crearea de profiluri specifice dispozitivului. Autorii ar trebui să se poată baza pe aceeași funcționalitate realizată în versiunile desktop și mobile ale aceluiași agent utilizator. Un proces deschis Web-ul a fost benefic deoarece a fost dezvoltat într-un mediu deschis. Aplicațiile web vor fi nucleul web, iar dezvoltatorul lor trebuie să fie deschis. Listele de corespondență, arhivele și proiectele de specificații ar trebui să fie permanent vizibile pentru public.

Într-un sondaj informal, participanții la atelier au fost întrebați: „Ar trebui W3C să dezvolte extensii declarative ale HTML și CSS și să extindă în mod necesar DOM-ul pentru a răspunde cerințelor aplicațiilor web de nivel mediu, spre deosebire de API-urile complexe ale unui sistem de operare complet? (sugerat de Ian Hickson, Opera Software)." Votul a fost 11 pentru, 8 împotrivă. În rezumatul atelierului, W3C a scris: „În acest moment, W3C nu intenționează să furnizeze nicio resursă subiectului sondajului informal al terților: Extensii HTML și CSS pentru aplicații web, dincolo de tehnologiile dezvoltate în baza chartei actuale. Grupul de lucru W3C.”

În fața acestei decizii, cei care și-au propus dezvoltarea formularelor HTML și HTML au avut doar două opțiuni: să renunțe sau să-și continue munca în afara W3C. Au ales-o pe cea din urmă și au înregistrat domeniul whatwg.org, iar grupul de lucru WHAT s-a născut în iunie 2004.

CE grup de lucru?

Ce dracu este grupul de lucru WHAT? Îi voi lăsa să-și explice singuri:

Grupul de lucru WHAT este o colaborare gratuită, informală și deschisă a furnizorilor de browsere și a părților interesate. Grupul își propune să dezvolte specificații bazate pe HTML și tehnologii aferente pentru a facilita implementarea de aplicații web interoperabile cu scopul de a oferi rezultate organizației standardelor. Această prevedere va forma apoi baza lucrării formale de extensie HTML în cursul de standarde.

Crearea acestui forum urmează câteva luni de corespondență privată cu privire la specificațiile pentru fiecare tehnologie. Accentul s-a pus pe extinderea formularelor HTML4 pentru a suporta funcțiile solicitate de autori, fără a întrerupe compatibilitatea cu conținutul existent. Acest grup a fost creat pentru a asigura dezvoltarea viitoare a acestor specificații și va fi complet deschis printr-o arhivă publică, listă de corespondență accesibilă.

Expresia cheie aici este „fără a întrerupe compatibilitatea inversă”. XHTML (excluzând lacuna din Anexa C) nu este compatibil cu HTML. Necesită un tip MIME complet nou, care include gestionarea erorilor draconice pentru orice conținut transmis cu acel tip MIME. XForms nu sunt compatibile cu formularele HTML, deoarece pot fi utilizate numai în documentele care sunt trimise cu noul tip MIME XHTML, ceea ce înseamnă că XForms include și gestionarea draconiană a erorilor. Toate drumurile duc la MIME.

În loc să arunce peste un deceniu de investiții în HTML și să facă 99% din paginile web existente inutilizabile, grupul de lucru WHAT a decis să adopte o abordare diferită: documentarea algoritmilor de gestionare a erorilor „îngăduitori” pe care browserele îi folosesc de fapt. Browserele iartă întotdeauna erorile HTML, dar nimeni nu s-a obosit vreodată să scrie exact cum au făcut-o. NCSA Mosaic are propriii algoritmi pentru a trata paginile sparte, iar Netscape a încercat să le potrivească. Internet Explorer încearcă apoi să concureze cu Netscape. Apoi Opera și Firefox încearcă să concureze cu Internet Explorer. Safari încearcă apoi să concureze cu Firefox. Și așa mai departe, până în zilele noastre. Pe parcurs, dezvoltatorii au ars mii și mii de ore încercând să-și facă produsul compatibil cu concurența.

Dacă asta pare o cantitate nebunească de muncă, asta este pentru că este. Sau, mai degrabă, a fost. A durat cinci ani, dar grupul de lucru WHAT a documentat cu succes cum să parseze HTML într-un mod care să fie compatibil cu conținutul web existent. Nu există nicăieri în algoritmul final un pas care să afirme că HTML trebuie să oprească procesarea și să arate un mesaj de eroare utilizatorului final.

În timp ce ingineria inversă avea loc, grupul de lucru WHAT lucra în liniște la alte lucruri. Una dintre acestea a fost o specificație care a duplicat inițial Web Forms 2.0 și a adăugat noi tipuri de câmpuri la formularele HTML (veți afla mai multe despre Web Forms în ). Un alt proiect de specificație se numește „Aplicații web 1.0”, care a inclus multe caracteristici noi, cum ar fi o pânză pentru desen direct și suport nativ audio și video fără pluginuri.

Înapoi la W3C

Timp de doi ani și jumătate, W3C și grupul de lucru WHAT s-au ignorat în mare măsură reciproc. În timp ce grupul de lucru WHAT s-a concentrat pe formularele web și pe noile funcții HTML, grupul de lucru HTML W3C a fost ocupat cu versiunea XHTML 2.0. Dar până în octombrie 2006, a devenit clar că grupul de lucru WHAT a luat un impuls serios, în timp ce XHTML 2 încă lânceșea în formă de schiță și nu fusese implementat în niciun browser serios. În octombrie 2006, Tim Berners-Lee, fondatorul W3C, a anunțat că W3C va colabora cu grupul de lucru WHAT pentru a dezvolta HTML.

Unele lucruri devin clare după câțiva ani. Este necesar să se dezvolte HTML treptat. Încercarea de a obține lumea accesând XML, inclusiv ghilimele din jurul valorilor atributelor și barele oblice în etichetele și spațiile de nume goale, nu funcționează toate deodată. Publicul imens format în jurul HTML nu s-a mișcat, în mare parte pentru că browserele nu s-au plâns. Unele comunități mari au făcut schimbarea și se bucură de beneficiile sistemelor corecte din punct de vedere sintactic, dar nu toate. Este important să sprijiniți HTML treptat și să continuați să mergeți către o lume corectă din punct de vedere sintactic și să dezvoltați eforturi mai mari în acea lume.

Există planuri de organizare a unui grup HTML complet nou. Spre deosebire de grupul anterior, acesta va aduce îmbunătățiri incrementale atât HTML, cât și XHTML în paralel. Va avea management și personal diferit. Va funcționa împreună pe HTML și XHTML. Avem un sprijin puternic pentru acest grup din partea multor persoane despre care am vorbit, inclusiv a dezvoltatorilor de browsere.

Se va lucra și cu formulare. Aceasta este o zonă dificilă, deoarece formularele HTML și XForms existente sunt un limbaj de formulare. Formularele HTML sunt implementate pe scară largă și există multe implementări și utilizatori ai XForms. Între timp, WebForms sunt supuse unei extensii inteligente în formulare HTML. Este planificat să formeze WebForms într-o extensie a formularelor HTML.

Unul dintre primele lucruri pe care le-a făcut noul grup de lucru W3C HTML a fost să decidă să redenumească „Web Applications 1.0” în „HTML5”. Și așa ne aruncăm în HTML5.

P.S

În octombrie 2009, W3C a închis grupul de lucru XHTML 2 și a lansat o declarație în care explică decizia:

Când W3C a anunțat grupurile de lucru HTML și XHTML 2 în martie 2007, am indicat că vom continua să monitorizăm piața pentru XHTML 2. W3C recunoaște un semnal clar important din partea comunității despre viitorul HTML.

Deși recunoaștem importanța Grupului de lucru XHTML 2 de-a lungul anilor, după discuții cu membrii, conducerea W3C a decis că statutul Grupului de lucru, care expiră la sfârșitul anului 2009, nu va fi reînnoit.

Cei care l-au implementat au beneficiat de asta.

Dezvoltarea limbajului marcare hipertext

1. Conceptul de limbaj de marcare generalizat standard SGML.

HTML este principalul limbaj de marcare a documentelor, dar nu singurul. Există atât soluții mai generale, cât și soluții foarte specializate.

Din punct de vedere istoric, primul format comun a fost SGML (Standard Generalized Markup Language, pronunțat SGML). SGML este succesorul limbajului GML (Generalized MarkupLanguage) dezvoltat în 1960 de IBM. metalimbaj, adică poate fi folosit pentru a defini reguli pentru construirea altor limbaje de formatare a documentelor.

SGML a fost conceput pentru dezvoltarea în colaborare a documentelor mașinii în proiecte mari guvernamentale și aerospațiale. A fost utilizat pe scară largă în industriile tipărite și editoriale, dar complexitatea sa a făcut dificilă utilizarea de zi cu zi. Principalii descendenți ai SGML sunt formatele HTML și XML.

2. Versiuni ale limbajului de marcare hipertext HTML.

HTML (Hypertext Markup Language) este cel mai comun instrument pentru crearea paginilor Web în prezent. Tehnologia HTML vă permite să legați documente de diferite formate între ele folosind link-uri hipertext (hyperlink-uri sau link-uri). Astfel de conexiuni între documente situate pe servere din întreaga lume permit sistemului să funcționeze ca și cum ar fi un singur World Wide Web. Un document HTML este un fișier care conține text simplu și comenzi speciale - etichete. Etichetele definesc formatarea vizuală a textului (culoarea și stilul fontului, aspectul titlurilor, tabelelor etc.), precum și relațiile acestui document HTML cu alte resurse (imagini, foi de stil, videoclipuri, alte documente HTML etc.) . În SGML, HTML și XML, etichetele sunt formatate cu o deschidere (<) и закрывающей (>) paranteze unghiulare urmate de Nume etichetă și apoi - comenzi care specifică acțiunea acesteia - atribute.

HTML a fost dezvoltat de omul de știință britanic Tim Berners-Lee în 1991-1992 la Consiliul European pentru Cercetare Nucleară de la Geneva (Elveția). HTML a fost creat inițial ca un limbaj pentru schimbul de documentație științifică și tehnică, potrivit pentru persoanele care nu sunt specialiști în domeniul layout-ului.

Apoi, pe lângă simplificarea structurii documentului, în HTML a fost introdus suportul pentru diferite tipuri de link-uri hipertext, iar ulterior limbii au fost adăugate capabilități multimedia. HTML a fost inițial conceput pentru structurarea și formatarea documentelor fără a le lega la software-ul de afișare. În mod ideal, textul cu marcaj HTML ar fi trebuit reprodus fără distorsiuni stilistice și structurale pe echipamente cu echipamente tehnice diferite (un ecran color al unui computer temporar, un ecran de telefon mobil cu capacitate limitată sau un program text-to-voice). Cu toate acestea, utilizarea modernă a HTML este foarte departe de intenția sa inițială. De-a lungul timpului, ideea de bază a independenței platformei HTML a fost sacrificată nevoilor moderne de multimedia și grafică.

HTML este o aplicație a SGML și este conformă cu standardul internațional ISO 8879. Standardul actual, HTML 4.01, există din 1999. Un proiect de standard în a cincea limbă a fost publicat. Noua versiune de HTML promite să adauge numeroase extensii la limbaj și să ofere un sistem de reguli mai simplu, mai logic și mai convenabil.

HTML dinamic sau DHTML este o modalitate de a crea un site Web interactiv. DHTML a apărut ca un set de metode pentru crearea și modificarea dinamică a paginilor Web prin apelarea scripturilor dintr-un document HTML. Cu toate acestea, dezvoltarea acestor metode a condus la o revizuire completă a conceptului de document Web și formarea conceptului de DOM (Document Object Model).

DOM este o interfață de programare independentă de platformă, care permite programelor și scripturilor să manipuleze conținutul documentelor HTML și XML, precum și să modifice structura și designul acestora.

DOM nu impune restricții asupra structurii documentului. Orice document cu o structură cunoscută poate fi reprezentat folosind DOM-ul ca un arbore de noduri, fiecare dintre ele conţinând un obiect. Nodurile sunt conectate printr-o relație părinte-copil.

Inițial, multe browsere aveau propriul lor model DOM, care nu era compatibil cu altele. Pentru a asigura compatibilitatea, experții din consorțiul internațional W3C au clasificat acest model în niveluri, pentru fiecare dintre acestea fiind creată propria specificație. Toate aceste specificații sunt combinate într-un grup comun numit W3C DOM.

3. Conceptul de limbaj de markup extensibil XML.

XML (Extensible Markup Language; pronunțat ex-em-el) este un format care este un set de reguli sintactice generale. XML este destinat stocării datelor structurate (în loc de fișierele de baze de date existente), schimbului de informații între programe și, de asemenea, pentru crearea unor limbaje de marcare mai specializate pe baza acestuia, uneori numite dicționare. XML este un set simplificat al limbajului SGML.

XML a fost creat pentru a oferi interoperabilitate la transferul de date structurate între sistemele de procesare a informațiilor, în special la transferul de date prin Internet.

XML nu a înlocuit HTML. Mai mult, putem prezice cu încredere că acest lucru nu se va întâmpla în viitorul apropiat. Motivele sunt atât dezavantajele evidente ale XML (dimensiuni mari ale documentelor, sintaxă redundantă și limitări ale modelului de date ierarhic încorporat în format), cât și un fapt practic important care vorbește în favoarea HTML. - majoritatea sarcinilor nu necesită întreaga putere a sintaxei XML; soluțiile HTML simple și productive sunt suficiente.