Il markup semantico è troppo aperto? [chiuso]

Question

Sto dando un'occhiata a Dive Into HTML5 . Sembra carino e interessante, ma sono perplesso.

Negli anni '90, al tempo in cui Netscape era il browser e HTML era HTML2 o HTML3, c'erano molti tag: indirizzo, citazione, codice ... La maggior parte di essi non è utilizzata da oggi, probabilmente persino obsoleta.

HTML5 introduce tag per esprimere " significato semantico " al tag stesso. Questo è tutto divertimento e giochi, ma vedo qualcosa di molto strano in questo approccio. Tecnicamente, la semantica può essere molto aperta. HTML5 ha tag per articolo, ora, barre di navigazione, piè di pagina. Perché non dovrebbe contenere tag per l'icona del post, la posizione dell'autore, il nome e il cognome o qualsiasi altra cosa a cui si desidera assegnare una semantica specifica (sono sicuro che <rant> e <nsfw> sarebbero tag molto importanti):? Pensavo che XML fosse la strategia per assegnare la semantica alle cose. Nulla ti impedisce di inserire un blocco XML sotto un elemento div XHTML e di assegnargli un foglio di stile in modo da modellarlo correttamente o delegare al visualizzatore appropriato la gestione di quello spazio dei nomi (ad esempio, quando si gestisce RSS o SVG ).

In conclusione, non capisco il motivo dietro queste estensioni focalizzate sulla semantica, quando è chiaro che la semantica è un argomento molto ampio, che è garantito per richiedere una quantità potenzialmente infinita di tag semantici. Dato che sono abbastanza sicuro che ci siano persone intelligenti su W3C , penso di sbagliarmi, ma Mi piacerebbe sapere perché.

Answer 1

Perché sono utili i tag per articolo, ora, barre di navigazione, piè di pagina?

Perché facilitano l'analisi per strumenti di elaborazione del testo come Google.

Non si tratta di semantica (almeno nel significato 'ampio'). Invece dicono solo: qui c'è il corpo della pagina (la parte più importante del testo) e c'è la barra di navigazione piena di collegamenti. Con un tale approccio puoi facilmente estrarre ciò di cui hai bisogno.

Answer 2

Anch'io odio il modo in cui il W3C sta seguendo le loro specifiche. Ci sono molte cose che non mi piacciono e questa & Quot; semantica & Quot; la moda è una di queste. (Altri includono impiegare un'eternità per completare le specifiche e lasciare troppi dettagli importanti che i browser possono implementare a loro scelta)

Soprattutto non mi piace perché rende più difficile il mio lavoro di sviluppatore web. Spesso devo fare una scelta se rendere la pagina web & Quot; semanticamente corretta & Quot; oppure " " visivamente / esteticamente gradevole ;. Quest'ultimo vince ovviamente, perché è quello che vogliono gli utenti, ma di conseguenza le validazioni iniziano a fallire e il tutto diventa abbastanza non semantico (tabelle per layout e altre cose).

Un altro problema a cui aggrotto le sopracciglia è che hanno dichiarato ufficialmente che " class " l'attributo è per la semantica, ma poi lo hanno usato per i selettori di presentazioni visive nei CSS.

In conclusione - NON MISCELARE SEMANTICA E RAPPRESENTAZIONE VISIVA . Se usi un meccanismo per descrivere la semantica (come nomi di tag, valori di attributo o cos'altro), non utilizzarlo per scopi funzionali / visivi e viceversa.

Se dovessi progettare HTML, aggiungerei semplicemente un attributo " semantico " che potrebbe (come l'attributo " class ") essere aggiunto a qualsiasi tag. Quindi ci sarebbero una serie di valori predefiniti come tutte quelle intestazioni / piè di pagina / articoli / virgolette / ecc.

I tag definiscono la funzionalità. Fondamentalmente potresti ridurre i tag HTML a una manciata, come & Quot; div & Quot ;, & Quot; table / tr / td & Quot ;, & Quot; a & Quot ;, " img " ;, " form " ;, " input " e " selezionare " ;. Probabilmente ne ho perse alcune, ma questa è la maggior parte. Lo stile visivo verrebbe realizzato tramite CSS.

In questo modo le tre aree - semantica, rappresentazione visiva e funzionalità - sarebbero completamente indipendenti e non si scontrerebbero con soluzioni di vita reale.

Naturalmente, non credo che il W3C sia interessato a soluzioni pratiche ...

Answer 3

Esiste già molta semantica nel markup HTML nelle forme di classi e ID, di cui esiste una quantità (quasi) infinita di possibilità di, e ognuno ha il proprio modo di gestire queste semantiche. Uno degli obiettivi di HTML5 è provare a portare una struttura a questo. sarai ancora in grado di estendere la semantica dei tag con classi e ID. Molto probabilmente renderà le cose più facili per i motori di ricerca.

Answer 4

Osservalo dal punto di vista del tentativo di fare dichiarazioni sulla pagina o sugli oggetti a cui fa riferimento la pagina. Se vedi un & Lt; footer & Gt; tag, tutto quello che puoi dire è " roba qui è un piè di pagina " e passalo vicino. Pertanto, l'aggiunta di tag personalizzati non è una soluzione generica come l'aggiunta di attributi e consente alle persone di utilizzare la propria scelta di URI per specificare predicati e valori facoltativi: RDFa vince a mani basse perché puoi esprimere qualsiasi triplo -statement che ti piace da RDF in una pagina, in un modo o nell'altro.

Answer 5

Voglio solo rispondere a una parte della tua domanda. Dici:

  

Negli anni novanta, nel momento in cui   Netscape era il browser e html lo era   HTML2 o HTML3, ce n'erano molti   tag: indirizzo, citazione, codice ... La maggior parte di   sono inutilizzati da oggi, probabilmente   persino obsoleto.

Ci sono molti tag tra cui scegliere in HTML, ma la mancanza di utilizzo non implica che siano obsoleti. In particolare i tag di intestazione <h1>, ecc. E <ul>, <ol> vengono utilizzati per unire gli elementi agli elenchi in un modo che considero semantico. Molte persone potrebbero non utilizzare i tag semanticamente, ma lo sforzo di creare microformati è una continuazione continua del idea di considerare un manufatto degli anni '90. Gli sforzi per rendere web semantico continuano ad essere vincenti, nonostante la ricerca full-text e l'analisi dei collegamenti (sotto forma di Google) essendo il vincitore per quanto riguarda come trovare e comprendere il web.

Sarebbe bello vedere una versione aggiornata di Statistiche web di Google che mostra " html mentre è parlata. " Ma hai ragione sul fatto che molti tag sono sottoutilizzati.

Se html5 avrà successo è una domanda aperta e interessante, ma i tag che descrivi come obsoleti non sono andati da nessuna parte, erano lì in HTML 4.01 e xhtml . HTML5 sembra essere uno sforzo per consolidare ciò che è utile nei tag. Alla fine se html5 ottiene supporto nei browser e semplifica il lavoro degli sviluppatori Web, ci riuscirà. xhtml2 non è riuscito perché non è riuscito a ottenere l'adozione nei browser e non ha fatto nulla per rendere il lavoro dei creatori di pagine Web è più semplice. Le forze che lavorano su html5 sembrano profondamente consapevoli del fallimento di xhtml2, e penso che stiano evitando di far subire un destino simile a html5.

Answer 6

" Perché non dovrebbe contenere tag per l'icona del post, la posizione dell'autore, il nome e il cognome o qualsiasi altra cosa a cui si desideri assegnare una semantica specifica (sono sicuro e sarebbero tag molto importanti):? quot &;

Usi < dialog > per descrivere conversazioni o commenti. Rant e NSFW sono termini soggettivi, quindi ha senso non usarli.

Da quello che ho capito, un gruppo di sviluppatori web esperti ha fatto ricerche e cercato ciò che la maggior parte dei siti Web ha in comune in HTML. Hanno notato che la maggior parte dei websitse ha id = & Quot; header & Quot ;, id = & Quot; footer & Quot ;, id = & Quot; sezione & Quot; e id = " nav " tag così hanno deciso che abbiamo bisogno di tag HTML per sostituire quelli ID. Quindi, in altre parole, non aspettarti che ti diano una ENORME quantità di vocabolario HTML. Mantienilo il più semplice possibile mentre affronti i tag HTML necessari PIÙ comuni.

Il tag NAV è MOLTO importante per fornire accessibilità. Volete che sappiano dove si trova la navigazione piuttosto che costringerli a scoprire se i collegamenti sono per la navigazione o meno.

Answer 7

Non sono d'accordo con l'aggiunta di tag extra. Se il vocabolario dettagliato fosse effettivamente importato, potrebbe esserci un nome tag diverso per ogni parola nel dizionario. I nomi di tag aggiuntivi non sono utili in quanto possono comunicare un significato aggiuntivo agli umani, ma non fanno nulla per facilitare l'analisi automatica della lingua. Questo è il motivo per cui non mi piace il & Quot; semantico & Quot; tag per HTML5, poiché ritengo che ciò costituisca una pendenza sdrucciolevole per fornire un vocabolario troppo complesso, fornendo al contempo una soluzione debole a un problema non completamente affrontato.

A mio avviso, i dati della struttura del linguaggio di markup sono tanto quanto descrivili in un diagramma ad albero. Attraverso l'analisi della struttura e l'uso corretto delle convenzioni semantiche, come RDFa, il contesto può essere sfruttato per fornire un significato specifico a nomi di tag altrimenti generici. In tal caso non è necessario che esista un vocabolario eccessivo e che i nomi di tag strutturalmente ridondanti, come piè di pagina e parte, possano essere eliminati. L'obiettivo finale è quello di rendere i contenuti più veloci e accurati da interpretare sia dagli umani che dalle macchine contemporaneamente, utilizzando il minor codice possibile per ottenere quel risultato. In che modo tale soluzione è meno importante, ad eccezione di HTML5.

Answer 8

  

Pensavo che XML fosse la strategia per assegnare la semantica alle cose.

Per quanto ne so, no, non era & # 8217; t. XML consente di definire nuovi linguaggi che vengono analizzati tutti allo stesso modo, poiché utilizzano tutti la sintassi XML.

Non & # 8217; t, di per sé, fornisce alcun modo per aggiungere significato (& # 8220; semantico & # 8221; significa solo & # 8220; significativo & # 8221 ;) in quelle lingue. E fino a quando i computer non ottengono l'intelligenza artificiale, in realtà non capiscono il significato, quindi il significato è proprio ciò che è concordato tra gli esseri umani. HTML è il linguaggio più comunemente usato con il significato concordato dei suoi tag.

Poiché l'HTML è così comune, & # 8217; è utile aggiungere ad esso alcuni tag significativi che sono abbastanza generali nella loro applicazione. I nuovi tag HTML5 sono mirati a questo. Gli autori delle specifiche HTML5 & # 8217; potrebbero effettivamente continuare su questa strada, creando tag per ogni specifico significato possibile, ma poiché & # 8217; non sono robot, probabilmente hanno vinto & # 8217 ;. t

<section> è utile e abbastanza generale da essere significativamente applicabile in molti documenti. <author-last-name> isn & # 8217; t. Distinguere tra i due è un appello al giudizio, motivo per cui gli umani, e non i computer, scrivono le specifiche.

Per la semantica personalizzata troppo specifica per essere aggiunta all'HTML come tag, HTML5 definisce microdata .

Answer 9

Ho letto il libro di Andy Clark Transcending CSS (pagina 33).

..., è ormai ampiamente accettato che nomi di presentazione come intestazione , a sinistra o rosso che descrivono l'aspetto o la posizione di un elemento sono scelte sbagliate.

Dopo aver letto queste righe mi sono chiesto: ehi, non ci sono elementi nelle specifiche HTML5 come header, footer ?? Perché il piè di pagina è più semantico? Andy nel suo libro sostiene di usare site-info per l'ID del div footer e questo ha più senso IMHO. Il piè di pagina è un nome di presentazione (descrive la posizione dell'elemento).

Answer 10

In una parola, AJAX. I nuovi tag hanno lo scopo di supportare ciò che gli sviluppatori del mondo reale stanno facendo sostituendo alcuni il <div class="sidebar-wrap"><div class="styling-hook"><div><ul class="nav"> tipo di divite di cui soffrono molti siti Web. L'unico <div> rimasto in HTML5 è il gancio di stile.

La semantica che viene promossa in tag dalle classi è quella che gli sviluppatori hanno adottato liberamente in massa come best practice, dato un lungo periodo di adozione di xhtml / css. Controlla l'edizione per sviluppatori WHATWG della pagina delle sezioni delle specifiche qui . Il documento stesso è un piacere, ma non lo rovinerò se non lo hai ancora visto.

Una delle ragioni meno ovvie per alcune decisioni prese dal W3C è l'importanza di Webkit. Se guardi, puoi vedere che erano migliori di alcuni nel prendere l'attuale lavoro del gruppo di lavoro HTML5 e nell'implementare idee. Storicamente sono stati molto avanti nella conformità ( vedi qui ). Il W3C ha dato la massima priorità al proprio (ad es. Android, iPhone, Googlebot, Chrome, Safari, Dreamweaver, ecc.). Google, utenti del framework, Wordpress / Tipo mobile / Joomla! utenti di tipo e altri volevano blocchi autonomi, quindi questo è lo stile che otteniamo.

Facebook è modulare. Le griglie di responsive design sono modulari. Wordpress è modulare. Ajax funziona al meglio con strutture di pagina modulari. I widget sono moduli. I plug-in sono moduli. Sembrerebbe che dovremmo cercare di capire cose come come applicare questi tag per rendere più semplice agganciare gli elementi appropriati e attivarli nel nostro documento / applicazione / rete di informazioni ibrida Web 2.0.

In chiusura, HTML5 deve essere scritto come xml (di nuovo, vedi le specifiche) al fine di garantire che gli strumenti e le macchine che fanno richieste Ajax per una parte di un documento ottengano una risposta utile ben formata. Fantastico in combinazione con cose come query multimediali per dispositivi come lettori di feed, stampanti braille, annotatori, ecc.,. Vedo un (prossimo) futuro in cui qualsiasi cosa con un buon contenuto semantico è il suo newsfeed automagicamente! Ciò accade solo se gli sviluppatori adottano e scrivono documenti conformi.