Sisään tämän sarjan ensimmäinen osa käsittelemme puutteita, jotka johtavat HTML5: n rakenteellisiin elementteihin, tässä toisessa osassa tarkastelemme yksityiskohtaisesti näiden puutteiden seurauksia.
Olen sanonut useita kertoja, että HTML5 tuo uudenlaisen menetelmän web-sivun jäsentämiseen, ja sinä luulet miettimättä, mikä se todella on. Se on täsmälleen oikeassa, mikä esittelee käsitteen "jakaminen sisältöä ': jakaminen sisältö on sisältöä, joka määrittää otsikoiden ja alatunnisteiden soveltamisalaa. Jokaisella leikkaussisältöelementillä voi olla otsikko ja ääriviivat.
Tieto dokumentoi sen lähestymistavan otsikot, osuudet ja ääriviivat tehdä käsite selkeäksi. Selvä niille, jotka tarvitsevat selaimissa toimivan toiminnon. Jotta voimme ymmärtää HTML: n rakenteellisia elementtejä (osio, artikkeli, nav, syrjään ja niihin liittyvät elementit otsikko ja alatunniste) ja tämä hämärä käsitys "leikkauksen sisällöstä" tai "hahmottelemisesta", tarvitsemme hieman matkaa HTML-historian kautta.
HTML5: ssä esitelty kuvaaja voidaan jäljittää vuoteen 1991 ja se on sisällytetty epäonnistuneeseen umpikujaan XHTML 2.0 -spektriin ja lopulta näkee päivänvalon HTML5: ssä ... vain niin huonosti kommunikoidusti, että ajatus on melko kuollut saapumisen yhteydessä.
Ennen HTML5: ta sivun hierarkkinen rakenne määriteltiin otsikkokohdista - vanhat ystäväsi h1: stä h6: een. Voimme rakentaa sivun sanomalla, että sivun otsikko on h1, artikkelin otsikko voi olla h2 ja kenties artikkelin alanimikkeet voivat olla h3 ja h4 ja niin edelleen.
Tämä on hieno yksinkertainen asiakirja, mutta otsikkotunnisteiden luominen loogisen hierarkian tai "asiakirjan ääriviivan" luomiseksi monimutkaiselle, modernille verkkosivulle on hyvin vaikeaa. Osa ongelmasta on puute tapa määrittää, mistä sivun osio alkaa ja pysähtyy. Esimerkiksi sanomme, että meillä oli aiemmin mainittu asiakirja h1: lla sivun otsikkoa varten, h2 artikkelin otsikolla, h3 alanimikkeille, mutta halusimme myös merkitä sivupalkkiosiosi otsikon myös h3-otsikoilla.
Asiakirjassa, jossa tällainen rakenne luo, näyttää olevan jotain tällaista:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Tässä h3-elementit ovat "niiden omistuksessa" h2: n yläpuolella, vaikka niillä ei olisi paljon järkeä. Tietenkin, me hajottaisimme nämä asiat jotain divilla artikkelille ja div sivupalkille, mutta käyttäjäagentit (kuten näytönlukijat) eivät ota niitä huomioon, jotka määrittelevät sivun ääriviivat yksinomaan otsikkorakenteella.
Sitomalla sivuhierarkia suoraan sellaisiin usein esittämistason otsikkotasoksi, meillä on vain rajoituksia siitä, miten voimme rakentaa sivun.
Yritettäessä ratkaista tämä ongelma HTML5 tuo esiin "leikkauselementtien" käsitteen, eli erikoiselementit, jotka jakavat sivun ylös - olet arvannut sen - osiot ja nämä osat määrittävät otsikoiden pesimistason ja jopa hierarkian , tai sivun "ääriviivat".
Toisin sanoen sivun hierarkia irtoaa otsikoista, ja sen sijaan nämä uudet leikkauselementit määrittävät minkä tason otsakeelementti todella on.
Ensimmäisessä luonnoksessa XHTML 2.0 -spesifikaatio , leikkaus toimi elementtielementillä ja yleinen otsikko h -elementti. Kun kirjoitit HTML-koodia, emme sitten määrittäisi mitä otsikkotasoa halusimme käyttää, annamme selaimen määrittää tietyn otsikon pesintatason. Voisimme upottaa osaelementtejä 99 tasoja syvälle, ja h-elementti 99. tasolla vastaisi h99-elementtiä. Näin pystymme jäsentämään asiakirjamme loogisesti huolimatta siitä, kuinka voimme käyttää rajoitettuja h1-h6-elementtejä.
(Tämä ajatus todella on peräisin vuodelta 1991, muuten: Jeremy Keith Tim Berners-Lee esitti ajatuksen osasta ja h-elementistä sivun rakentamiseksi vuoden lopussa lokakuu 1991 sähköposti .)
Hickson yritti ottaa tämän saman konseptin käyttöön HTML5: ksi, mutta lisättyyn vaikeuteen: hän halusi ylläpitää taaksepäin yhteensopivuutta ja esitellä joitain uusia semanttisia "yksinkertaistamaan kirjoitusta" käynnistämiseen. Siksi, sen sijaan, että käytämme HTML5-osiossa olevaa elementtiosaa, meillä on myös artikkeli, nav, ja syrjään elementti, jotka kaikki käyttävät samoja osia kuin eri nimet, joita käytetään eri tavoin.
Mitä spec kertoo näistä elementeistä? Kehotan sinua lue esittely itse , mutta tässä on maku:
Osa-elementti on perusta, jonka avulla voit luoda dokumentin ääriviivat.
Osio-osa edustaa asiakirjan tai sovelluksen yleistä osaa. Osa tässä osassa on temaattinen sisällön ryhmittely, tyypillisesti otsikolla.
Esimerkkejä osista ovat luokat, välilehdet-välilehden eri välilehtiset sivut tai diplomityön numeroidut osiot. Verkkosivun kotisivut voidaan jakaa osioihin johdanto-, uutis- ja yhteystietoihin.
Tieteessä oleva huomautus sanoo, että elementtiä ei pitäisi käyttää pelkästään muotoilutarkoituksiin - div olisi parempi siellä ja ymmärrettävästi, sillä osuudet, jotka heijastuivat valehtelematta muotoiluun, tekisivät hyvin rikki asiakirjan ääriviivat.
Huomautus jatkuu sanoen: "Yleinen sääntö on, että osa-elementti on tarkoituksenmukainen vain, jos elementin sisältö mainitaan nimenomaisesti asiakirjan hahmossa" ja se on selkein lausuma speksin osa-elementistä.
Kun ymmärrämme poikkileikkauksen ja kuvittelun käsitteen, osaelementin sisällyttäminen on järkevää. Se ei näkynyt yhteisten arvojen tutkimuksessa, mutta se esiintyi XHTML 2.0: ssa, ja se on peräisin käsitteellisesti vuodelta 1991.
Muut HTML5: n rakenteelliset elementit - ne, jotka oletettavasti heijastuivat tutkimuksessa - ovat täsmälleen samanlaiset kuin leikkauselementti, mikä on asiakirjahahmoa. He myös luo sivun hierarkian ja siten asiakirjan ääriviivat.
Ota esimerkiksi artikkelielementti. Monet ihmiset olettavat, että se on yksinkertaisesti artikkeleita kuten tämä. Mutta se ei ole ollenkaan. Se on "artikkeli" merkityksessä "vaatekappale". On parempi ajatella "esineeksi" kuin "vaatekappaleessa", koska sen määritelmä on niin laaja.
Kun artikkelielementit ovat sisäkkäisiä, sisäisen artikkelin elementit edustavat artikkeleita, jotka periaatteessa liittyvät ulkoisen artikkelin sisältöön. Esimerkiksi blogikirjoitus sivustolle, joka hyväksyy käyttäjän toimittamat kommentit, voivat edustaa kommentteja artikkelin elementteinä, jotka on sijoitettu blogimerkinnän artikkelielementtiin.
HTML5: ssa käyttäjätunnukset, asianmukainen artikkeli, foorumin viestit ja jopa "interaktiiviset widgetit ja gadgetit" ovat kaikki artikkeleita. Määritelmä on niin leveä, että se on hyödytöntä - semantiikan on tarkoitus antaa merkitys, mutta käyttämällä kollektiivista termiä niin monenlaisille kohteille tekee elementistä merkityksetön.
Tämä on yksi esimerkki, jossa olemme saaneet mallin - muutamat ihmiset seuraavat täsmällisesti ja tekevät melkein kaiken artikkelin (blogin tiivistelmät, blogiviestit, kommentit, widgetit, foorumin viestit jne.), Kun taas toiset ovat pitäneet sitä vain sivun pääartikkeliin, joka on vain yksi osa sen laajaa määritelmää. Saatat ajatella, ettei sillä ole merkitystä, ja suurelta osin olisit oikeassa. Mutta ajattele kaikkia niitä lukulaitoksia, jotka pyrkivät vain jäsentämään sivun pääsisältöä. Minkä erityispiirteen toteutusta ne seuraavat? Pitäisikö heidän seurata, mitä spec todella sanoo, vai pitäisikö he seurata yleistä yhteisön toteutusta, jossa yleensä on vain yksi canonical "artikkeli" sivulla?
Tämä on menetetty tilaisuus, ja mitä tapahtuu, kun määrittely ei oikeastaan määritä , ja toimittaja ja oikeudenmukainen yhteisö ei välitä mitä spec itse asiassa sanoo.
Kuvittele, että artikkelia ei käytetä myös kommentteihin. Kuvittele, jos kommentit saivat omat elementtinsä ja esimerkiksi adoptio tuli laajalle. Selaimen tekijät voivat lisätä "mykistyskommentteja" -toiminnon, joka helposti piilottaa (tai muuten jäsentää) kommentteja verkkosivuilla. Mutta Hickson on nimenomaisesti kieltäytynyt pyytämästä kommenttielementtiä . HTML5: ssa artikkeleita alas.
Erona on toinen elementti, joka ei näy missään Hicksonin luokkatietotutkimuksessa, ja saa hyvin erikoisen määritelmän käynnistää:
Sivustoelementti edustaa sivun osaa, joka koostuu sisällöstä, joka on tangentiaalisesti sidoksissa syrjään elementin ympärille, ja jota voidaan pitää erillisenä kyseisestä sisällöstä. Tällaiset osuudet ovat usein edustettuina painetuissa typografioissa.
Elementtiä voidaan käyttää typografisiin vaikutuksiin, kuten vetoketjuihin tai sivupalkkeihin, mainostamiseen, nav-elementtien ryhmiin ja muuhun sisältöön, jota pidetään erillään sivun pääsisältöstä.
Kuka tietää, miksi sivun pitäisi kattaa sekä vedä lainausmerkit, sivupalkit, mainonta ja navigointielementtien ryhmät, vaan se luo myös uusia osioita asiakirjan ääriviivoihin. Tämä tarkoittaa, että vedon lainausmerkinnät saavat oman luettelomerkin asiakirjan ääriviivoista, mikä näyttää, sanotaan esimerkiksi, "outoa". Jälleen kerran hyvää tarkoittaville web-suunnittelijoilleen sattumanvaraista käyttöä on ja luodaan runsaasti rikki dokumenttien ääriviivoja.
Nav-elementti tuntuu itsestään selvimmin leikkauselementtejä, ja onneksi määritelmää ei ole venytetty rikkomatta.
Nav-elementti edustaa sivun osaa, joka linkittää muille sivuille tai sivun osiin: osio, jossa on navigointiyhteyksiä.
Mikä on hieno, ja sillä voisi olla teoreettisia saavutettavuusetuja (käyttäjäagentti voi ohittaa nav nav-linkit tai hypätä nav-linkkeihin - he eivät, mutta voisivat).
Ongelmana on, että "yksinkertaistamalla kirjoittamisen" ja korvaamalla divin nav-elementillä, räjäytämme navigoinnin tyylin toisen osajoukon käyttäjille. IE6-8- käyttäjät, joilla on JavaScript pois päältä (Yahoo-tutkimuksen mukaan 1-2% käyttäjistä on poistettu käytöstä ) ovat tämän ongelman uhreja. JavaScriptin ollessa pois päältä JavaScript-pohjainen HTML5-muoto, joka auttaa IE6-8: n ymmärtämään HTML5-elementtejä, ei toimi, joten selaimessa ei ole HTML5-elementtejä. Tämä voi vaikuttaa vain pieneen määrään käyttäjiä, mutta miksi vaikuttaa niihin?
Ylä- ja alatunnisteelementit ovat klassinen tapaus, jossa käytetään yhteisiä termejä ja annetaan heille hyvin erilaisia käyttötarkoituksia.
Esimerkki osoittaa, että kumpikaan näistä elementeistä ei luo uusia osioita asiakirjan ääriviivoihin, vaikka ne usein kuvataan olevan samansuuruisina kuin osio, nav, artikkeli ja syrjään. Itse asiassa he eivät tee mitään. Ne sisältyvät vain dokumentin ääriviivan tiettyyn osaan rajautuville alueille.
Seuraavassa kerrotaan, mitä spec kertoo otsakkeesta: otsakeelementti edustaa johdanto- tai navigointi-apujoukkoa.
Huomaa: otsikkokappaleen tarkoituksena on yleensä sisältää osan otsikko (h1-h6-elementti tai hgroup-elementti), mutta sitä ei vaadita. Otsikkoelementtiä voidaan myös käyttää osaston sisällön, hakulomakkeen tai minkä tahansa asiaankuuluvan logon pakkaamiseen.
ja alatunniste: alatunnisteelementti edustaa alatunnistetta sen lähimmälle esiasteosion sisällölle tai leikkauselementille. Jalka sisältää yleensä tietoja sen osasta, kuten kuka kirjoitti, linkit liittyviin asiakirjoihin, tekijänoikeustietoihin ja vastaaviin.
HTML5: ssä kehoelementti on itse asiassa juurihakemisto-elementti, joten yleinen otsikko ja alatunniste on tarkoitettu kuvaamaan juuren runko-osaa. Jokaisella jaksolla voi olla otsikko ja / tai alatunniste - niitä ei ole tarkoitettu vain yleisille otsikoille ja alatunnisteille, kuten olemme saattaneet olettaa. Yksittäisillä kommenteilla voi olla esimerkiksi otsikko ja alatunniste. Itse asiassa, kuten aiemmin kosketimme, spec todella antaa esimerkin alatunnisteen käytöstä kommentissa, joka on varsinainen kommenttisisältö. Se on oikein, HTML5-kommentit ovat artikkeleita, ja niillä voi olla alatunniste otsakkeelle, ja se on todellinen määrittely. Haluatko alatunnisteen elementit kommenttien otsikkoon? Ei? No, sinulla on yksi.
Tässä taas HTML5 käyttää yhteisiä termejä ja käyttää niitä tavoilla, jotka eivät ole tunnistettavissa yhteiselle web-kirjoittajalle.
Mutta on jotain, jota emme ole tarkastelleet HTML: n toteutuksessa leikkaus. Näitkö sen? Meillä on leikkauselementit, mutta meillä ei ole geneeristä h-elementtiä. Ei hätää, ratkaisu on speksissä :
Jaksot voivat sisältää minkä tahansa listan otsikoita, mutta kirjoittajia kehotetaan joko käyttämään vain h1-elementtejä tai käyttämään elementtejä, joilla on sopiva sijoitus lajin pesintäasteelle.
HTML5 haluaa olla taaksepäin yhteensopiva, joten WHATWG päätti olla ottamatta käyttöön h-elementtiä (vaikka se sisälsi joukon uusia leikkauselementtejä), ja haluaa sen sijaan muodostaa uudelleen h1-elementin yleiseksi h-elementiksi. Käytä h1: tä kaikkialla ja anna HTML5-piirtoalgoritmin määrittää sen todellisen tason ... tai niin teoria menee.
Tämä on kauhea ajatus useista syistä, joista kaksi tärkeintä ovat esteettömyys ja muotoilu.
Käyttämällä h1: tä kaikkialla on erittäin huono esteettömyys. Blind-käyttäjät luottavat voimakkaasti sivuston otsikkorakenteeseen. On tärkeää, että meille kaikille muistutetaan siitä, kuinka tärkeä otsake on esteettömyyden kannalta. Esimerkiksi joulukuussa 2008 kysely yli 1000 näytön lukija käyttäjille jonka toteuttama WebAIM totesi, että 76% sokeista ja näköhäiriöistä käyttäjistä "aina tai usein" navigoitiin otsikoissa, kun he olivat käytettävissä. Ja toukokuussa 2012 tehty tutkimus osoitti, että 82,1% otsikkotasot olivat "erittäin hyödyllisiä" tai "hieman hyödyllisiä" web-sivun navigoinnissa. (Tämä on hyvä, käytännöllinen tutkimus, joten huomioi.)
H1s: n käyttö kaikkialla tekee sivustoista vaikeammaksi navigoida sokeille käyttäjille. Teoriassa näytönlukijat käyttäisivät HTML: n hahmotelma-algoritmia ja selattaisivat asiakirjan ääriviivojen avulla, mutta kun otetaan huomioon tapa, jolla kirjoittajille on kerrottu toteuttaa leikkauselementtejä, hahmotellaan sotku ja yritetään navigoida dokumentin ääriviivoja, joita ei ole koskaan ajateltu. olla vielä huonompi sokeille käyttäjille.
HTML5-spec tarjoaa ulospääsyä: käytä sopivia h1-h6-tasoja ylläpitämään taaksepäin yhteensopivuutta. Mutta nyt säilytetään kaksi asiakirjaa ääriviivoja yhdessä asiakirjassa ja kun otetaan huomioon ongelmat, jotka kirjoittajat ovat saaneet ensi sijassa käsittelemään asiakirjan ääriviivoja, todennäköisyys kenen ylläpitämiseksi on sekä looginen h1-h6-ääriviiva että looginen, oikein -sectioned HTML5 -näkymä näyttää parhaimmalta.
Mutta se pahenee. Sanotaan haluamme ajaa puhtaalla HTML5-äärellä, ja käytämme h1: ää kaikkialla. Muista, että HTML5-mallissa h1 on vain yleinen h-elementti; sen tosiasiallinen taso määräytyy siitä, kuinka syvälle se on sijoitettu leikkauselementteihin.
Joten miten me muotoilemme sen? Voisimme lisätä luokan nimet kaikkiin h1-elementteihimme, jotta voimme noutaa ne, mutta se on vastoin HTML5: n tavoite yksinkertaistaa kirjoitusta; ja voimme myös pysyä h1-h6: llä (kaikkia käsitellään HTML-ääriviivojen yleisinä h-elementteinä).
Voisimme kokeilla ja muotoilla niitä kaskadin läpi, mutta tämä muuttuu nopeasti absurdiksi Nicole Sullivan huomautti . Itse asiassa "järjetön" alkaa vain kuvailla sitä. Kun tarkastelet osion, artikkelin, nav: n ja sivujen mahdollisia yhdistelmiä ja haluat luoda yleisen tyylin otsikolle, joka on esimerkiksi viisi tasoa syvä (eli vastaava h5), sinun pitäisi kirjoittaa tyylit kaikille mahdolliset yhdistelmät, jotka saavat aivan naurettavaa . Tässä on h3-elementin yleinen tyyli:
article aside nav h1, article aside section h1,article nav aside h1, article nav section h1,article section aside h1, article section nav h1, article section section h1,aside article nav h1, aside article section h1,aside nav article h1, aside nav section h1,aside section article h1, aside section nav h1, aside section section h1,nav article aside h1, nav article section h1,nav aside article h1, nav aside section h1,nav section article h1, nav section aside h1, nav section section h1,section article aside h1, section article nav h1, section article section h1,section aside article h1, section aside nav h1, section aside section h1,section nav article h1, section nav aside h1, section nav section h1,section section article h1, section section aside h1, section section nav h1, section section section h1 {font-size: 1.00em;}Silti tämä on mitä HTML: n rakenteelliset elementit antavat meille. Mikä sotku.
Hungry lisää? Kolmannen osan tässä artikkelissa 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ö artikkelielementtejä useita kertoja asiakirjassa? Ovatko osiot hyödyllisiä vai pitäisikö meidän pitää kiinni divs: stä? Kerro meille mielipiteesi kommentteihin.
Esitetty kuva / pikkukuva, käyttää rakennekuva kautta Shutterstock.