Perché uno dovrebbe preoccuparsi di marcare correttamente e semanticamente?

Funzionalità gratuite

Utilizzare correttamente <label> s significa che è possibile fare clic sull'etichetta per inserire il campo di testo. Molti browser aggiungeranno funzionalità logiche predefinite a molti tag secondo le specifiche ufficiali, il che significa che è possibile utilizzare meno plug-in JavaScript e scrivere meno codice rispetto a un sito interamente composto da <div> s e <span> s.

Accessibilità

In relazione alla funzionalità gratuita, semantica significa molto per il software di screen reader. Il testo davanti a un campo di input non verrà letto nello stesso modo di un <label> . I lettori di schermate ignoreranno la maggior parte dei tuoi CSS, quindi dipende principalmente dalla struttura del tuo HTML.

CSS logico

Perché usare un div #header quando puoi usare un <header> e lo stile direttamente? I tag semantici rendono più facile marcare le cose e rendere il tuo stile molto più portabile; se hai un certo stile per strikeout e usi sempre <del> elementi lo stile è molto più portabile. <del> significa la stessa cosa per tutti, ma ognuno nominerà la propria classe .deletedText in modo diverso.

Aiuta anche a mantenere tutti sulla stessa pagina in progetti di grandi dimensioni; a nessuno piace imparare le convenzioni di denominazione di classe esoterica di altre persone.

SEO

I motori di ricerca come Google hanno fatto un maggiore uso di HTML semantico e metadati . I Rich Snippet di Google utilizzano anche metadati speciali pensati per trasmettere contenuti semantici.

Perché non è tutto così comune

Ci vuole lavoro, e le persone sono abituate a giudicare un sito web da come guarda e lavora . Spesso non si tiene conto della semantica perché chi scrive la business case per le app non lo capisce o perché è importante.

È molto difficile per le persone non tecniche comprendere o valutare la semantica HTML.

Se un sito web sembra buono e sembra funzionare, perché preoccuparsi? Molte persone potrebbero anche non sapere che è qualcosa di più. Simile all'accessibilità, questo tende ad essere ignorato fino a quando qualcuno del tuo team lo capisce davvero.

Se vuoi che l'HTML semantico sia una priorità del tuo progetto, tu devi presentare il caso. Anche mostrare al tuo team / capo come funziona il tuo sito web in uno screen reader è uno strumento utile.

La risposta è semplicemente per trasmettere informazioni e per strutturare il tuo documento .

Quando usi span e div, il documento non ha una struttura. Non ci sono liste, senza paragrafi, senza tabelle, senza collegamenti ipertestuali. Niente. Non ha davvero senso scegliere HTML come linguaggio di markup e quindi ignorare il vocabolario che offre per esprimere e strutturare il contenuto. La struttura è la parola importante qui btw. HTML è per la strutturazione che non viene visualizzata. Ecco a cosa serve CSS.

Se marcisci semanticamente il tuo codice, dai ai lettori umani e alle macchine la possibilità di comprendere i dati all'interno dei tuoi elementi. Se utilizzi gli elementi span e div fino in fondo, non avrai queste informazioni extra e non sarà possibile dedurli dai soli valori.

Allo stesso modo, se voglio raschiare i siti web e solo estrarre i titoli per creare il sommario per loro, il mio ragno dovrebbe sapere qual è il titolo. Non può farlo senza gli elementi appropriati.

Ultimo ma non meno importante, se si utilizzano solo le div e span, si avrà difficoltà a progettarle con i CSS. I selettori CSS funzionano sulla struttura del tuo documento e, se questa è per lo più una struttura ambigua, le regole CSS non riescono ad applicarsi. Come decidi se div div div si riferisce effettivamente a table tr td o body ul li ? Dovresti aggiungere classi e id allora, ma poi stai reinventando la ruota.

Vedi anche la raccomandazione del W3C

Using the appropriate semantic elements will make sure the structure is available to the user agent. This involves explicitly indicating the role that different units have in understanding the meaning of the content. The nature of a piece of content as a paragraph, header, emphasized text, table, etc. can all be indicated in this way. In some cases, the relationships between units of content should also be indicated, such as between headings and subheadings, or amongst the cells of a table. The user agent can then make the structure perceivable to the user, for example using a different visual presentation for different types of structures or by using a different voice or pitch in an auditory presentation.

Per aggiungere alle già buone risposte qui, una cosa che non ho visto menzionato è la compatibilità diretta . Man mano che la specifica evolve, è possibile specificare funzionalità aggiuntive per determinati elementi semantici. Se il tuo codice è semanticamente corretto, sarà in grado di sfruttare questa funzionalità senza manutenzione minima o minima.

Un motivo per cui non vedi molti siti che seguono perfettamente la semantica è che non c'è un business case per la maggior parte del tempo. Se spinge le vendite (o una categoria correlata come l'esposizione), allora vale la pena spendere per scrivere HTML semantico.

Il miglior caso che posso fare per l'uso semantico dei tag è quando consumi o usi l'HTML con uno strumento. Ad esempio, l'utilizzo di tag semantici consente di creare direttamente gli elementi senza temere l'aggiunta o la rimozione di stili da qualcos'altro. Inoltre, se dovessi analizzare l'HTML usando un raschietto o qualcosa di simile, apprezzerai sicuramente HTML ben formato e semantico, poiché diventa più facile scrivere query XPath e DOM per trovare quello che ti serve.

Devo notare che le classi non sono una sostituzione diretta per i tag semantici. Ho classi riutilizzabili [error, information, warning] che trasmettono significati diversi e quindi stili basati sul tag a cui sono associati.

Perché può essere utile o necessario per crawler e servizi Web (computer AKA che comunicano con computer). Se scrivi:

<span class="time">Sep 16 at 2:17</span>

... il web crawler non sarà necessario capirlo come una data, una roba del tempo. O sarà molto più difficile individuarlo come informazione sulla data.

Se si utilizza:

 <time datetime="2012-02-11 16:24:02">feb 11 2012 at 16:24:02</time>

... sarà molto più facile per qualsiasi crawler trovare e analizzare il materiale.

Quando dico crawler, non intendo necessariamente i motori di ricerca:)

Gestisco una piccola società di consulenza web e il nostro attuale approccio è di non utilizzare i nuovi tag HTML5 perché stiamo cercando di bilanciare molti fattori. In questo caso, il saldo è tra usabilità, usabilità e SEO:

• SEO: quali altre risposte hanno detto - potrebbe aiutare un po 'il SEO, anche se sulla base della mia esperienza più ovvia è una strategia SEO, meno è probabile che sia di aiuto.

• Usabilità n. 1: è ragionevole presumere che i tag HTML5 conferiscano una sorta di vantaggio di usabilità. Per gli utenti non vedenti è certo che qualunque sia il ripiego che il browser accessibile fornisce loro sarà meglio di qualsiasi cosa potrò fornire. Per il tuo utente tipico è molto più discutibile. Forse l'utilizzo di un lettore multimediale non scolorito fornito dal browser è più semplice da utilizzare rispetto al widget meno familiare che altrimenti avrei messo lì. O forse l'impostazione predefinita del browser è crap (come il modo in cui il lettore MP3 predefinito di Chrome Windows smette di funzionare periodicamente).

• Usabilità n. 2: Old IE. Old IE richiede un certo numero di shim HTML5 che gonfiano la pagina in modo che uno di questi tag funzioni. Devi aggiungere qualche script ai tag head che chiama CreateElement () in un ciclo su tutti i tag HTML5 che stai utilizzando. Se non hai intenzione di andare in giro a pettinare ogni pagina per i tag che hai in uso, significa che ogni tag HTML5. Questo deve essere eseguito su ogni singola pagina, in linea, ovvero senza memorizzazione nella cache. E cattive notizie: la vecchia IE è la più lenta ad eseguire Javascript, quindi crea un piccolo barlume mentre si carica. Poi devi far parte di un gruppo di vecchi Javascript e CSS di IE, e spesso di Flash, per rendere correttamente tutti gli elementi più recenti non supportati. Puoi eseguire il rilevamento delle funzioni prima di decidere di caricare il vecchio codice IE, ma poi stai facendo in modo che i vecchi utenti di IE attenderanno fino a quando non saranno caricati abbastanza script per eseguire il rilevamento delle funzionalità prima ancora di richiedere tutti gli elementi che fanno funzionare quei tag. È possibile che il browser rilevi e invii solo i vecchi file IE agli utenti con tali browser, ma ciò può rendere difficile o impossibile la memorizzazione nella cache a seconda della piattaforma. Fornire codice diverso a utenti diversi significa anche che il test è più complicato - mai un bug di asincronia? Che ne dici di uno che si verifica solo su un browser specifico? E solo in produzione? Iscrivimi. Quindi, probabilmente manderai tutto il problema a tutti.

Fino alla morte di IE8, il valore di questi tag HTML5 più recenti non è abbastanza alto per i problemi di prestazioni che portano. Dobbiamo ancora lavorare con un pubblico in cui è quasi morto *, ma un giorno.

* Le nostre metriche più recenti mostrano IE8 al 6% per il sito con il minor numero di visitatori di IE8 e il 24% con il maggior numero di visitatori di IE8. Lontano, tutt'altro che morto.

La risposta breve è "Nessuna buona ragione nella pratica". Quasi tutti gli argomenti dati a favore del markup "semantico" sono solo pensieri su cosa potrebbe o dovrebbe accadere, piuttosto che qualcosa di tangibile. Ad esempio, spesso si fa riferimento ai motori di ricerca, ma non vi è alcuna prova pubblica del fatto che si preoccupino meno di time o output o address .

Indirettamente, possiamo dedurre che non gli interesseranno nel prossimo futuro. Il sito schema.org , di alcuni dei principali motori di ricerca, favorisce chiaramente un approccio specifico al "markup semantico" basato su qualcosa di completamente diverso, vale a dire microdati ( itemscope e attributi correlati). E in realtà lo fanno principalmente per grandi siti commerciali o di comunità.

L'utilizzo di span o div funziona più bene delle novità HTML5, in quanto questi ultimi non sono riconosciuti dalle vecchie versioni di IE anche ai fini dello stile. Quindi hai bisogno di trucchi per renderli "funzionanti" anche come elementi del contenitore.

Tuttavia, ci sono alcuni elementi "semantici" che hanno un significato reale assegnato loro da browser, software di assistenza o motori di ricerca. L'utilizzo di h1 per l'intestazione principale è sempre stato una buona pratica per tali motivi. L'utilizzo di label per le etichette dei campi modulo ha un impatto reale sull'usabilità e l'accessibilità. E così via; vedi La guida pragmatica all'HTML: principi .

L'HTML non è solo un linguaggio di interfaccia utente, è anche un linguaggio di strutturazione dei dati. È stato progettato per aiutare le macchine eterogenee ad avere un modo comune per identificare il tipo di informazioni in arrivo per il server. Quindi tanti tag diversi. Le pagine HTML dovrebbero essere considerate come strutture di dati.