Moralas toks – jeigu įtrauki į savo kodą failus tiesiogiai iš kitų žmonių serverių, ypač jeigu jų nepažįsti ir nepaklausi jų sutikimo, viskas gali baigtis blogai. Štai pvz. mano blog’as naudoja html5.js – aš galėčiai ramiai pakeisti jį taip, kad jis vogtų jūsų svetainės lankytojų slaptažodžius ir siųstų man. Bet aš neesu blogietis ir to nedarysiu.

Jeigu kam nors reikia įsijungti HTML5 Internet Exploreryje – galima gi paimti ir parsisiųsti tą JS ir pasidėti savo svetainėje. Bet jeigu jau taip gaila srauto – Remy Sharp leidžia tiesiogiai naudoti jo sukurtą versiją iš Google Code SVN.

Man iš tikro negaila, bet pagunda bent pajuokauti yra… Tu žinai kas tu esi. Ar ne?

Šiame blogo įraše susidėjau tai, ką pasižymėjau pats sau beklausydamas kalbėtojų. Pačių kalbų tikrai neketinu aprašinėti – tai puikiai padarė Ajaxian (nuorodas pateikiu), o skaidrės taipogi prieinamos viešai.

Jeigu kažkuris punktas sudomino – palikit komentarą – išplėsiu!

Christian Heilmann – Frontloaded and zipped up – do loose types sink ships

Ajaxian santrauka; skaidrės; garso įrašas.

• Apie “AJAX” programuotojus kalbama žymiai pagarbiau negu apie “JavaScript” programuotojus. Abydna, vienok.
• JS nėra programavimo kalba skirta kiekvienam – ir ne kiekvienas save vadinantis “tinklo kūrėju” turėtu ja užsiimti.
• JS egzistavo gerokai prieš jQuery.
• Naudojant JS kalbą, reikėtų ją naudoti taip, kaip ji buvo suplanuota – gana kurti įvairias abstrakcijas pagal tradicinius OO modelius. JS turi savo stilių – privalu jį išnaudoti ir įsisavinti.
• Saugumo skylės (XSS, XSRF ir t.t.) yra server-side problema – JS dažniausiai yra nekaltas (nors ir išnaudojamas)
• Nepamiršti: http-only sausainiukai sesijoms
• Bet kuris API yra iš esmės saugumo skylė – Firefox greičiausiai yra pati nesaugiausia naršyklė būtent dėl savo plėtinių architektūros. Priminė kažkieno sakinį, kad mash-up’ai yra XSS atakos prieš save patį.
• Išbandyti: dažnos ir paprastos apklausėlės kaip mokymosi metodas komandoje
• Pasidomėti: adsafe.org saugumo rekomendacijos
• Pasidomėti: Google Caja (yra informacijos ir YDN)
  • Kas per saugumo skylė IE su radio mygtukais?
  • Kodėl clearfix nevartotinas pagal Caja?
  • Kodėl tiek daug CSS apribojimų?
• javascript:void(0) turi mirti (žiauria ir negarbina mirtimi)!
• John Resig yra, lyg ir, pažadėjęs, kad jeigu pakankamai žmonių to reikalaus – jQuery pritaikys Caja rekomendacijas
• Pasidomėti: ar įmanoma padaryti YQL injection?
• Pasidomėti: jau egzistuoja OAuth implementacija vien su JS

Robert Nyman – JavaScript: from birth to closure

Ajaxian santrauka; skaidrės.

• Kas čia per įprotis, tikrinti ar dižiąjame ekrane bėgantis Twitter srautas yra cenzūruojamas? Įdomus kultūrinis pokrypis, besivystant technologijoms…
• Nepamiršt: skaityti Dmitry Baranovskiy’o blogą
• Pasikartot: typeof kint == 'undefined' naudojimas
• Pasidomėt: Koks yra globalus this Rhino variklyje (t.y. window atitikmuo naršyklėse)?
• Pasidomėt: YAHOO Module Pattern

Peter-Paul Koch – W3C Widgets

Ajaxian santrauka; skaidrės.

• Pasidomėt: Ar Nokia N900 naršyklė yra fennec? (Atsakymas: taip)
• Mobilaus telefono naudojimas interneto naršymui yra puikus būdas pasimokyti – visos vartojiškumo pamokos gali būti pritaikytos eilinėms naršyklėms
• Ar @media kartu su iPhone’o <meta name="viewport" /> galėtų išspręsti problemą, kad user-agentai savaip interpretuoja pločius kai svetainė yra išzoominta? (Prie alaus PPK patvirtino, kad ketina tą patikrinti artimiausiu metu)
• Kai kuriuose aukšto DPI telefonuose kartais būna sunku paspausti tą vietą kurią nori – ar gali spaudimo jautrumo DPI ir ekrano DPI gali būti skirtingi?
• Nejaugi mobilūs telefonai neturi “ilgai trunkančio skripto” perspėjimų?
• Dėl greičio problemų, rekomenduojama nenaudoti iframe mobiliems telefonams skirtose svetainėse – kaip įgyventi AJAX-išką naršyklės istoriją (back/forward)?
• Dingstantis ryšys yra problema – ir online/offline įvykiai jos visiškai nepadeda spręsti
• Mobilių telefonų kešas yra ~200kb – būtina dar protingiau optimizuoti kodą
• W3C specifikacijos widgetai leidžia tik vieną HTML puslapį – potenciali problema?
• Dalintis widgetais per Bluetooth yra pavojinga
• Animacijos efektai mobiliuose telefonuose veikia lėtai. Iš patirties – ne viskas taip jau blogai, bet optimizuoti ir apskritai elgtis protingai privalu

Stuart Langridge – New things that HTML5 provides to JavaScript hackers

Ajaxian santrauka

• Pasidomėti: underscore.js
• Internetas jau nebėra “programų rašymo platforma”. Tavo svetainė gali būti ta platforma, jeigu atidarysi savo API. Ir net jeigu neatidarysi – yra GreaseMonkey. Reikia tam būti pasiruošus!
• Idėja: naršyklių gamintojai, galėtų turėti standartinį būdą palaikymo tikrinimui, t.y. jeigu tu rašai savo kodą laikydamasis progressive enhancement principo, kartais turi paprastus būdus patikrinti, ar kažkas veiks – o kartais ne (pvz. Operos <event-source/>). O galėtų būti kas nors paprasto, pvz. window.navigator.supports("event-source");

Todd Kloots – More accessible user interfaces with ARIA

Ajaxian santrauka, video įrašas ta pačia tema iš YUI konferencijos

• Idėja: YUI3 šiuo moment palaiko ARIA pridėdami roles ir atributus elementams, su kuriais dirba, pvz. sukuriant YUI meniu JS, susiiję elementai yra teisingai pažymimi. Ar neturėtų viskas būti atvirkščiai? T.y. rolės ir atributai nustatomi tiesiai HTML dar serveryje, o YUI (ar kita biblioteka) inicializuojasi jau naudodami tas roles.
• Toddas kalbėjo apie tai, kaip galima “uždėti ARIA sluoksnį savo sistemoje”. Bet argi nebūtų paprasčiau laikytis “ARIA palaikymo” kaip pagrindinio principo, t.y. tai yra kažkas tokio, ką tiesiog darai natūraliai, negu tai, ką darai pabaigoje, ant viršaus? Lygiai taip, kaip kažkada reikėjo pakeisti mastymą rašant HTML ir CSS, bei išmokti naudoti progressive enhancement, o ne graceful degradation.
• YUI2 palaiko “event delegation“? Čia nuo kada? (Atsakymas: pasirodo, nuo YUI 2.8 – pamiršęs buvau… “event delegation” valdo!)
• Žmonės su normaliu regėjimu, turbūt savo protiniuose modeliuose (kaip išversti mental model?) turbūt be problemų priima, kad meniu dažnai eina iš kairės į dešinę. Kaip tai suvokia aklieji? T.y. kaip jų modeliai susitvarko su tuo, kad meniu navigacija vykdoma “kairė/dešinė” mygtukais, o ne “viršus/apačia”, kai naudojamos ekrano skaityklės?
• Pasidomėti: ar ARIA turi kokį nors “fokusuotos grupės” apibrėžimą, o ne vien tik “fokusuoto elemento”?
• Pasidomėti: accessibility šiuo metu dažniausiai siejasi su pele ir klaviatūra, kaip įvesties įrenginiais – kokie modeliai naudojami kitiems įrenginiams?
• Pasidomėti: ką HTML5 specifikacija sako apie <section/> web application kontekste?
• Pasidomėti: klaviatūros greitųjų klavišų atrandamumas lankytojams su normalia rega

Jake Archibald – Optimising where it hurts

Ajaxian santrauka; tyrimas ir skaidrės

• Ar jis čia skaidres varto su savo WII kontroleriu? Geras!
• Niekada nenaudoti eval(), ypač closure viduje – tai iš esmės nužudo visas JS variklių (V8, TraceMonkey ir t.t.) optimizacijas, nes eval() gali nesunkiai pakeisti kintamųjų aprėptį (kaip išversti scope?)
• Nenaudoti closure per dideliam gyliui, jeigu galima to išvengti
• Niekada nenaudoti eilučių sujungimo, kai jos rašomos į innerHTML, t.y. ne el.innerHTML="<div>"+kint+"</div>", o var s="<div>"+kint+"</div>"; el.innerHTML=s;
• Vengti window.onunload naudojimo, nes nužudomas kešinimas (jQuery jau turi šią problemą – bet ketina išspręsti)
• Švarus ir paprastas HTML, neturintis bereikalingų tagų, pats savaime paspartina selektorių darbą (nes reikia perfiltruoti mažesnį kiekį elementų). Žodžiu, rašyti didelį kiekį nesemantinio HTML (ar tai būtų nereikalingi div, ar table) yra blogai!
• Kiekvienas turėtų pasimokyti pats rašyti vykdymo greičio testus (tik reikia nepamiršti apie “16ms problemą JS”)
• “Optimizuok ten kur skauda” iš tikro tereiškia “nebūk durnas” – visos diskusijos, apie tai kuris ciklas optimalesnis (for prieš while) yra bevertės (nes sutaupo 0.002 milisekundės). Iš tikro reikia izoliuoti tą dalį, kuri veikia lėčiausiai, ir tvarkyti būtent ją. Vargti stengiantis rašyti “teisingą kodą” iš anksto yra beprasmiška – žinot istoriją su “priešlaikine optimizacija”, ar ne?

Simon Willison – Beating server side engineers in their own game

Ajaxian santrauka; autoriaus santrauka

• Pasidomėti plačiau apie E4X
• Mac’ų vartotojai elgiasi… kitaip. Tiesiog kitaip ir tiek.
• Ar eitų NodeJS panaudoti kaip unit testų konsolę? Integruoti į continuous build’us?
• JS nėra “strongly typed” kalba – tai natūraliai yra sunkiau dirbant komandoje. Pasidomėti: kaip tai galima spręsti
• NodeJS ir CouchDB yra labai labai seksi! Kiekvienas turėtų pasidomėti kaip jie veikia, kaip optimizuoja procesus ir kokiais principais yra paremti!

Antraščių problema HTML 4.01

HTML4 specifikacija apie h? antraštes kalba gana abstrakčiai. Jų esmė – pristatyti toliau einačios dokumento dalies turinį. Paminėta, kad h1 yra svarbiau negu h6, taipogi, kad iš to galima sukurti dokumento “apžvalgą” ar “turinio rodyklę”. Dar rašoma, kad “kai kurie žmonės” laiko, kad “peršokti” lygius (t.y. h1 h3 h5) yra neteisinga, tačiau neteikia jokių rekomendacijų šiuo klausimu.

Be jau paminėto komentaro pačioje specifikacijoje, toks aprašymas palieka begalybę kitų klausimų, kad ir pvz. kiek puslapyje gali būti h1 žymų? Kaip atskirti skirtingą jų kontekstą? Viena iš SEO strategijų (kol robotai nebuvo to išmokę pažinti), buvo sukišti vos ne visą puslapio turinį į h1, taip raktažodžiams suteikiant papildomą vertę. Kita problema buvo, kad ir tai, kad pvz. dokumento skiltis skirta navigacijai (blog’o sidebar) taipogi buvo suskirstyta į dalis – tokiu atveju norėtųsi atskirti, kad sidebar poskyriai (pažymėti h3) nėra vienos iš įrašo pastraipų (pažymėtų h2) dalis.

Interpretacija: h1 yra svarbiausias ir vienintelis

Negana to, mano asmeniniu požiūriu, puslapyje derėtų derėjo naudoti tik vieną h1 tipo elementą (WCAG rekomendacija) – tą, kuris daugiau mažiau sutaptų su puslapio pavadinimu, nurodytu title. Taigi titulinis eilinio blog’o puslapis atrodytų maždaug taip:

• h1: blog’o pavadinimas
  • h2: navigacija
    • h3: sidebar skiltis
    • h3: sidebar skiltis
  • h2: įrašas
    • h3: įrašo pastraipa
    • h3: įrašo pastraipa
  • h2: įrašas
    • h3: įrašo pastraipa
    • h3: įrašo pastraipa

Ką daryti kai antraštės “šokinėja”?

Aukštesnis suskirstymas tinka tik pirmąjam puslapiui. Jeigu kalbame apie individualaus įrašo puslapio sužymėjimą, tai situacija lyg ir keistųsi – blog’o pavadinimas jau nebėra h1 svarbos, nes svarbiausia antraštė tokiu atveju yra įrašo pavadinimas! Įrašo pastraipos taipogi turėtų kylti lygiu aukščiau – iki h2. Kas tokiu atveju atsitinka su sidebar skiltimis? Nežinau.

Taip iki galo ir neišsprendžiau tos problemos, nors ir labai norėjosi. Viena iš minčių buvo išvis atsisakyti pašalinės navigacijos. Lankytojų tai per daug nenuskriaustų – pagal mano duomenis didžioji dalis lankytojų iš Google patekę tiesiai į konkretų įrašą arba tiesiog išeidavo (aš gal rašyt nemoku?), arba po to keliaudavo į titulinį puslapį (o gal vistik moku?), o ne tiesiogiai į kitus įrašus.

HTML5 dokumento skilčių apibrėžimai į pagalbą!

Nepaisant to, kad iš aukščiau apibrėžtos problemos grafomanas išspaustų tris įrašus, o internetas pilnas nesibaigiančių diskusijų, man tai nebėra aktualu! HTML5 apibrėžia dokumento skiltis – joms sužymėti galima naudoti section, nav ir article elementus (aside taipogi laikoma atskiru, susijusiu poskyriu). Visi šie elementai gali turėti savo antraštes ir paraštes (header ir footer). Tokiu atveju, kiekviena antraštė įgauna savo individualų kontekstą (body viduje esanti antraštė aprašo puslapį, gi tuo tarpu article viduje – tik tą įrašą) ir savo individualią hierarchiją.

Nepaisant to, kad specifikacijoje gana daug teksto yra skiriama rodyklės (outline) formavimo algoritmui, paprastam blog’ui, o turbūt ir daugeliui kitų svetainių, tai yra neaktualu, nes antraščių hierarchija visada gaunasi elementari – praktiškai bet kurios dokumento dalies antraštės apsirašo tiesiog <header><h1> pavadinimas </h1></header>, t.y. h1 šiuo atveju nebereiškia tiesiog “svarbiausia antraštė”, o interpretuotina kaip “svarbiausia antraštė šioje dokumento dalyje”. Naudojant tokią logiką, individualus įrašo puslapis jau nebeturi kitokio globalaus antraščių lygmenų išsidėstymo, nei sąrašuose – dabar aš drąsiai galiu savo įrašų poskilčius žymėti tiesiog h2.

Desertas

• HTML5 neberiboja antraščių gilumo (anksčiau buvo maks. 6) – nors ir nelabai žinau kam to gali prireikti
• hgroup elementas leidžia grupuoti antraštes su paantraštėm, kaip pvz. aš esu padaręs su blog’o pavadinimu – View source naudoti mokat?
• ARIA banner rolė leidžia atskirti “svetainės” ir “dokumento” pavadinimus – apie ARIA apskritai dar reiktų daugiau man pasiskaityti…

Papildomas skaitymas

• Introducing the <hgroup> element
• Headings in HTML 5 and accessibility
• More than one H1 on a page: good or bad?

PS neturiu laiko ieškoti, bet gal kas turit pasiūlymą, kaip WordPress priversti nedėti aside į p?

Struktūriniai elementai veikia puikiai

Naujieji elementai (header, footer, time, etc) veikia (beveik) puikiai. Nėra nei vienos rimtos priežasties, kodėl reiktų delsti su jų naudojimu. Vienintelė išimtis (kurios aš net nesistengiau išspręsti) – Firefox 2. IE šeimos naršyklės taipogi nenori pripažinti naujų žymų ir pritaikyti joms stilių, tačiau tai nesunkiai išsprendžiama Javascript pagalba. Jeigu vien Javascript sprendimas netenkina (unobtrussive, progressive enhancement, etc) – visada galima naudoti tarpinį sprendimą – naudoti naujas HTML5 žymas semantikai, o stiliams prikaišioti div‘ų.

Be viso šito, perrašydamas savo blog’o HTML, nesusidūriau su jokiom problemom, išskyrus header ir h1 semantinėm reikšmėm, bet tai yra verta atskiro įrašo. Dar turėjau šiek tiek dvejonių dėl section naudojimo, tačiau priėjau išvados, kad geriau šiandien eksperimentuoti, o rytoj padaryti teisingai – be klaidų progreso nebus.

Formos elementų tipus naudoti galima

Aš pats nenaudojau naujų formų elementų tipų (type=email, type=url), tačiau kai tik turėsiu daugiau laiko paeksperimentuoti – naudosiu ir juos. Kol kas juos palaiko tik Opera naršyklė, tačiau kitos netruks prisivyti, o tos kurios jų nepalaiko – atvaizduos laukus tiesiog kaip type=text – demo. Vėlgi – truputėlis JS šen bei ten, truputėlis CSS ir ateitis bus šiandien.

canvas, video ir audio palaikymas

Na, šitie trys žvėrys man šį savaitgalį, ir juo labiau eiliniam blog’ui, buvo visai neaktualūs, tačiau jie jau veikia bent dalyje naršyklių.

Turint omeny, kad iš dalies HTML5 yra kuriamas kaip standartas, dokumentuojantis jau egzistuojančią tinklo ir naršyklių būklę, tai canvas yra tas dalykas, kuris turi mažiausiai palaikymo problemų (neskaitant vienos, ghkhmz, naršyklės). Ajaxian vos ne kas antrą dieną paskelbią kokį nors naują demo su canvas. Super Mario žaidimas – sukurtas prieš daugiau nei metus! Aš ir pats dar užpernai naudojau vieną iš jQuery pluginų grafikų paišymui.

Su video problemos yra kur kas didesnės. Kas nors dar atsimenat, kaip prieš daug daug metų tekdavo vargti ieškant codec packų? Internete tai būtų visos “video be pluginų (skaityti: Flash)” idėjos žudikas. Safari palaiko Quick Time, Opera 10 ir Firefox – OGG Vorbis ir Theora, Chrome – OGG ir H.264, ir nei vieni, nei kiti neketina pasiduoti.

Kodekų problema yra iš esmės tai, kad dauguma jų yra uždari, apsaugoti patentų ir brangiai kainuoja. Tie, kurie yra atviri – netenkina kokybės reikalavimų (Google, kaip didžiausias video turinio teikėjas, nenori naudoti OGG, nes na interneto srautas yra brangus dalykas).

Ateitis

Kadangi XHTML2 mirė, tai HTML5 lieka vienintelis ateities standardas. Ir jis nors ir nėra tobulas, tačiau panašu, kad neketina sugriauti egzistuojančio interneto. Naršyklės pradeda jį po truputį palaikyti, tinklo kūrėjai taipogi jau turi galimybę juo naudotis. Kartais atrodo, kad jis gal ir nėra reikalingas – juk internetas veikia ir dabar, tačiau tikrasis postūmis bus tada, kai paieškos robotukai pradės labiau gerbti semantinį tinklą. Tai nutiks tik tuo atveju, jeigu HTML5 bus naudojamas jau dabar – nereikia laukti galutinės W3C rekomendacijos (juk ji bus tik tada, kai bus 2 pilnai įgyventintos realizacijos).

Šaltiniai ir tolesnis skaitymas

• HTML5 doctor
• HTML5 enabling script
• Yes, You Can Use HTML 5 Today!
• HTML5 darbo grupės blog’as

Aprašytos problemos sprendimo algoritmas yra gana paprastas – prikabinti įvykių gaudytojus prie reikalingų elementų ir pačiam nustatyti reikalingus parametrus. Tačiau jeigu nesusimąstytume – greitas ir paprastas įgyvendimas turėtų kelias problemas.

Sprendimo problemos

Pavyzdys: krauname puslapį, jame yra paieškos laukas, kurio viduje yra tekstas “Paieška”. Fokusuojant lauką tas tekstas turi pradingti. Be abejo, pats “standartinio teksto” patternas yra jau savaime nelabai geras, tačiau kartais be jo tiesiog neįmanoma išsiversti. Taigi, turime du variantus: a) tekstą įrašyti lauke iš anksto (input value="Paieška"), fokusuojant jį ištrinti; b) palikti tuščią lauką, ir užkrovus puslapį tą tekstą įrašyti. Pirmu atveju turime semantikos problemą, o taipogi jis nėra netrukdantis, t.y. tam, kad naudotis lauku, reikalingas įjungtas Javascript. Taip pat, abiem atvejais, neįdėjus papildomų pastangų, perrašymas gali įvykti jau po to kai vartotojas fokusuoja lauką (pvz. dėl lėtai kraunamų Javascript bibliotekų arba IE6 paspaudus refresh, kai kursorius yra viename iš laukų).

Konkrečiam pavyzdžiui yra dar ir trečiasis variantas – naudoti onfocus ir onblur atributus ir Javascript rašyti tiesiog HTML viduje (inline Javascript), tačiau šis būdas tinkamas tik tuo atveju, jeigu nesilaikote sužymėjimo ir elgsenos atskyrimo principo. Be to, jis apkrauna kiekvieną siunčiamą puslapį papildomu kodu, kas nėra pageidautina, ypač jeigu tokių laukų yra ne vienas. Na ir aišku, jis neišsprendžia pagrindės šio įrašo problemos – hasFocus – vieningu, paprastu, universaliu būdu.

Kodo kiekis ir geriausios praktikos

Akivaizdu, kad hasFocus simuliavimui reikės kiekviename puslapyje įtraukti gabaliuką Javascript, kuris priešingai negu geriausios praktikos rekomendacijos, turės būti įvykdomas dar prieš galutiniai “nupiešiant” puslapį, t.y. <head> viduje. Tai reiškia, kad pats kodas turi būti minimalus – tiek instrukcijų kiekiu, tiek savo apimtimi, nes kiekvienas persiųstas baitas ir vykdymas kainuoja vertingas milisekundes (prezentacija).

Įvykių burbuliavimas

Su ankstesniu reikalavimu atsiranda ir kitas – neturime galimybės įvykių gaudyti kiekvienam elementui individualiai. Net jeigu tai ir nebūtų idelaus sprendimas vien dėl apkrovimo priežasčių, tie elementai dar paprasčiausiai neegzistuoja dokumente. Taigi turime rinktis reglib požiūrį – prikabinti savo funkcijas prie viso dokumento ir jų viduje nustatinėti elementą, kuriame viskas vyksta. Šioje vietoje derėtų paminėti, kad remiantis standartais, focus ir blur įvykiai neburbuliuoja į viršų, t.y. tėvinis elementas teoriškai neturėtų žinoti, kad jo vaikuose vyksta būtent šie įvykiai.

Naršyklių skirtumai

Skirtingos naršyklės eventus gaudo skirtingais būdais, taipogi naudoja skirtingą metodiką perduoti susiijusius elementus. Tradiciškai ši problema buvo sprendžiama vykdant skirtingas kodo šakas skirtingoms naršyklėms, tai nustant pagal user-agent eilutę. Tokia metodika yra žalinga ir nėra amžina. Pastaruoju metu tiek jQuery, tiek kitos bibliotekos perėjo prie efektyvesnio būdo – tikrinti ar egzistuoja tam tikros galimybės, o ne tikrinti ar lankytojas naudoja konkrečią naršyklę. Feature sniffing taipogi yra reikalavimas šiai užduočiai.

Sprendimas pažingsniui

1. Nusistatom įvykių gaudymo funkciją (f) – IE naudoja attachEvent, padorios naršyklės – addEventListener.
2. Nusistatom įvykių vardus (n). focus ir blur kaip minėjau neturėtų burbuliuoti į viršų, todėl su IE reikia naudoti onfocusin ir onfocusout. Šia tema galima pasiskaityti ir daugiau, tačiau šiam sprendimui šito užtenka.
3. Pagrindinė fokuso nustatymo funkcija (s) ima du parametrus – pirmas nurodo ar fokusą įjungti, ar atjungti, antrasis gi nurodo elementą.
4. Neesu įsitikinęs, kad čia pats taupiausias variantas, tačiau įdedame dvi funkcijas – viena gaudo focus (i), kita blur (o), ir kviečia pagrindinę funkciją.
5. Viską sukišame į closure ir sutrumpinę iki minimumo pagaliau prisegame įvykius – d[f](n[0],i,true);.

Galutinis sprendimas

(function() {
    var d = document,
	s = function(h, t) {
		if (t.tagName) {
			t.hasFocus=h;
			if (a) document.activeElement=t;
		}
	},
	i = function(e) {
		s(true, e.target || e.srcElement); },
	o = function(e) {
		s(false, e.target || e.srcElement); },
	f = d.addEventListener ?
		"addEventListener" : "attachEvent",
	n = typeof d.onfocusin=="object" ?
		['onfocusin','onfocusout'] : ['focus','blur'],
	a = typeof document.activeElement=="object" ?
		false : true;

	d[f](n[0],i,true); d[f](n[1],o,true);
})();

Panaikinus bereikalingus tarpus ir suspaudus viską į vieną eilutę, šis sprendimas užimtų vos daugiau nei 400 baitų – pakankamai maža kaina už funkcionalumą. Jeigu netyčia nepalikau kokios klaidos kur nors – viskas turėtų veikti su IE6/7, FF2/3, Opera 9.6 ir Safari 3.x.

Taipogi galite pasižiūrėti veikiančią demonstraciją. Po dviejų sekundžių nuo užkrovimo gausite iššokantį langą, kuriame bus surašyta kas turi fokusą.

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.