HTML's structurele elementen - artikel, sectie, nav en terzijde - zijn op het eerste gezicht enkele van de gemakkelijkste onderdelen van de HTML5-specificatie om te begrijpen en te implementeren. Ze zijn echter eigenlijk enkele van de slechtst gespecificeerde, slecht begrepen en slecht geïmplementeerde delen van HTML5.
Willekeurig gemaakt; ze proberen een geheel nieuwe manier te bieden om webpagina's te structureren; ze zijn in strijd met de eigen ontwerpprincipes van HTML; ze schaden toegankelijkheid voor sommige gebruikers; en je zou ze niet moeten gebruiken.
Ja, ik kom met geweren op de proppen tegen dit specifieke deel van HTML5, maar neem alsjeblieft niet aan dat ik 'anti-HTML5' ben. Ik heb een boek geschreven over HTML5 , Ik ben dol op het open web, ik hou van goede webstandaarden en ik ben er dol op dat na een decennia van stagnatie de innovatie in webtechnologieën nu met een uiterst zinderende snelheid plaatsvindt. Dat betekent echter niet dat we alles moeten accepteren wat we krijgen. We hoeven niet alles op de HTML5-plaat te eten, ook al vinden we delen van het gerecht best lekker. Sommige delen moeten waarschijnlijk worden teruggestuurd naar de chef-kok.
Er zijn goede en slechte onderdelen van de vrij enorme HTML5-specificatie en we gaan kritisch nadenken over een heel specifiek deel van de specificatie: de secties of 'structurele' elementen die HTML5 introduceert. Dus laten we onze detectivehoeden opleggen en kijken waar deze nieuwe elementen echt vandaan komen, hoe ze verondersteld worden gebruikt te worden en hoe wij, de webontwerpgemeenschap, ze fundamenteel verkeerd hebben begrepen, voornamelijk het specken. We zullen de basis voor deze elementen in twijfel trekken en onderweg een aantal mythes over hen op de borst slaan.
Laten we één mythe verslaan die Ad nauseum herhaald heeft over deze elementen: het idee dat ze gebaseerd zijn op onderzoek naar hoe wij, de webgemeenschap, onze documenten markeerden. Het is een mythe die al jarenlang wordt herhaald in boeken, blogs en lezingen, en het is gewoon niet waar. Hoe moet ik dat weten? Ik heb gevraagd.
Toen ik de oorsprong van deze elementen onderzocht, besloot ik de editor te vragen naar de HTML5-specificatie, Ian Hickson, waar deze elementen vandaan kwamen. Hij antwoorde:
Ik en andere WHATWG-bijdragers [voegden ze toe], [in] 2004ish, omdat het voor de hand liggende elementen waren om toe te voegen nadat ze hadden gezien hoe auteurs HTML4 gebruikten. We hebben later (eind 2005, begin 2006) wat objectief onderzoek gedaan om erachter te komen wat de top tien HTML-klassen waren en het bleek dat ze in principe exact overeenkwamen met de elementen die we hadden toegevoegd, wat handig was.
Laten we dit uiteenzetten: eerst hebben Hickson en de WHATWG-leden deze elementen toegevoegd voordat er onderzoek werd gedaan . Je kunt duiken in de WHATWG's (gelukkig openbare) archieven van de mailinglijst en zelf beginnen met het ontdekken van vroege discussies over deze elementen. Je kunt bijvoorbeeld Hickson in november 2004 bespreken, met opmerkingen zoals deze :
Ja, ik ben van plan om dingen als [semantische elementen] op te nemen in Web Apps. Het whiteboard in mijn kantoor heeft momenteel een lijst met elementen onder de kop "HTML5 BLOKNIVEAUELEMENTEN", en ik probeer uit te werken hoe ze goed te laten werken (de elementen in kwestie worden momenteel vermeld in het concept, maar het concept kan de kopteksten helemaal niet goed verwerken). Ik heb nog niet naar inline markup gekeken, maar dat staat er ook op.
Dat is, zo lijkt het, hoe de HTML5 structurele semantiek ontstond: één man, één whiteboard en wat input van andere WHATWG-leden. (De WHATWG, of Web Hypertext Application Technology Working Group, werd gevormd door vertegenwoordigers van browsers in reactie op het achterlaten van HTML door de W3C voor het utopische ideaal van XHTML 2.0).
De elementen die worden gebruikt door miljoenen documenten die we hebben besproken en besproken, zijn blijkbaar willekeurig gemaakt in een opwelling van de HTML5-editor in 2004. (En werden ontmoet met een scherpzinnige kritiek en sommige helaas nauwkeurige voorspellingen bijna onmiddelijk.)
Tantek heeft al lange tijd aangedrongen op onderzoek-voor-specificeren-nieuwe formaten in de microformats-context, en tot slot zullen de WHATWG-specificaties op dezelfde manier worden ontworpen met feitelijke gegevens, in plaats van dat we spullen uit onze collectieve billen trekken. - Ian Hickson
Dat brengt ons bij het tweede punt. In december 2005, ongeveer een jaar na het bedenken van deze nieuwe elementen, deed Hickson (een medewerker van Google) enig onderzoek naar de manier waarop documenten werden geschreven met behulp van de enorme documentendatabase van Google. Het onderzoek was 'een analyse van een steekproef van iets meer dan een miljard documenten, die informatie verzamelde over populaire klassenamen, elementen, attributen en gerelateerde metadata.' ID's werden niet opgenomen in het onderzoek. De bevindingen zijn door Google gepubliceerd als Web Authoring Statistics (2005) .
Het kritieke deel van het onderzoek, wat betreft de structurele elementen van HTML, was de lessen bevindingen , wat, ondanks het gebruik van een voorbeeld waarbij ~ 900 miljoen van de 1 miljard documenten blijkbaar helemaal geen klassen hadden, enkele algemene klassen bevatte, ik weet zeker dat we allemaal eerder in onze projecten hebben gebruikt: footer, menu, titel, klein, tekst , inhoud, koptekst, nav, copyright, button, main, enzovoort.
Hickson geeft vervolgens zijn draai aan de gegevens, suggererend dat deze klassen 'erg goed passen bij de elementen die in HTML5 worden voorgesteld' en biedt een tabel waarin de resultaten van het onderzoek worden vergeleken met de nieuwe elementen in HTML5: een voettekst klasse is in het onderzoek, een voettekstelement is in HTML5; een header- klasse is in het onderzoek, een header- element is in HTML5; de klassen text , content , main , body staan in het onderzoek, en err ... article staat in HTML5 wat, zoals we zullen zien, helemaal niet overeenkomt; sectie is helemaal niet te vinden, wat ook het vermelden waard is.
Op het eerste gezicht genomen is dit allemaal redelijk genoeg. Ik gebruik voettekst, u gebruikt voettekst, voettekst is in HTML5. Wat is het probleem?
Het probleem is, als je de feitelijke leest HTML5-specificatie , de elementen in HTML5 zijn gedefinieerd op een manier die weinig te maken heeft met hoe we ze traditioneel hebben gebruikt.
Aan de ene kant heeft Hickson een heel nieuw concept geïntroduceerd voor het structureren van een webpagina in HTML5 met deelelementen . Aan de andere kant vergelijkt Hickson zijn HTML5-segmentelementen met klassen die in het wild worden gebruikt zonder te weten waarvoor die klassen daadwerkelijk zijn gebruikt. Een klassiek voorbeeld is 'koptekst', die de meesten van ons zouden gebruiken voor het gebied bovenaan de pagina, maar de HTML5-specificatie suggereert dat u het kunt gebruiken voor de kop van elke opmerking op een pagina . Werkelijk. Alleen omdat klassen in het onderzoek en elementen in HTML5 dezelfde naam hebben, betekent niet dat hun gebruik hetzelfde is.
Nu, als duidelijk werd gecommuniceerd dat nieuwe elementen werden geïntroduceerd met een nieuw doel en een duidelijke reden, dan zou dat niet zo erg zijn. Maar dat is niet wat ons is verteld.
hier is Hickson in 2009 , reageren op een vraag over het doel van sectie, nav, artikel, terzijde en anderen:
Ze vullen min of meer de meest voorkomende verzoeken van webontwikkelaars in op basis van wat de meest voorkomende class = "" attribuutwaarden zijn. Hun voornaamste doel is het vereenvoudigen van het ontwerpen en stylen.
Helaas lijkt dit een geval te zijn waarin de HTML5-editor, voor al zijn goede werk in het samen trekken van de spec, (laten we vrijgevig zijn) vergeten waarom hij deze elementen heeft toegevoegd aan wat in wezen zijn spec is. Misschien is het het tijdsverschil tussen 2009 en 2004, wie weet. Maar we weten dit wel: de HTML5-segmentelementen zijn niet toegevoegd om 'de meest voorkomende verzoeken van webontwikkelaars' helemaal te vullen. Hoe weten we? We kunnen alleen naar de lijst kijken en zien dat de meest fundamentele elementen die toegevoegd zijn, zoals het sectie-element (en het gerelateerde artikel en opzij geplaatste elementen), niet voorkomen in het gemeenschappelijke klassenattributenonderzoek.
Hoewel Hickson misschien is vergeten waarom deze elementen zijn toegevoegd, kunnen we gelukkig nog steeds de specificatie lezen die hun doel documenteert.
Maar wat gebeurt er wanneer u webontwerpers en ontwikkelaars vertelt dat u zich geen zorgen hoeft te maken, deze elementen vervangen gewoon wat u al doet en specificeren deze elementen op een manier die zeker niet is wat webontwerpers en ontwikkelaars aan het doen waren? Je zet ze op een enkele reis naar de verwarringstad.
Dit is het ergste soort onderzoek: een luie interpretatie van gegevens die zijn gedaan om reeds gemaakte beslissingen te rechtvaardigen. Een vaak herhaald ontwerpprincipe van HTML5 is om ' effenen de koeienpaadjes ', dat is' Wanneer een praktijk al wijdverspreid is onder auteurs, overweeg dan om het te adopteren in plaats van het te verbieden of iets nieuws uit te vinden. ' En zo lijkt het met deze nieuwe structurele elementen: sectie, artikel, nav en opzij (en kop- en voettekst) - bijna zijn dit gewoon 'de koeienpadden bestraten'?
Dat is de indruk die velen van ons hebben, want dat is wat ons is verteld.
Sterker nog, bijna vijf jaar geleden, toen we voor het eerst een voorbeeld van HTML5 , het leek erop dat deze elementen eenvoudigweg de 'unsemantic' div's konden vervangen die we gewend waren te gebruiken. Wat was div id = "header" aan de bovenkant van de pagina zou nu gewoon koptekst kunnen worden ; div id = "footer" kan nu gewoon voettekst worden en onze div kan gewoon een artikel zijn. Eenvoudig, toch?
Helaas hebben we, ondanks het doen wat ons werd verteld (dat wil zeggen, gewoon ruilen voor de ander), deze elementen daadwerkelijk geïmplementeerd op een manier die niet wordt weerspiegeld in de HTML5-specificatie. Dat wil zeggen, als het gaat om HTML5-structuur, hebben we in feite de specificatie gesplitst. Er zijn momenteel twee methoden voor HTML5-structuur: de interpretatie van de community, die wordt weerspiegeld in het artikel A List Apart uit 2007 (en talloze andere); en de eigenlijke HTML5-specificatie, die een geheel nieuwe manier introduceert om een webpagina met de naam outline te structureren.
Dit is de tegenstrijdigheid die centraal staat in de structurele semantiek van HTML. Aan de ene kant laten we de redacteur ons vertellen dat de nieuwe elementen gebaseerd zijn op het onderzoek naar wat we al deden, en daarom bedoeld zijn om het maken van een beetje eenvoudiger te maken; en aan de andere kant hebben we wat de editor feitelijk heeft gemaakt in de HTML5-specificatie, wat een nieuwe manier is om een webpagina zo te structureren dat een documentoverzicht wordt gegenereerd met behulp van segmentelementen .
Er was een duidelijke keuze om hier gemaakt te worden. Breek met de HTML5-ontwerpprincipes en introduceer iets nieuws, of volg eenvoudigweg de echte schrijfpraktijken en specificeer elementen op een manier die webontwerppraktijken weerspiegelt. Hickson probeerde het eerste te doen en noemde het het laatste, en we hebben nu één grote puinhoop aan onze handen.
Honger naar meer? Deel twee van dit artikel is nu beschikbaar en Luke's boek "The Truth About HTML5" is voor een beperkte tijd beschikbaar via onze zustersite MightyDeals.com met een verbazingwekkende 50% korting.
Werk je met structurele HTML5-elementen? Vind je ze nuttig of een belemmering? Laat het ons weten in de comments.
Uitgelichte afbeelding / miniatuur, gebruik structuur afbeelding via Shutterstock.