Perché preoccuparsi di segnare correttamente e semanticamente?

_{Nota che (cerco) di segnare il più semanticamente possibile perché mi piace il loro aspetto e aspetto, ma non perché sono consapevole di altri straordinari vantaggi. Il punto della mia domanda è di essere in grado di educare gli altri}

Bene, ho visto molti articoli ed esercitazioni che affermano spesso "Facciamo questo nel modo più semantico possibile".

Ma uno strano pensiero mi è venuto in mente, perché?

Perché uno dovrebbe (o vorrebbe) preoccuparsi degli elementi specifici che trasmettono il significato semantico corretto? In particolare, mi riferisco ai nuovi elementi HTML5, come ad esempio <time>, <output>o <address>. Soprattutto, se la pagina "funziona" (si visualizza bene in tutti i browser).

Perché dovrei usare elementi come <time>o <address>, dove niente (o nel peggiore dei casi, un generico <span>) funziona altrettanto bene?

Lo sto chiedendo perché sto vedendo una moltitudine di siti Web (molto popolari) (incluso questo) che non seguono queste cosiddette migliori pratiche.

Funzionalità gratuita

L'uso corretto di <label>s significa che è possibile fare clic sull'etichetta per inserire il campo di testo. Molti browser aggiungeranno funzionalità logiche predefinite a molti tag in base alle specifiche ufficiali, il che significa che è possibile utilizzare un minor numero di plug-in JavaScript e scrivere meno codice rispetto a un sito interamente realizzato con <div>s e <span>s.

Accessibilità

Relativamente alla funzionalità gratuita, la semantica significa molto per il software di lettura dello schermo. Il testo davanti a un campo di input non verrà letto esattamente come una <label>volontà. Gli screen reader ignoreranno la maggior parte dei CSS, quindi dipende principalmente dalla struttura del codice HTML.

CSS logico

Perché usare a div #headerquando puoi usare a <header>e lo stile direttamente? I tag semantici semplificano il markup delle cose e rendono il tuo stile molto più portatile; se hai un certo stile per strikeout e usi sempre <del>elementi lo stile è molto più portatile. <del>significa la stessa cosa per tutti, ma ognuno nominerà la propria .deletedTextclasse in modo diverso.

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

SEO

I motori di ricerca come Google hanno fatto un uso crescente di HTML e metadati semantici . I rich snippet di Google usano anche metadati speciali pensati per trasmettere contenuti semantici.

Perché non è così comune

Ci vuole lavoro e le persone sono abituate a giudicare un sito Web da come appare e funziona . Spesso non si tiene conto della semantica perché le persone che scrivono il business case per le app non lo capiscono o perché sono importanti.

È 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 non possono nemmeno che ci sia qualcosa di più ad esso. Simile all'accessibilità, questo tende a essere ignorato fino a quando qualcuno nella tua squadra lo capisce davvero.

Se desideri che l'HTML semantico sia una priorità per il tuo progetto, 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 a ciò è semplicemente quella di trasmettere informazioni e strutturare il tuo documento .

Quando si utilizzano span e div, il documento non ha una struttura. Non ci sono elenchi, né paragrafi, né tabelle, né collegamenti ipertestuali. Niente. Non ha davvero senso scegliere HTML come linguaggio di markup e quindi ignorare il vocabolario che offre per esprimere e strutturare i tuoi contenuti. La struttura è la parola importante qui tra noi. HTML è per strutturare non visualizzare. Ecco a cosa serve CSS.

Se esegui il markup semantico del codice, dai ai lettori umani e alle macchine la possibilità di comprendere i dati all'interno dei tuoi elementi. Se si utilizzano gli elementi span e div fino in fondo, non si avranno queste informazioni aggiuntive e dedurle dai soli valori potrebbe non essere possibile.

Allo stesso modo, se voglio raschiare siti Web ed estrarre solo le intestazioni per creare il Sommario per loro, il mio ragno dovrebbe sapere qual è l'intestazione. Non può farlo senza gli elementi appropriati.

Ultimo ma non meno importante, se usi solo div e span, avrai difficoltà a disegnarli con CSS. I selettori CSS funzionano sulla struttura del tuo documento e se questa è per lo più struttura ambigua, le regole CSS ottengono iffy da applicare. Come decidi se fare div div divveramente riferimento table tr tdo body ul li? Allora dovresti aggiungere classi e ID, ma poi stai reinventando la ruota.

Vedi anche le raccomandazioni del W3C

L'uso degli elementi semantici appropriati assicurerà che la struttura sia disponibile per l'agente utente. Ciò implica indicare esplicitamente il ruolo che le diverse unità hanno nella comprensione del significato del contenuto. La natura di un contenuto come paragrafo, intestazione, testo sottolineato, tabella, ecc. Può essere indicata in questo modo. In alcuni casi, dovrebbero essere indicati anche i rapporti tra unità di contenuto, ad esempio tra intestazioni e sottotitoli o tra le celle di una tabella. L'agente utente può quindi rendere la struttura percepibile all'utente, ad esempio utilizzando una presentazione visiva diversa per diversi tipi di strutture o utilizzando una voce o un tono diversi in una presentazione uditiva.

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

Uno dei motivi per cui non vedi molti siti che seguono perfettamente la semantica è che non c'è un caso aziendale per questo il più delle volte. Se favorisce le vendite (o una categoria correlata come l'esposizione), vale la pena spendere i loro soldi per scrivere HTML semantico.

Il caso migliore che posso fare per l'uso semantico dei tag è quando stai consumando o usando HTML con uno strumento. Ad esempio, l'uso di tag semantici ti consente di modellare direttamente gli elementi senza paura di aggiungere o rimuovere stili da qualcos'altro. Inoltre, se dovessi mai analizzare l'HTML usando uno scraper o qualcosa del genere, apprezzeresti sicuramente l'HTML ben formato e semantico in quanto diventa più facile scrivere query XPath e DOM per trovare quello che ti serve.

Devo notare che le classi non sostituiscono direttamente i tag semantici. Ho delle 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 i computer). Se scrivi:

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

... il web crawler non sarà necessario capirlo come una data, una roba da tempo. Oppure sarà molto più difficile individuarlo come data.

Se usi:

 <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 le cose.

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

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

• SEO: Ciò che altre risposte hanno detto qui - potrebbe aiutare un po 'per il SEO, anche se in base alla mia esperienza più una strategia SEO è ovvia, meno è probabile che sia di aiuto.

• Usabilità n. 1: è ragionevole supporre che i tag HTML5 conferiscano una sorta di vantaggio di usabilità. Per gli utenti non vedenti è certo che qualunque sia il fallback fornito dal loro browser accessibile sarà migliore di qualsiasi cosa io possa fornire. Per il tuo tipico utente è molto più discutibile. Forse usando un lettore multimediale non ancorato fornito dal tuo browser è più facile da usare rispetto al widget meno familiare che altrimenti metterei lì. O forse il default del tuo browser è schifo (come il modo in cui il lettore MP3 predefinito di Chrome Windows smette di funzionare periodicamente).

• Usabilità n. 2: IE precedente. Il vecchio IE richiede un sacco di spessori HTML5 che gonfiano la pagina affinché uno di questi tag funzioni. Devi aggiungere alcuni script ai tag head che chiamano CreateElement () in un ciclo attraverso 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, ciò significa ogni tag HTML5. Questo deve essere eseguito su ogni singola pagina, in linea, il che significa che non c'è cache. E cattive notizie: il vecchio IE è il più lento ad eseguire Javascript, quindi crea un piccolo barlume mentre si carica. Quindi devi creare una serie di vecchi Javascript e CSS solo IE, e spesso Flash, per rendere correttamente tutti gli elementi non supportati più recenti. Puoi rilevare le funzionalità prima di decidere di caricare il vecchio codice IE, ma poi " per far sì che gli utenti di IE precedenti attendano fino a quando non sono stati caricati abbastanza script per eseguire tale rilevamento prima ancora di iniziare a richiedere tutto ciò che fa funzionare quei tag. È possibile rilevare il browser e inviare agli utenti solo i vecchi contenuti di IE con tali browser, ma ciò può rendere la memorizzazione nella cache difficile o impossibile a seconda della piattaforma. Fornire codice diverso a utenti diversi significa anche che i test sono più complicati: hai mai avuto un bug asincrono? Che ne dite di uno che si verifica solo su un browser specifico? E solo in produzione? Iscrivimi. Quindi, probabilmente manderai quel gonfiore a tutti. Fornire codice diverso a utenti diversi significa anche che i test sono più complicati: hai mai avuto un bug asincrono? Che ne dite di uno che si verifica solo su un browser specifico? E solo in produzione? Iscrivimi. Quindi, probabilmente manderai quel gonfiore a tutti. Fornire codice diverso a utenti diversi significa anche che i test sono più complicati: hai mai avuto un bug asincrono? Che ne dite di uno che si verifica solo su un browser specifico? E solo in produzione? Iscrivimi. Quindi, probabilmente manderai quel gonfiore a tutti.

Fino alla morte di IE8, il valore di questi nuovi tag HTML5 non è abbastanza alto per i problemi di prestazioni che portano. Dobbiamo ancora lavorare con un pubblico in cui è persino vicino ai morti *, ma un giorno.

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

La risposta breve è "Nessuna buona ragione in pratica". Quasi tutti gli argomenti forniti a favore del markup "semantico" sono solo pensieri di ciò che potrebbe o dovrebbe accadere, piuttosto che qualcosa di tangibile. Ad esempio, i motori di ricerca sono spesso citati, ma non ci sono prove pubbliche del fatto che si preoccupino meno di timeo outputo address.

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

Utilizzare spano divfunziona in modo più gradevole rispetto alle novità HTML5, poiché queste ultime non sono riconosciute dalle vecchie versioni di IE nemmeno ai fini dello stile. Quindi hai bisogno di qualche trucco per farli "funzionare" anche come elementi contenitore.

Tuttavia, ci sono alcuni elementi "semantici" che hanno un significato reale assegnato loro da browser, software assistivo o motori di ricerca. L'uso h1per l'intestazione principale è sempre stata una buona pratica per tali motivi. L'uso labeldelle etichette dei campi modulo ha un impatto reale sull'usabilità e l'accessibilità. E così via; vedi La guida pragmatica a HTML: Principi .

HTML non è solo un linguaggio dell'interfaccia utente, è anche un linguaggio di strutturazione dei dati. È stato progettato per aiutare le macchine eterogenee a disporre di un modo comune per identificare il tipo di informazioni provenienti dal server. Da qui tanti tag diversi. Le pagine HTML dovrebbero essere considerate come strutture di dati.