Gli elementi strutturali HTML - articolo, sezione, nav e a parte - sono, a prima vista, alcune delle parti più semplici della specifica HTML5 da comprendere e implementare. Tuttavia, sono in realtà alcune delle parti meno specificate, scarsamente comprese e mal implementate di HTML5.
Creato arbitrariamente; cercano di introdurre un modo completamente nuovo di strutturare le pagine web; violano i principi di progettazione propri dell'HTML; danneggiano l'accessibilità per alcuni utenti; e non dovresti usarli.
Sì, sto uscendo con le pistole, sfolgorando contro questa specifica parte di HTML5, ma per favore non presumere che io sia "anti-HTML5". Ho scritto un libro su HTML5 , Amo il web aperto, adoro i buoni standard web e adoro il fatto che dopo aver attraversato un decennio di stagnazione, l'innovazione nelle tecnologie web stia avvenendo ad una velocità assolutamente esplosiva. Ciò, tuttavia, non significa che dobbiamo accettare tutto ciò che ci viene dato. Non dobbiamo mangiare tutto sulla piastra HTML5, anche se troviamo parti del piatto piuttosto gustose. Alcune parti probabilmente devono essere rispedite allo chef.
Ci sono parti buone e cattive nella specifica HTML5, e penseremo in modo critico a una parte specifica della specifica: la sezione, o elementi "strutturali" che HTML5 introduce. Quindi mettiamo i nostri cappelli da detective e guardiamo da dove provengono veramente questi nuovi elementi, come dovrebbero essere usati, e come noi, la comunità del web design, li abbiamo fondamentalmente fraintesi, essenzialmente biforcando le specifiche. Metteremo in discussione le basi stesse di questi elementi e vi faremo alcuni miti su di loro lungo la strada.
Sconfiggiamo un mito che è stato ripetuto fino alla nausea su questi elementi: l'idea che siano basati sulla ricerca su come noi, la comunità web, stavamo marcando i nostri documenti. È un mito che è stato ripetuto in libri, blog e discorsi da anni, e non è vero. Come lo so? Ho chiesto.
Quando stavo ricercando le origini di questi elementi, ho deciso di chiedere all'editor della specifica HTML5, Ian Hickson, da dove provenivano questi elementi. Lui ha risposto:
Io e altri collaboratori di WHATWG [li ho aggiunti], [in] 2004ish, perché erano elementi ovvi da aggiungere dopo aver visto come gli autori usavano HTML4. Successivamente (tra la fine del 2005 e l'inizio del 2006) abbiamo fatto delle ricerche obiettive per scoprire quali erano le dieci migliori classi HTML e abbiamo scoperto che sostanzialmente corrispondevano esattamente agli elementi che avevamo aggiunto, il che era conveniente.
Analizziamolo: in primo luogo, Hickson ei membri di WHATWG hanno aggiunto questi elementi prima di fare qualsiasi ricerca . Puoi tuffarti negli archivi della mailing list del WHATWG (per fortuna pubblico) e scoprire da solo le prime discussioni su questi elementi. Ad esempio, è possibile vedere Hickson discutere di loro nel novembre 2004, con commenti come questo :
Sì, intendo includere elementi come [elementi semantici] nelle app Web. La lavagna del mio ufficio contiene attualmente un elenco di elementi sotto la voce "ELEMENTI DI LIVELLO BLOCCO HTML5", e sto cercando di capire come farli funzionare bene (gli elementi in questione sono attualmente menzionati nella bozza, ma la bozza non gestisce bene le intestazioni) Non ho ancora visto il markup in linea, ma anche quello è sulle carte.
Cioè, sembra, come è nata la semantica strutturale HTML5: un uomo, una lavagna e alcuni input da altri membri WHATWG. (Il WHATWG, o gruppo di lavoro sulla tecnologia di applicazione di ipertesti Web, è stato formato dai rappresentanti del browser in risposta all'abbandono dell'HTML da parte del W3C per l'ideale utopico di XHTML 2.0).
Gli elementi utilizzati da milioni di documenti di cui abbiamo discusso e discusso sono stati, a quanto pare, creati arbitrariamente per un capriccio dell'editor HTML5 nel 2004. (E sono stati incontrati con un una critica astuta e alcune previsioni tristemente accurate quasi immediatamente.)
Tantek ha insistito sulla ricerca, prima di specificare i nuovi formati per lungo tempo nel contesto dei microformati, e infine le specifiche WHATWG saranno similmente progettate con dati reali, invece di tirar fuori le cose dai nostri retaggi collettivi. - Ian Hickson
Questo ci porta al secondo punto. Nel dicembre 2005, circa un anno dopo aver inventato questi nuovi elementi, Hickson (un dipendente di Google) ha effettuato alcune ricerche sul modo in cui i documenti sono stati creati utilizzando l'ampio database di documenti di Google. La ricerca era "un'analisi di un campione di poco più di un miliardo di documenti, che estraeva informazioni su nomi di classi popolari, elementi, attributi e metadati correlati". Gli ID non sono stati inclusi nella ricerca. I risultati sono stati pubblicati da Google come Web Authoring Statistics (2005) .
La parte critica della ricerca, per quanto riguarda gli elementi strutturali dell'HTML, era la risultati delle lezioni , che, nonostante l'utilizzo di un campione in cui ~ 900 milioni di 1 miliardo di documenti apparentemente non avevano classi, conteneva alcune classi comuni, sono sicuro che tutti abbiamo usato nei nostri progetti: footer, menu, titolo, piccolo, testo , contenuto, intestazione, nav, copyright, pulsante, principale e così via.
Hickson fornisce quindi i suoi dati, suggerendo che queste classi "effettivamente [mappano] molto bene agli elementi proposti in HTML5" e fornisce una tabella che confronta i risultati della ricerca e i nuovi elementi in HTML5: un footer la classe è nella ricerca, un elemento footer è in HTML5; una classe di intestazione è nella ricerca, un elemento di intestazione è in HTML5; le classi testo , contenuto , main , body sono nella ricerca, e, err ... l' articolo è in HTML5 che, come vedremo, non corrisponde affatto; la sezione non si trova affatto, il che vale anche la pena di notare.
Preso per valore nominale, questo è tutto abbastanza ragionevole. Io uso il piè di pagina, usi il piè di pagina, il piè di pagina è in HTML5. Qual è il problema?
Il problema è che se leggi l'attuale Specifica HTML5 , gli elementi in HTML5 sono definiti in un modo che ha poco a che fare con il modo in cui li abbiamo tradizionalmente usati.
Da un lato, Hickson ha introdotto un nuovo concetto di strutturazione di una pagina Web in HTML5 con elementi di sezione . Dall'altra parte, Hickson sta confrontando i suoi elementi di sezione HTML5 con le classi utilizzate in natura senza alcuna comprensione di ciò per cui queste classi sono state effettivamente utilizzate. Un classico esempio è 'header', che la maggior parte di noi userebbe per l'area nella parte superiore della pagina, ma la specifica HTML5 suggerisce di poterla usare per l' intestazione di ogni commento su una pagina . Veramente. Solo perché le classi nella ricerca e gli elementi in HTML5 hanno lo stesso nome non significa che i loro usi siano gli stessi.
Ora, se fosse stato comunicato chiaramente che i nuovi elementi sono stati introdotti con un nuovo scopo e una logica chiara, allora non sarebbe così male. Ma non è quello che ci è stato detto.
Ecco Hickson nel 2009 , rispondendo a una domanda sullo scopo della sezione, nav, article, aside e altri:
Sono, più o meno, riempiendo le richieste più comuni da parte degli sviluppatori Web sulla base dei valori di attributo class = "" più comuni. Il loro scopo principale è semplificare la creazione e lo stile.
Sfortunatamente, questo sembra essere un caso in cui l'editor HTML5, per tutto il suo buon lavoro nel tirare insieme le specifiche, ha (siamo generosi) dimenticato perché ha aggiunto questi elementi a ciò che è essenzialmente la sua specifica. Forse è la differenza di tempo tra il 2009 e il 2004, chi lo sa. Ma sappiamo questo: gli elementi di sezione HTML5 non sono stati aggiunti per colmare "le richieste più comuni da parte degli sviluppatori web". Come lo sappiamo? Possiamo solo guardare la lista e vedere gli elementi più fondamentali aggiunti, come l'elemento della sezione (e l'articolo correlato e gli elementi a parte), non compaiono nella ricerca degli attributi di classi comuni di sorta.
Sebbene Hickson possa aver dimenticato il motivo per cui questi elementi sono stati aggiunti, possiamo ancora leggere per fortuna le specifiche che documentano il loro scopo.
Ma cosa succede quando dici a web designer e sviluppatori di non preoccuparti, questi elementi sostituiscono solo quello che stai già facendo e poi specificano questi elementi in un modo che non è certamente quello che stavano facendo i web designer e gli sviluppatori? Li metti in un viaggio di sola andata verso la città della confusione.
Questo è il peggior tipo di ricerca: un'interpretazione pigra dei dati fatti per giustificare decisioni già prese. Un principio di design spesso ripetuto di HTML5 è ' spianare i cammini ', cioè' Quando una pratica è già diffusa tra gli autori, considera di adottarla piuttosto che proibirla o inventare qualcosa di nuovo. ' E così sembrerebbe con questi nuovi elementi strutturali: sezione, articolo, nav, e a parte (e intestazione e piè di pagina) - sicuramente questi sono solo 'spianando le strade di campagna'?
Questa è l'impressione che molti di noi hanno, poiché è quello che ci è stato detto che sono.
In effetti, quasi cinque anni fa, quando abbiamo ottenuto per la prima volta un anteprima di HTML5 sembrava che questi elementi potessero semplicemente sostituire i div 'insensati' che eravamo abituati ad usare. Ciò che era div id = "header" nella parte superiore della pagina ora potrebbe diventare semplicemente intestazione ; div id = "footer" potrebbe ora diventare solo il footer , e il nostro div potrebbe essere solo un articolo. Semplice, vero?
Sfortunatamente, nonostante ciò che ci è stato detto (cioè scambiandone uno per l'altro), abbiamo effettivamente implementato questi elementi in un modo che non si riflette nelle specifiche HTML5. Cioè, quando si tratta di una struttura HTML5, abbiamo essenzialmente biforcato le specifiche. Esistono attualmente due metodi di struttura HTML5 - l'interpretazione della comunità, che si riflette nell'articolo A List Apart del 2007 (e innumerevoli altri); e la specifica HTML5, che introduce un modo completamente nuovo di strutturare una pagina web chiamata outlining.
Questa è la contraddizione nel cuore della semantica strutturale dell'HTML. Da un lato abbiamo l'editore che ci dice che i nuovi elementi si basano sulla ricerca di ciò che stavamo già facendo, e quindi intendiamo semplicemente rendere l'authoring un po 'più semplice; e d'altra parte abbiamo ciò che l'editor ha effettivamente creato nella specifica HTML5, che è un nuovo modo di strutturare una pagina web in un modo che genera una struttura del documento usando elementi di sezione .
C'era una scelta chiara da fare qui. Rompere con i principi di design HTML5 e introdurre qualcosa di nuovo, o semplicemente seguire le pratiche di authoring reali e specificare gli elementi in un modo che rifletta la pratica del web design. Hickson ha provato a fare il primo e chiamarlo quest'ultimo, e ora abbiamo un grosso casino tra le mani.
Affamato di più? Seconda parte di questo articolo è ora disponibile e il libro di Luke "The Truth About HTML5" è disponibile per un periodo limitato attraverso il nostro sito gemello MightyDeals.com con uno straordinario sconto del 50%.
Lavori con elementi strutturali HTML5? Li trovi utili o un ostacolo? Fateci sapere nei commenti.
Immagine in primo piano / miniatura, usi immagine della struttura via Shutterstock.