In la prima parte di questa serie abbiamo coperto i difetti che portano agli elementi strutturali di HTML5, in questa seconda parte esamineremo in dettaglio le conseguenze di tali carenze.
Ho detto più volte che HTML5 introduce un nuovo metodo per strutturare una pagina web e probabilmente ti starai chiedendo cosa sia effettivamente. È proprio lì nelle specifiche, quali introduce il concetto di 'sezionamento del contenuto ': il contenuto della sezione è contenuto che definisce l'ambito di intestazioni e piè di pagina. Ogni elemento di contenuto della sezione ha potenzialmente un'intestazione e una struttura.
Le specifiche documentano il suo approccio a intestazioni, sezioni e contorni per rendere il concetto chiaro. Bene, chiaro a chi deve implementare la funzionalità nei browser. Per comprendere gli elementi strutturali dell'HTML (sezione, articolo, nav, a parte e i relativi elementi di intestazione e piè di pagina correlati) e questo concetto oscuro di "sectioning content" o "outlining", dobbiamo fare un piccolo viaggio nella cronologia HTML.
Il concetto di presentazione introdotto in HTML5 può essere fatto risalire fino al 1991 ed è stato incluso nella sfortunata caratteristica XHTML 2.0 senza fine e finalmente vede la luce in HTML5 ... solo per essere così scarsamente comunicati che l'idea è praticamente morto all'arrivo.
Prima di HTML5, la struttura gerarchica di una pagina era determinata dagli elementi di titolo: i nostri vecchi amici da h1 a h6. Potremmo strutturare una pagina dicendo che il titolo della pagina è h1, l'intestazione dell'articolo potrebbe essere h2 e forse i sottotitoli nell'articolo potrebbero essere h3 e h4 e così via.
Questo va bene per un documento semplice, ma l'utilizzo di tag di intestazione per creare una gerarchia logica, o 'outline di documento', per una pagina Web complessa e moderna è molto difficile. Parte del problema è la mancanza di un modo per determinare dove inizia e si ferma una sezione della pagina. Ad esempio, diciamo che avevamo il nostro documento menzionato in precedenza con h1 per il titolo della pagina, h2 per il titolo dell'articolo, h3 per i sottotitoli, ma poi volevamo segnare il titolo per le nostre sezioni della barra laterale con intestazioni h3.
Il documento delineato da una struttura simile sarebbe simile a questo:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Qui, gli elementi h3 sono "posseduti" dall'h2 sopra di loro, anche se non ha molto senso. Ovviamente, dovremmo suddividerli con qualcosa come div per l'articolo e div per la barra laterale, ma questi vengono ignorati dagli interpreti (come gli screen reader) che determinano il contorno della pagina solo dalla struttura di titolo.
Legando direttamente la gerarchia delle pagine a quelli che sono spesso i livelli di intestazione della presentazione, siamo limitati nel modo in cui possiamo strutturare una pagina.
Nel tentativo di risolvere questo problema, HTML5 introduce il concetto di 'elementi di sezione', cioè elementi speciali che dividono la pagina in sezioni - hai indovinato - e quelle sezioni determinano il livello di annidamento delle intestazioni e, in effetti, la gerarchia o "contorno" della pagina.
Cioè, la gerarchia della pagina è disgiunta dagli elementi di titolo, e invece questi nuovi elementi di sezione determinano quale livello è effettivamente un elemento di intestazione.
Nella prima bozza Specifiche XHTML 2.0 , la sezione ha funzionato con un elemento di sezione e un elemento generico di intestazione h. Quando scriviamo HTML, non dovremmo specificare il livello di intestazione che volevamo utilizzare, dovremmo semplicemente consentire al browser di determinare il livello di nidificazione per una determinata intestazione. Potremmo annidare elementi di sezione 99 livelli profondi, e un elemento h al 99 ° livello sarebbe equivalente a un elemento h99. In questo modo, possiamo strutturare i nostri documenti logicamente, senza preoccuparci di come possiamo usare gli elementi limitati di h1-h6.
(Questa idea in realtà risale al 1991, tra l'altro: come Jeremy Keith ha sottolineato, Tim Berners-Lee ha mooted l'idea di una sezione e h elemento per strutturare una pagina alla fine di questa email dell'ottobre 1991 .)
Hickson ha tentato di introdurre questo stesso concetto in HTML5, ma con un ulteriore grado di difficoltà: voleva mantenere la retrocompatibilità e introdurre alcune nuove semantiche per "semplificare la creazione" all'avvio. Pertanto, invece di avere solo un elemento di sezione in HTML5, abbiamo anche un articolo, nav e un elemento a parte che fanno tutti la stessa cosa della sezione, ma con nomi diversi, da utilizzare in modi diversi.
Cosa dicono le specifiche di questi elementi? Ti incoraggio a leggi le specifiche per te stesso , ma ecco un assaggio:
L'elemento di sezione è il fondamento della sezione per creare una struttura del documento.
L'elemento section rappresenta una sezione generica di un documento o un'applicazione. Una sezione, in questo contesto, è un raggruppamento tematico di contenuti, in genere con un titolo.
Esempi di sezioni sono i capitoli, le varie pagine a schede in una finestra di dialogo a schede o le sezioni numerate di una tesi. La home page di un sito Web potrebbe essere suddivisa in sezioni per un'introduzione, notizie e informazioni di contatto.
Una nota nella specifica dice che l'elemento non dovrebbe essere usato per scopi puramente stilistici - un div sarebbe meglio lì, e comprensibilmente così, come le sezioni gettate in willy-nilly per lo styling creerebbero un contorno del documento molto rotto.
La nota continua dicendo "Una regola generale è che l'elemento della sezione è appropriato solo se il contenuto dell'elemento viene elencato esplicitamente nella struttura del documento" e questa è l'affermazione più chiara sull'elemento della sezione nella specifica.
Quando comprendiamo il concetto di sezionamento e delineamento, l'inclusione dell'elemento di sezione ha senso. Non appariva nella ricerca sui valori di classe comuni, ma appariva in XHTML 2.0 e risaliva concettualmente al 1991.
Gli altri elementi strutturali che HTML5 introduce - quelli che si supponeva riflettessero nella ricerca - fanno esattamente la stessa cosa dell'elemento di sezione, per quanto riguarda il profilo del documento. Creano anche la gerarchia della pagina e quindi il contorno del documento.
Prendi l'elemento dell'articolo per esempio. Molte persone pensano che sia semplicemente per articoli come questo. Ma non è affatto così. È "articolo" nel senso di "un articolo di abbigliamento". È meglio pensarlo come "oggetto" come in "un capo d'abbigliamento", poiché la sua definizione è così ampia.
Quando gli elementi dell'articolo sono nidificati, gli elementi dell'articolo interno rappresentano articoli che sono in linea di principio correlati al contenuto dell'articolo esterno. Ad esempio, un post di blog su un sito che accetta commenti inviati dall'utente potrebbe rappresentare i commenti come elementi di articolo nidificati all'interno dell'elemento articolo per il post di blog.
In HTML5, i commenti degli utenti, l'articolo corretto, i post sui forum e persino i "widget e gadget interattivi" sono tutti articoli. La definizione è così ampia da essere inutile: la semantica dovrebbe dare un senso, ma usare un termine collettivo per una così ampia varietà di elementi rende l'elemento privo di significato.
Questo è un esempio in cui abbiamo biforcato le specifiche: alcune persone seguono correttamente le specifiche e rendono quasi tutto un articolo (riepiloghi di post di blog, post di blog, commenti, widget, post di forum, ecc.), Mentre altri lo hanno tenuto solo per l'articolo principale su una pagina, che è solo una parte della sua ampia definizione. Potresti pensare che non abbia importanza in entrambi i casi, e in larga misura avresti ragione. Ma pensa a tutti quei servizi di lettura che mirano solo ad analizzare il contenuto principale della pagina. Quale implementazione delle specifiche dovrebbero seguire? Dovrebbero seguire ciò che dicono le specifiche, o dovrebbero seguire l'implementazione della comunità generale dove di solito c'è solo un "articolo" canonico su una pagina?
Questa è un'opportunità mancata, e cosa succede quando la specifica non riesce a specificare , e l'editore e, per essere onesti, la comunità, non riesce a comunicare ciò che le specifiche effettivamente dicono.
Immagina se l'articolo non fosse usato anche per i commenti. Immagina se i commenti avessero il loro elemento, ad esempio, e l'adozione diventasse molto diffusa. I creatori di browser potrebbero aggiungere una funzione di 'commenti muti' che potrebbe facilmente nascondere (o altrimenti analizzare) i commenti sulle pagine web. Ma Hickson ha specificamente rifiutato una richiesta per un elemento di commento . In HTML5, gli articoli arrivano fino in fondo.
A parte questo, c'è un altro elemento che non appare da nessuna parte nella ricerca sul nome di classe di Hickson e ottiene una definizione molto particolare da avviare:
L'elemento aside rappresenta una sezione di una pagina che consiste in contenuti che sono correlati in modo tangenziale al contenuto attorno all'elemento aside e che potrebbero essere considerati separati da tale contenuto. Tali sezioni sono spesso rappresentate come barre laterali nella tipografia stampata.
L'elemento può essere utilizzato per effetti tipografici come virgolette o barre laterali, per la pubblicità, per gruppi di elementi nav e per altri contenuti che sono considerati separati dal contenuto principale della pagina.
Chissà perché a parte coprire le virgolette, le barre laterali, la pubblicità e i gruppi di elementi di navigazione, ma crea anche nuove sezioni nella struttura del documento. Ciò significa che le virgolette pull ottengono il loro punto elenco nel profilo del documento, che sembra, diciamo, "strano". Ancora una volta, il suo utilizzo casuale da parte di progettisti di siti Web ben intenzionati ha creato e creerà numerosi profili di documenti rotti.
L'elemento nav sembra il più autoesplicativo degli elementi di sezione, e per fortuna la definizione non è stata allungata oltre la rottura.
L'elemento nav rappresenta una sezione di una pagina che collega ad altre pagine o a parti all'interno della pagina: una sezione con collegamenti di navigazione.
Il che va bene, e potrebbe avere vantaggi di accessibilità teorici (un agente utente potrebbe saltare oltre, o saltare a, i collegamenti nav - non lo fanno, ma potrebbero farlo).
Il problema è che nello spirito di 'semplificazione della creazione' e sostituzione di div con l'elemento di navigazione, facciamo esplodere lo stile di navigazione per un altro sottoinsieme di utenti. Utenti di IE6-8 con JavaScript disattivato (La ricerca di Yahoo suggerisce L'1-2% di tutti gli utenti ha JavaScript disattivato ) sono vittime di questo problema. Con JavaScript disattivato, lo shim HTML5 basato su JavaScript che aiuta IE6-8 a comprendere gli elementi HTML5 non funziona, quindi il browser non ha lo stile di elementi HTML5. Questo può interessare solo un numero limitato di utenti, ma perché li riguarda?
Gli elementi di intestazione e piè di pagina sono un classico caso di prendere termini comuni e dare loro usi molto diversi.
La specifica afferma che nessuno di questi elementi crea nuove sezioni nella struttura del documento, nonostante siano spesso raffigurati come alla pari con sezione, nav, articolo e parte. In realtà, non fanno nulla. Sono solo inclusi per delimitare le aree di una sezione specifica nella struttura del documento.
Ecco cosa dice la specifica sull'intestazione: l'elemento di intestazione rappresenta un gruppo di aiuti introduttivi o di navigazione.
Nota: un intestazione contiene solitamente l'intestazione della sezione (un elemento h1-h6 o un elemento hgroup), ma questo non è richiesto. L'elemento di intestazione può anche essere utilizzato per avvolgere il sommario di una sezione, un modulo di ricerca o qualsiasi logo pertinente.
e piè di pagina: l'elemento footer rappresenta un piè di pagina per il suo contenuto di sezioni antenato più prossimo o per l'elemento radice di sezionamento. In genere un footer contiene informazioni sulla sua sezione, ad esempio chi lo ha scritto, collegamenti a documenti correlati, dati sul copyright e simili.
In HTML5, l'elemento body è in realtà l'elemento della sezione radice, quindi un'intestazione e un piè di pagina generali intendono descrivere la sezione del corpo radice. Qualsiasi sezione può avere un'intestazione e / o un piè di pagina: non sono pensati solo per le intestazioni e i piè di pagina complessivi, come si può presumere. Ad esempio, i singoli commenti possono avere un'intestazione e un piè di pagina. Infatti, come abbiamo accennato in precedenza, la specifica fornisce effettivamente un esempio di footer utilizzato in un commento sopra il contenuto del commento effettivo. Proprio così, nei commenti HTML5 ci sono articoli, e possono avere un piè di pagina per un'intestazione, e questo è nelle specifiche effettive. Volevi un elemento footer per l'intestazione dei tuoi commenti? No? Bene, ce l'hai.
Anche in questo caso, HTML5 accetta termini comuni e li utilizza in modi che non sono riconoscibili per l'autore web comune.
Ma c'è qualcosa che non abbiamo visto nell'implementazione HTML del sectioning. L'hai notato? Abbiamo gli elementi di sezione, ma non abbiamo un elemento h generico. Non preoccuparti, la soluzione è nello spec :
Le sezioni possono contenere intestazioni di qualsiasi livello, ma gli autori sono vivamente incoraggiati a utilizzare solo elementi h1 o a utilizzare elementi della classificazione appropriata per il livello di nidificazione della sezione.
HTML5 vuole essere retrocompatibile, quindi WHATWG ha deciso di non introdurre un elemento h (nonostante l'introduzione di una serie di nuovi elementi di sezione), e invece di riutilizzare l'elemento h1 per essere l'elemento h generico. Usa h1 ovunque e lascia che l'algoritmo delineato in HTML5 determini il suo vero livello ... o così la teoria va.
Questa è una pessima idea per diversi motivi, i due principali sono l'accessibilità e lo styling.
Usare h1 ovunque è molto brutto per l'accessibilità. Gli utenti non vedenti fanno molto affidamento sulla struttura delle intestazioni di un sito. È importante ricordare a tutti noi quanto sia cruciale la struttura delle intestazioni ai fini dell'accessibilità. Ad esempio, un dicembre Indagine del 2008 su oltre 1000 utenti di screen reader condotto da WebAIM ha rilevato che il 76% degli utenti non vedenti e ipovedenti "sempre o spesso" navigava per titoli quando erano disponibili. E un sondaggio del maggio 2012 ha rilevato che i livelli di intestazione dell'82,1% erano "molto utili" o "in qualche modo utili" durante la navigazione di una pagina web. (Questa è una buona ricerca pratica, quindi prendi nota).
Avere h1s ovunque renderà i siti più difficili da navigare per gli utenti non vedenti. In teoria, i lettori di schermo userebbero invece l'algoritmo di delineamento HTML e navigano usando il contorno del documento, ma dato il modo in cui gli autori hanno detto di implementare elementi di sezione, delineando è un casino e tentando di navigare nei contorni di documenti a cui non è stato dato alcun pensiero essere ancora peggio per gli utenti non vedenti.
Le specifiche HTML5 offrono una via d'uscita: continua a utilizzare i livelli h1-h6 appropriati per mantenere la compatibilità con le versioni precedenti. Ma ora stiamo mantenendo due linee di documento in un documento, e visti i problemi che gli autori hanno avuto anche nel considerare la struttura del documento in primo luogo, la probabilità che qualcuno mantenga sia una struttura logica h1-h6, sia una logica, correttamente Il profilo HTML5 a sezioni sembra remoto, nella migliore delle ipotesi.
Ma peggiora. Diciamo che vogliamo correre con un profilo HTML5 puro, e usiamo h1 ovunque. Ricorda, nelle specifiche HTML5, h1 è solo un generico elemento h; il suo livello reale è determinato da quanto profondamente è annidato negli elementi di sezionamento.
Quindi come lo modelliamo? Bene, potremmo aggiungere nomi di classe a tutti i nostri elementi h1 in modo che possiamo individuarli, ma questo è contrario all'obiettivo dichiarato di HTML5 di semplificare la creazione; e possiamo anche attenerci a h1-h6 (che sono tutti trattati come elementi h generici in una struttura HTML5).
Potremmo provare a modellarli attraverso la cascata, ma questo diventa rapidamente assurdo, come Nicole Sullivan ha sottolineato . In realtà, "assurdo" inizia solo a descriverlo. Quando consideri le possibili combinazioni di sezione, articolo, nav e a parte e vuoi creare uno stile generico per un'intestazione che è, ad esempio, cinque livelli profondi (cioè l'equivalente di h5), devi scrivere stili per tutti combinazioni possibili, che ottiene assolutamente ridicolo . Ecco lo stile generico per un elemento h3:
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;}Eppure questo è ciò che gli elementi strutturali dell'HTML ci danno. Che casino.
Affamato di più? Terza 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%.
Usi gli elementi dell'articolo più volte in un documento? Le sezioni sono utili o dovremmo attenerci alle div? Fateci sapere che ne pensate nei commenti.
Immagine in primo piano / miniatura, usi immagine della struttura via Shutterstock.