O dėl verkimo, tai jis turi kelias labai konkrečias priežastis:

• Džiaugsmas, dėl tobulėjimo, naujų galimybių, semantiškumo;
• Nusivylimas, kad tai kas aprašyta specifikacijoje, turėsime (su implementacija) tik po, geriausiu atveju, penkių, jeigu ne penkiasdešimties, metų;
• Pyktis su klausimu “koks idiotas sugalvojo, kad tai yra reikalinga”;
• Tragiška panika, kad naujasis HTML5 suteiks galimybę Microsoft padaryti dar daugiau klaidų Internet Exploreryje….

Žingsnis į priekį

Pirmą kartą skaitydamas apie tuos skirtumus atkreipiau dėmesį tik į naujus elementus. Labiausiai džiaugiuosi struktūriniais <section>, <article>, <header>, <footer>, <aside> elementais – jie bus labai naudingi SEO požiūriu. Didžioji dalis kitų naujų tag’ų taipogi nėra blogi iš esmės – jie visi turi savo pritaikymą.

Du žingsniai atgal

Na, dėl žengimo atgal gal per daug griežtai pasakyta, tačiau kai kurie dalykai atrodo mažų mažiausiai keisti. Labiausiai mane neramina esminiai pasikeitimai formose. Aš tikrai nepeikiu tų idėjų, netgi atvirkščiai – džiaugiuosi jomis, tačiau didysis klausimas yra ar šioms naujovėms vieta HTML standarte?

Nepaisant to, kad <input> elemento tipas datetime yra tikrai reikalingas, tereikia tinkamai apibrėžti siuntimo standartus į serverį (nes atvaizdavimo formatas skirtingas priklausomai nuo vartotojo lokalės), jis sukelia neigiamą postūmį tinklo kūrėjams.

HTML mokymosi kreivė

Daugiau nei pusė “PHP programuotojų”, kurie ateidavo pas mane į pokalbius dėl darbo, nežinojo arba nesugebėdavo apibrėžti kas yra “SQL injection”. Natūralus klausimas yra ar tie programuotojai suvoks kad email lauke įvestus duomenis reikia vistiek tikrinti ir server-side? Nemanau. Be abejo, galimi kažkokie priverstiniai sprendimai, kad ir reikalavimas kartu su siunčiama forma perduoti metaduomenis apie laukų tipus. juos automatiškai patikrintų, kad ir tas pats PHP – tačiau tam gali prireikti ir pakeitimų HTTP standarte – kas sukuria tik dar didesnį sniego kamuolį, besiritantį žemyn nuo kalno.

Be abejo, galimas kontra-argumentas yra tai, kad svetaines turėtų kurti profesionalai, bet juk HTML visada buvo standartas, kurio mokymosi kreivė nėra labai stati, be to idėja prieštarauja user-generated content principui. Kažkada žaidžiant žaidimus, teko susidurti su penkiasdešitmetėmis mamytėmis, kurios prižiūrėdamus vaikus, be didelio vargo tvarkydavo savo sritį žaidėjų aliansų svetainėse. Profesionalūs programuotojai jau beveik išmoko “teisingo HTML” taisykles – tačiau didžioji dauguma žmonių, kuriems teks susidurti su tuo, niekada nevargs dėl jų, bet puslapius tvarkyti norės. Tokie žmonės visada galvos “Štai įdedu čia number lauką ir jis automatiškai išsisaugo duomenų bazėje – puiku! Paprasta! Dabar pradėsiu profesionalią tinklo kūrėjo karjerą!”

Daugiau medžių

HTML5 specifikacija gan neblogai atspindi tam tikras Web 2.0 tendencijas, o ypač – AJAX paplitimą. Tai ryškiai matosi iš tokių naujų atributų kaip contenteditable, contextmenu, draggable, ping ar elementų <menu>, <progress>. Vėlgi – beprotiškai džiaugiuosi didžiąją jų dalimi. Kasdieniame darbe ne kartą apie juos teko pasvajoti (tol kol nepradėjau žaisti su GWT – JavaScript nėra pati dėkingiausia programavimo kalba).

Tačiau ar tikrai HTML yra ta kalba, kuria derėtų aprašinėti turinio valdymo sistemas? Kiek pamenu, HTML buvo sukurta tam, kad sužymėti hiper-tekstą – tai yra dokumentą su išorinėmis nuorodomis. Evoliucija link semantiško HTML yra natūrali. Tačiau realybėje tinklas išsiplėtė ir “interneto svetainė”, dabar gali reikšti ir “tinkle veikiantis programinis paketas” (think: Google Apps). Lyg ir nebūtų problemos tame, tačiau tą evoliuciją griauna esminis rudimentas:

To keep the authoring language relatively simple for authors several elements and attributes are not included <..> User agents, however, will always have to support these older elements.

Ši frazė iš esmės reiškia, kad kūrėjas neturi teisės naudoti tam tikrų senų elementų, bet naršyklės privalo juos palaikyti. Sakyčiau visiškas absurdas. Panašiai kaip ir su greičio limitais. Mieste lyg ir 50km/h, bet Vilniuje visi važiuoja 70km/h ar greičiau. Tai kur gi dingo ta aktyviai W3C propaguojama semantika? Iš vienos pusės jie nori suteikti kuo daugiau lankstumo, tačiau tuo sukelia absoliutų chaosą savo diegiamoje tvarkoje. Iš vienos pusės jie skatina naudoti CSS turinio formatavimui, tačiau iš kitos – bando palikti meniu iš “tipinio interfeiso”. Tiesa, neįsivaizduoju kaip galima būtų su CSS aprašyti iššokantį kalendorių (kurį sukuria naršyklė, pagal OS standartus). Nors… ne bėda juk. <SELECT>’ų po IE neina formatuoti – matyt teks gyventi šiame pragare ir toliau…

Šaunam į kiškius

Kaip ten bebūtų – pagrindinė W3C problema kuriant HTML5 yra siekimas patenkinti visus. Tiek naršyklių kūrėjus, tiek tinklo kūrėjus. Tiek patyrusius HTML ekspertus, tiek entuziastiškus mėgėjus. O juk jie galėtų atsižvelgti į vieną elementarią usability taisyklę – ekspertai nepyksta, kai dalykai yra pritaikyti kvailesniems mažiau patyrusiems už juos ir todėl yra nesudėtingi.

Juk galima vos vos pataisyti esamą HTML standartą, iš jo pašalinant kelis “per sudėtingus” elementus bei neįtraukiant naujovių ir publikuoti tai kaip HTML5 basic. O visus sudėtinguosius dalykus perkelti į HTML5 strict standartą, kuriame vertinimas būtų daug griežtesnis. Panašiai jau yra padaryta su HTML4, tačiau svarbiausias dalykas kurio reikia – norint naudoti pažangius dalykus, privalu naudoti strict standartą. Tai yra, mamytė kovinio alianso žaidime vadovė ir toliau gali naudoti paprastą HTML, o komanda, kurianti corporate level web programą būtų priversta pilnai laikytis standartų, nes kitaip aplikacija neveiktų išvis.

Labiausiai paguodžiantis, tačiau tuo pačiu virkdantis dalykas visame dokumente yra ši eilutė:

The HTML 5 specification will not be considered finished before there are at least two complete implementations of the specification.

Paguodžia todėl, kad jeigu Microsoft nesugebės to įdiegti 19.5 IE versijoje be klaidų – jie atsiliks. Virkdo dėl dviejų priežasčių. Pirma – Microsoft pasakys, kad standartas yra tai, kaip klaidos veikia 19.5 IE versijoje, o antra – tinklo kūrėjai pirmo žingsnio diegiant standartus negalės žengti, o naršyklių kūrėjai gali gerokai užtrukti priiminėdami sprendimus, nes visi kabės ore dėl galimų pasikeitimų standarto specifikacijoje.