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ą.

Dažniausiai norint nežinomo pločio elementą išcentruoti horizontaliai kitame elemente problemų nekyla – užtenka tiesiog paprasto text-align:center; ar kiek sudėtingesnio display:block; margin-left: auto; margin-right: auto;. Šie abu variantai netinka tuo atveju, kai vidinis elementas yra platesnis negu išorinis. Jeigu tas vidinis elementas yra paveiksliukas, jį galima perkelti į foną ir uždėti background-position: 50% 50%;, tačiau kartais tiesiog nėra techninės galimybės nenaudoti <img>, o galbūt kai kam kiltų noro ir žaisti su kitokiais elementais.

Alternatyvus variantas, be abejo, yra naudoti tam JavaScript, tačiau pritaikom Auksinę Gero Tinklo Taisyklę: HTML naudojamas aprašymui (mark-up), CSS atvaizdavimui (presentation), o JS elgsenai/veikimui (behavior)- centravimas yra atvaizdavimas, taigi JS netinka.

Praktinė užduotis

Turime didelę duomenų bazę, kurioje sukauptas kalnas sumažintų paveiksliukų (thumbnails). Dauguma jų yra 150px pločio, tačiau pasitaiko ir kitokių. Kaip juos visus “apkarpyti” parodant tik vidurinę dalį 100px pločio rėmelyje? Galima naudotis tik CSS ir <img> dėl accessibility.

Sprendimas: kaip centruoti nežinomo pločio vidinį elementą

Nustok man kvaršinti galvą ir duok pilną sprendimą.

Jeigu turime fiksuoto pločio išorinį rėmelį, ir visiškai nežinomo pločio (platesnį arba siauresnį) vidinį elementą, tenka šiek tiek pavargti. Matematika atrodytų paprasta – kažkokiu būdu pastumti vidinį elementą per pusę išorinio elemento pločio, ir patraukti atgal per pusę vidinio elemento pločio, taip sulygiuojant jų centrines linijas. Lengviau pasakyti, negu padaryti…

Pirmas žingsnis – pastumiam į šoną

Išoriniam elementui .frame uždedame fiksuotą plotį ir overflow: hidden;, kad jokie išsiplėtę vidiniai elementai jo nepakeistų. Tada sukuriame pirmą vidinį rėmelį perkėlimui – .shiftLeft, kuris paprasčiausiai turi papildomą paraštę, kurios plotis yra pusė išorinio rėmelio. Sprendime naudoju pikselius, bet manau, kad turėtų veikti ir procentai.

Antras žingsnis – patraukiam atgal

Patraukti vidinį elementą per pusę jo paties pločio atgal yra kiek sudėtingiau – panaudoti neigiamos paraštės negalima, nes paraščių procentiniai pločiai, pagal standartus, yra skaičiuojami nuo tėvinio elemento pločio. Šią problemėlę galima išspręsti, jeigu vidinis elementas yra “plaukiojantis”. Kadangi kai kurios naršyklės (ghkhmz) tai palaiko ne visai tiksliai – tenka naudoti du elementus – vienam jų (.floatToFix) uždėti float ir užfiksuoti plotį, o su kitu (.unshift) traukti atgal. Į .unshift vidų jau galime įdėti neapibrėžto pločio paveiksliuką – nerekomenduočiau jam pačiam taikyti patraukimo atgal klasės…

Trečias žingsnis – sprendžiam problemas

Gana dažnai dėl klaidos kode (double margin bug) tam tikra naršyklė (ghkhmz) pritaiko dvigubą plotį plaukiančių elementų paraštėms – tai galima spręsti su display: inline;, tačiau šiuo atveju vistik tenka traukimo veiksmą pakeisti iš paraščių į santykinį pozicionavimą ir panaudoti tiesiog neigiamą left: -50%;. Su tuo santykiniu patraukimu atsiranda kita problema (toje pačioje, tam tikroje, naršyklėje (ghkhmz)) – vidinis elementas išlipa į viršų ir nebepaiso overflow. Tai galima išspręsti nustatant position: relative; ir visiems tėviniams elementams.

Galutinis sprendimas

Kažkodėl pažvelgus į jo kodą, atrodo, kad viskas taip elementaru, tačiau teko gerokai paeksperimentuoti, kol pasiekiau veikiantį variantą. Kas keisčiausia, vos vos jį pakeitus viskas sugriūna! Panašu, kad galutinė versija veikia teisingai su:

• Internet Explorer 6
• Internet Explorer 7
• Firefox 2
• Opera 9.26
• Safari 3.1

Su Safari, tiesa, kartais atsiranda gana keistas perpiešimo efektas – dalis vidinio elemento pradingsta, tačiau pakeitus lango dydį viskas sugrįžta į vietas. Jeigu kas galite patikrinti su kitomis naršyklėmis – būtų malonu išgirsti rezultatus, o šiaip jeigu prireiks šio sprendimo – naudokit į sveikatą ir neminėkit piktuoju, jeigu kas nors neveiks. Bandysiu pritaikyti ir vertikalų centravimą, tačiau bijau, kad aukštesniems elementams jis neveiks… Todėl eksperimento rezultatuose yra variantas, kuris pakeičia vidinio paveikslėlio aukštį – darant tai naršyklėje vaizdas kiek sugenda, tačiau galbūt geriau negu nieko?