HTML: n rakenteelliset elementit - artikkeli, osa, nav ja sivut - ovat ensi silmäyksellä joitain HTML5-määrityksen helpoimmista osista ymmärtämään ja toteuttamaan. He ovat kuitenkin itse asiassa joitain huonosti määriteltyjä, huonosti ymmärretyistä ja huonosti toteutettuja HTML5-osia.

Luotu mielivaltaisesti; he yrittävät ottaa käyttöön aivan uuden tavan jäsentää verkkosivuja; ne rikkovat HTML: n omia suunnitteluperiaatteita; ne vahingoittavat esteettömyyttä joillekin käyttäjille; ja sinun ei pitäisi käyttää niitä.

Kyllä, tulen ulos aseista, jotka kiihdyttävät tätä HTML5: n osaa, mutta älä ota oleta, että olen "anti-HTML5". Olen kirjoittanut kirjan HTML5: sta , Rakastan avointa verkkoa, rakastan hyviä webstandardeja ja rakastan sitä tosiasiaa, että työskentelyn jälkeen kymmenen vuoden stagnaation jälkeen innovaatio verkkotekniikoissa tapahtuu nyt täysin rakkuloilla. Tämä ei kuitenkaan tarkoita sitä, että meidän on hyväksyttävä kaikki, mitä meille annetaan. Meidän ei tarvitse syödä kaikkea HTML5-levyltä, vaikka löydämme osia lautasesta varsin maukkaalta. Jotkut osat on todennäköisesti lähetettävä takaisin kokkiin.

Aivan valtava HTML5-määrittely on hyviä ja huonoja osia, ja aiomme ajatella kriittisesti erästä täsmällistä osaa spesifikaatiosta: elementtien tai "rakenteellisten" elementtien HTML5 esittely. Jätkäämme sitten etsiväsi hatut ja tarkastelemme, mistä nämä uudet elementit todella tulevat, miten niitä käytetään, ja miten me, verkkoyhteisöyhteisö, ovat olennaisesti väärin ymmärtäneet ne, lähinnä haitannut spec. Me kyseenalaistetaan näiden elementtien perusta ja räjäytämme muutamia myyttejä niistä matkan varrella.

Mistä HTML5: n rakenteelliset elementit ovat peräisin?

Let's pudota yksi myytti, joka on toistettu ad nauseum näistä elementeistä: ajatus, että ne perustuvat tutkimukseen siitä, miten me, verkkoyhteisö, merkitsivät asiakirjamme. Se on myytti, joka on toistunut kirjoissa, blogeissa ja keskusteluissa vuosia, eikä se ole totta. Kuinka tiedän? Kysyin.

Kun tutkin näiden elementtien alkuperää, päätin kysyä HTML5-spesifin, Ian Hicksonin, toimittajalta, josta nämä elementit tulivat. Hän vastasi:

Me ja muut WHATWG-avustajat [lisäsivät], [in] 2004ish, koska ne olivat ilmeisiä elementtejä lisätäksesi sen jälkeen, kun tekijät käyttivät HTML4: ää. Me myöhemmin (vuoden 2005 loppupuolella 2006) teimme joitain objektiivisia tutkimuksia selvittääksesi, mikä oli kymmenen parhaan HTML-luokkaa, ja kävi ilmi, että ne sopivat olennaisilta osiltaan elementteihin, jotka oli lisätty, mikä oli kätevää.

Hajottakaamme tämän: ensin Hickson ja WHATWG: n jäsenet lisäsivät nämä elementit ennen kuin kaikki tutkimukset tehtiin . Voit sukeltaa WHATWG: n (onneksi julkisiin) postituslistan arkistoihin ja löytää aikaisista keskusteluista näistä elementeistä itsellesi. Esimerkiksi näet, että Hickson keskusteli niistä marraskuussa 2004, ja kommentteja olivat esimerkiksi Tämä :

Kyllä, aiomme sisällyttää tavaraa, kuten [semanttisia elementtejä] Web-sovelluksissa. Toimistossani olevaan taululle on tällä hetkellä otsikkokohta "HTML5 BLOCK LEVEL ELEMENTS", ja yritän selvittää, miten ne toimivat hyvin (kyseiset elementit mainitaan parhaillaan luonnoksessa, mutta luonnos ei käsittele otsikoita ollenkaan). En ole vielä katsellut inline-merkintää, mutta se on myös kortteja.

Se näyttää siltä, ​​miten HTML5-rakenteellinen semanttinen merkitsi: yksi mies, yksi valkeus ja jotkut muiden WHATWG-jäsenten tulot. (WHATWG tai Web Hypertext Application Technology -työryhmä muodostettiin selaimen edustajista vastauksena W3C: n hylkäämiseen HTML: stä XHTML 2.0: n utopialaiselle ihanteelle).

Muutamien asiakirjojen käyttämät elementit, joista keskustelemme ja keskustelimme, näyttävät mielivaltaisesti mielikuvitukseltaan vuoden 2004 HTML5-editoriin. (Ja he tapasivat järkevä kritiikki ja joitain valitettavasti tarkkoja ennusteita melkein välittömästi.)

Kollektiiviset takana

Tantek on vaatinut pitkään eteenpäin tutkimusta, ennen määrittelemistä uusia muotoja mikroformaattien yhteydessä, ja lopuksi WHATWG-määritykset suunnitellaan vastaavasti todellisilla tiedoilla sen sijaan, että voimme vetää tavaraa kollektiivisten taustatietojen ulkopuolelle. - Ian Hickson

Tämä tuo meidät toiseen asiaan. Joulukuussa 2005 - vuoden kuluttua näiden uusien elementtien syntymisestä - Hickson (Googlen työntekijä) teki jonkin verran tutkimusta siitä, miten asiakirjat luotiin Googlen laajan dokumenttitietokannan avulla. Tutkimus oli "analyysi hieman yli miljardin asiakirjan otosta, joka keräsi tietoa suosituista luokkien nimistä, elementeistä, ominaisuuksista ja niihin liittyvistä metatiedoista." Tunnukset eivät sisälly tutkimukseen. Googlen julkaisemat tulokset julkaistiin Verkkosivustotilastot (2005) .

Tutkimuksen kriittinen osa HTML: n rakenteellisten elementtien osalta oli luokkien tulokset , joka käytti otosta, jossa ~ 900 miljoonaa 1 miljardista asiakirjasta ei ilmeisesti ollut luokkia lainkaan, sisälsi joitain yhteisiä luokkia. Olen varma, että olemme kaikki käyttäneet projekteissamme aiemmin: alatunniste, valikko, nimi, pieni teksti , sisältö, otsikko, nav, tekijänoikeus, painike, tärkeimmät ja niin edelleen.

Hickson antaa sitten spin-tietonsa, mikä viittaa siihen, että nämä luokat "todella [kartoittavat] hyvin elementteihin, joita ehdotetaan HTML5: ssä", ja tarjoaa taulukon, jossa verrataan tutkimuksen tuloksia ja HTML5: n uudet elementit: alatunniste luokka on tutkimuksessa, alatunnisteelementti on HTML5: ssa; otsikossa on otsikko , HTML5- otsakkeen elementti; luokkiin teksti , sisältö , pää , elin ovat tutkimuksessa, ja err ... artikkeli on HTML5: ssä, joka, kuten näemme, ei täsmää lainkaan; osaa ei ole lainkaan löytynyt, mikä on myös syytä mainita.

Tämä on nimellisarvoltaan riittävän kohtuullinen. Käytän alatunnistetta, käytät alatunnistetta, alatunniste on HTML5: ssä. Mikä on ongelma?

Ongelma on, jos luet todellisen HTML5-määritys , HTML5-elementit määritellään tavalla, jolla ei ole paljon tekemistä sen kanssa, miten olemme perinteisesti käyttäneet niitä.

Toisaalta Hickson on tuonut aivan uuden käsitteen HTML5: n web-sivun jäsentämiseen leikkauselementeillä . Toisaalta Hickson vertailee HTML5-leikkauselementtinsä luonnossa käytetyille luokille, eikä ymmärrä, mitä kyseisiä luokkia todella käytettiin. Klassinen esimerkki on "otsikko", jota useimmat meistä käyttävät sivun yläosassa olevaan alueeseen, mutta HTML5-spec, ehdottaa, että voit käyttää sitä jokaisen sivun kommentin otsikkoon . Todella. Vain siksi, että tutkimuksessa ja elementeissä HTML5: ssä on samat nimikkeet, ei tarkoita, että niiden käyttötarkoitukset ovat samat.

Nyt, jos ilmoitettiin selkeästi, että uusia elementtejä otettiin käyttöön uudella tarkoituksella ja selkeällä perustelulla, niin se ei olisi niin huono. Mutta sitä ei ole, mitä meille on kerrottu.

tässä Hickson vuonna 2009 , vastaamaan kysymykseen osion, nav, artikkelin, sivun ja muiden tarkoitusperistä:

Ne täyttävät tavallisimmat pyynnöt Web-kehittäjiltä, ​​jotka perustuvat tavallisimpiin attribuuttien arvot class = "". Niiden päätavoitteena on yksinkertaistaa kirjoittamista ja muotoilua.

Valitettavasti tämä näyttää olevan tapaus, jossa HTML5-editori, kaiken hänen hyvää työtäsä vetäessään spec yhdessä, on (olemaan antelias) unohdettu, miksi hän lisäsi nämä elementit siihen, mikä on olennaisesti hänen spec. Ehkä se on aikaero vuosina 2009 ja 2004, kuka tietää. Mutta tiedämme tämän: HTML5-leikkauselementtejä ei lisätty täyttämään "web-kehittäjien yleisimpiä pyyntöjä" lainkaan. Mistä tiedämme? Voimme vain tarkastella luetteloa, ja nähtävästi tärkeimpiä elementtejä, kuten osioelementti (ja siihen liittyvä artikkeli ja sivuosielementit), eivät näy yhteisten luokkien attribuuttien tutkimuksessa.

Vaikka Hickson olisi unohtanut, miksi nämä elementit on lisätty, voimme silti kiittää todisteita, jotka dokumentoivat tarkoituksensa.

Mutta mitä tapahtuu, kun kerrot, että web-suunnittelijat ja kehittäjät eivät ole huolissasi, nämä elementit korvaavat vain, mitä teet jo, ja määritä nämä elementit tavalla, joka ei todellakaan ole mitä web-suunnittelijat ja kehittäjät tekivät? Laitat heidät yksisuuntaiseen matkaan sekaannusta kaupunkiin.

Tämä on huonoin tutkimus: laiska tulkinta tietojen tekemiseksi perustellakseen jo tehtyjä päätöksiä. HTML5: n usein toistuva suunnitteluperiaate on " avata luontopolut ", eli" Kun käytäntö on jo laaja kirjoittajien keskuudessa, harkitse sen omaksumista sen sijaan, että se kieltäisi sen tai keksisi jotain uutta ". Ja niin näyttäisi näiltä uusilta rakenteellisilta elementteiltä: osasta, artikkelista, nav: sta ja sivusta (ja otsikosta ja alatunnistuksesta) - nämä ovat vain "päällystyskaivureita"?

Tämä on vaikutelma, että monet meistä ovat saaneet, koska meille on kerrottu, että he ovat.

Itse asiassa lähes viisi vuotta sitten, kun saimme ensimmäisen kerran HTML5: n esikatselu , näytti siltä, ​​että nämä elementit voisivat yksinkertaisesti korvata "unsemanttiset" divit, joita tottumme käyttämään. Mikä oli div id = "otsikko" sivun yläosassa, voisi nyt olla vain otsikko ; div id = "footer" voi nyt tulla vain alatunnisteeksi , ja divimme voisi olla vain artikkeli. Yksinkertainen, eikö?

Olemme saaneet mallin

Valitettavasti siitä huolimatta, että olemme tehneet sen, mitä meille kerrottiin (eli vain vaihtaa toinen toiselle), olemme todellisuudessa panneet nämä elementit täytäntöön tavalla, joka ei näy HTML5-spec: ssa. Eli kun kyseessä on HTML5-rakenne, olemme olennaisesti kehittäneet spec. Tällä hetkellä on olemassa kaksi HTML5-rakenteellista menetelmää - yhteisön tulkinta, joka näkyy vuoden 2007 A List Apart -artikkelissa (ja lukemattomissa muissa); ja todellinen HTML5-spesifikaatio, joka tuo mukanaan aivan uudenlaisen tavan jäsentää ns.

Tämä on ristiriita HTML: n rakenteellisen semanttin ytimessä. Toisaalta meillä on toimittaja, joka kertoo meille, että uudet elementit perustuvat tutkimukseen siitä, mitä olimme jo tekemässä, ja sen vuoksi tarkoituksena on vain tehdä teksteistä hieman helpompaa; ja toisaalta meillä on se, mitä HTML5-spesifikaatiossa todella on luotu, mikä on uusi tapa jäsentää www-sivua tavalla, joka luo dokumentin ääriviivat käyttämällä leikkauselementtejä .

Täällä oli selvä valinta. Hylkää HTML5-suunnitteluperiaatteita ja esitä jotain uutta tai yksinkertaisesti seuraa todellista kirjoittamisen käytäntöjä ja määritä elementit tavalla, joka heijastaa web-suunnittelukäytäntöä. Hickson yritti tehdä entisen ja kutsua sitä jälkimmäiseksi, ja meillä on nyt yksi suuri sotku käsissämme.

Hungry lisää? Tämän artiklan toinen osa on nyt saatavilla ja Lukein kirja "The Truth About HTML5" on saatavilla rajoitetun ajan sisko-sivuston kautta MightyDeals.com hämmästyttävällä 50%: lla.

Käytätkö HTML5-rakenneosia? Löysitkö ne hyödyllisiksi tai esteenä? Kerro meille kommentit.

Esitetty kuva / pikkukuva, käyttää rakennekuva kautta Shutterstock.