Le balisage sémantique est-il trop ouvert? [fermé]

Question

Je suis en train de jeter un coup d'œil sur Plongez dans HTML5 . Cela semble agréable et intéressant, mais je suis perplexe.

Dans les années 1990, à l'époque où Netscape était le navigateur et HTML, HTML2 ou HTML3, il y avait beaucoup de balises: address, cite, code ... La plupart d'entre elles sont inutilisées à ce jour, probablement même obsolètes.

HTML5 introduit des balises pour exprimer " sens sémantique " à la balise elle-même. Tout cela est amusant et amusant, mais je vois quelque chose de très étrange dans cette approche. Techniquement, la sémantique peut être très ouverte. HTML5 a des balises pour article, heure, barres de navigation, pied de page. Pourquoi ne devrait-il pas contenir des balises pour l'icône de publication, le lieu, le nom et le nom de l'auteur, ou tout autre chose à laquelle vous souhaitez attribuer une sémantique spécifique (je suis convaincu que <rant> et <nsfw> seraient des balises très importantes):? Je pensais que XML était la stratégie pour assigner une sémantique à des choses. Rien ne vous interdit de placer un fragment XML sous un élément XHTML et de lui attribuer une feuille de style. donc, pour le styler correctement ou pour déléguer à l'utilisateur approprié le traitement de cet espace de noms (par exemple, lors du traitement de RSS ou SVG ).

En conclusion, je ne comprends pas la raison de cette extension axée sur la sémantique, alors qu’il est clair que la sémantique est un sujet très vaste, qui nécessitera sans doute une quantité infinie de balises sémantiques. Comme je suis presque sûr qu'il y a des gens intelligents au W3C , je pense que je me trompe, mais J'aimerais savoir pourquoi.

Answer 1

Pourquoi les balises pour l'article, l'heure, les barres de navigation et le pied de page sont-elles utiles?

Parce qu'ils facilitent l'analyse d'outils de traitement de texte tels que Google.

Il n’ya rien sur la sémantique (au moins dans le sens large). Au lieu de cela, ils se contentent de dire: voici le corps de la page (partie la plus importante du texte) et la barre de navigation contenant de nombreux liens. Avec une telle approche, vous pouvez facilement extraire ce dont vous avez besoin.

Answer 2

Moi aussi, je déteste la façon dont le W3C décrit ses spécifications. Il y a beaucoup de choses que je n'aime pas, et cette & "Sémantique &"; la mode est l'un d'entre eux. (D'autres incluent le fait de prendre pour toujours leurs spécifications et de laisser trop de détails importants que les navigateurs peuvent implémenter à leur guise.)

Surtout, je ne l’aime pas parce que cela complique davantage mon travail de développeur Web. Je dois souvent choisir entre rendre la page Web & Quot; sémantiquement correcte & Quot; ou & "Visuellement / esthétiquement plaisant &"; Ce dernier gagne bien sûr, car c’est ce que veulent les utilisateurs, mais en conséquence, les validations commencent à échouer et le tout devient plutôt non sémantique (tableaux de présentation et autres).

Un autre problème qui me déplaît est qu’ils ont officiellement déclaré que la & "classe &"; Cet attribut est destiné à la sémantique, mais ils l’ont ensuite utilisé pour les sélecteurs de présentation visuelle en CSS.

Résultat final - NE MÉLANGEZ PAS LA SÉMANTIQUE ET LA REPRÉSENTATION VISUELLE . Si vous utilisez un mécanisme pour décrire la sémantique (comme les noms de balises, les valeurs d'attributs ou quoi que ce soit d'autre), ne l'utilisez pas à des fins fonctionnelles / visuelles, et inversement.

Si je concevais du HTML, je rajouterais simplement un attribut " sémantique " qui pourrait (comme l'attribut & "class &") être ajouté à n'importe quelle balise. Ensuite, il y aurait un certain nombre de valeurs prédéfinies comme tous ces en-têtes / pieds de page / articles / citations / etc.

Les balises définiraient la fonctionnalité. En gros, vous pouvez réduire les balises HTML à une poignée, comme & "; Div &", & "Table / tr / td &", & "A &" ;, & "; img &"; & "forme &"; & "input &"; et " sélectionnez " ;. J'en ai probablement manqué quelques-uns mais c'est l'essentiel. Le style visuel serait réalisé via CSS.

De cette façon, les trois domaines - sémantique, représentation visuelle et fonctionnalité - seraient complètement indépendants et ne s’affronteraient pas dans les solutions réelles.

Bien sûr, je ne pense pas que le W3C s'intéresse aux solutions pratiques ...

Answer 3

Il existe déjà beaucoup de sémantiques dans le balisage HTML sous forme de classes et d'identifiants, pour lesquels il existe un nombre (quasi) infini de possibilités de, Et chacun a sa propre manière de gérer ces sémantiques. Un des objectifs de HTML5 est d’essayer d’apporter une structure à cela. vous pourrez toujours étendre la sémantique des balises avec des classes et des identifiants. Cela facilitera probablement les choses pour les moteurs de recherche.

Answer 4

Examinez-le sous l'angle d'essayer de faire des déclarations sur la page ou sur les objets référencés à partir de la page. Si vous voyez un & Lt; footer & Gt; balise, tout ce que vous pouvez dire est & "; ici, vous trouverez un pied de page &"; et passez le par. En tant que tel, ajouter des balises personnalisées n’est pas une solution aussi générique que d’ajouter des attributs et de permettre aux gens d’utiliser leur propre choix d’URI pour spécifier des prédicats et éventuellement des valeurs - RDFa gagne haut la main car vous pouvez exprimer n’importe quel -état que vous aimez de RDF dans une page, d'une manière ou d'une autre.

Answer 5

Je veux juste aborder une partie de votre question. Vous dites:

  

Dans les années quatre-vingt-dix, au moment où   Netscape était le navigateur et le HTML était   HTML2 ou HTML3, il y avait beaucoup de   tags: adresse, cite, code ... La plupart des   les sont inutilisés à compter d'aujourd'hui, probablement   même obsolète.

Il existe un grand nombre de balises en HTML, mais le manque d’utilisation ne signifie pas qu’elles sont obsolètes. En particulier, les balises d’en-tête <h1>, etc., et <ul>, <ol> permettent de joindre des éléments à des listes de manière sémantique. Beaucoup de gens ne peuvent pas utiliser les tags de manière sémantique, mais l’effort de création de microformats est une continuation de la idée que vous considérez comme un artefact des années 1990. Les efforts visant à faire du Web sémantique un succès continuent malgré la recherche en texte intégral et l'analyse des liens (sous la forme de Google) étant le gagnant en ce qui concerne la recherche et la compréhension du Web.

Il serait bon de voir une version mise à jour des statistiques Web de Google , qui s'affichent. & "; html comme elle est parlée. &"; Mais vous avez raison, beaucoup de tags sont sous-utilisés.

Que html5 réussisse est une question ouverte et intéressante, mais les balises que vous décrivez comme obsolètes ne vont nulle part, elles étaient là dans HTML 4.01 et xhtml . Le HTML5 semble être un effort pour consolider ce qui est utile dans les balises. En fin de compte, si HTML5 prend en charge les navigateurs et facilite le travail des développeurs Web, il réussira. xhtml2 a échoué car il n'a pas réussi à être adopté par les navigateurs et n'a rien fait pour en faire le travail des créateurs de pages Web est plus facile. Les forces qui travaillent sur html5 semblent parfaitement conscientes de l’échec de xhtml2 et je pense qu’elles éviteront que html5 ne subisse le même sort.

Answer 6

& "Pourquoi ne devrait-il pas contenir de balises pour l'icône de publication, le lieu, le nom et le nom de l'auteur, ou pour toute autre chose à laquelle vous souhaitez attribuer une sémantique spécifique (je suis confiant et qui serait très important):? "

Vous utilisez < dialogue > pour décrire des conversations ou des commentaires. Rant et NSFW sont des termes subjectifs, il est donc logique de ne pas les utiliser.

D'après ce que j'ai compris, de nombreux développeurs Web expérimentés ont effectué des recherches et recherché ce que la plupart des sites Web ont en commun en html. Ils ont remarqué que la plupart des sites Web avaient id = & "; Entête &"; Id = & "Pied de page &"; Id = & "Section &"; et id = " nav " donc ils ont décidé que nous avions besoin de balises HTML pour remplacer ces identifiants. Donc, en d'autres termes, ne vous attendez pas à ce qu'ils vous donnent une énorme quantité de vocabulaire HTML. Restez aussi simple que possible en adressant les balises HTML nécessaires les plus courantes.

La balise NAV est TRÈS importante pour l’accessibilité. Vous voulez qu'ils sachent où se trouve la navigation plutôt que de les forcer à rechercher si les liens sont destinés à la navigation ou non.

Answer 7

Je ne suis pas d'accord avec l'ajout de balises supplémentaires. Si le vocabulaire détaillé était réellement importé, il pourrait y avoir un nom de balise différent pour chaque mot du dictionnaire. Les noms de balises supplémentaires ne sont pas utiles car ils peuvent communiquer une signification supplémentaire aux humains, mais ne font rien pour faciliter l'analyse syntaxique du langage par la machine. C'est pourquoi je n'aime pas les & "Sémantiques &"; balises pour HTML5, car j'estime qu'il s'agit d'une pente glissante pour fournir un vocabulaire trop complexe tout en fournissant une solution faible à un problème qui n'a pas été entièrement résolu.

À mon avis, les données relatives à la structure du langage de balisage sont aussi importantes que celles décrites dans un diagramme en arborescence. Grâce à l'analyse de la structure et à l'utilisation appropriée des conventions sémantiques, telles que RDFa, le contexte peut être exploité pour fournir une signification spécifique à des noms de balises par ailleurs génériques. Dans de tels cas, un vocabulaire excessif n’est plus nécessaire et les noms d’étiquette structurellement redondants, tels que pied de page et côté, peuvent être éliminés. L'objectif final est de rendre le contenu plus rapide et plus précis à interpréter simultanément par les humains et les machines, tout en utilisant le moins de code possible pour obtenir ce résultat. En quoi cette solution est moins importante, sauf en HTML5.

Answer 8

  

Je pensais que XML était la stratégie pour attribuer une sémantique à des éléments.

Pour autant que je sache, non, ce n'était pas & # 8217; t. XML permet de définir de nouveaux langages, tous analysés de la même manière, car ils utilisent tous la syntaxe XML.

Cela ne & # 8217; t, en soi, ne fournit aucun moyen d'ajouter du sens (& # 8220; sémantique & # 8221; signifie simplement & # 8220; significatif & # 8221 ;) à ces langues. Et jusqu'à ce que les ordinateurs acquièrent une intelligence artificielle, ils & # 8217; t ne comprennent pas le sens, alors le sens est exactement ce qui est convenu entre des êtres humains. Le langage HTML est le langage le plus couramment utilisé, avec la signification convenue de ses balises.

Le HTML étant si courant, il est & # 8217; utile d’ajouter quelques balises significatives qui sont assez générales dans leur application. Les nouvelles balises HTML5 visent à cela. Les auteurs de la spécification HTML5 & # 8217; pourraient en effet continuer sur cette voie en créant des balises pour chaque bit de sens spécifique possible, mais comme ils & # 8217; ne sont pas des robots, ils ont probablement gagné & # 8217 ; t.

<section> est utile et suffisamment général pour pouvoir s'appliquer de manière significative à de nombreux documents. <author-last-name> isn & # 8217; t. Distinguer les deux est un jugement, c’est pourquoi les humains, et non les ordinateurs, écrivent la spécification.

Pour les sémantiques personnalisées trop spécifiques pour être ajoutées à HTML en tant que balises, HTML5 définit les microdonnées .

Answer 9

Je lisais le livre d’Andy Clark Transcending CSS (page 33).

..., il est maintenant largement admis que les noms de présentation tels que en-tête , à gauche ou en rouge , qui décrivent l'aspect ou la position d'un élément sont de mauvais choix.

Après avoir lu ces lignes, je me suis demandé: hé, n'y a-t-il pas d'éléments dans les spécifications HTML5 tels que l'en-tête, le pied de page? Pourquoi le pied de page est-il plus sémantique? Dans son livre, Andy préconise l’utilisation de informations de site pour l’ID du pied de page div, ce qui est plus logique à mon humble avis. Le pied de page est un nom de présentation (décrit la position de l'élément).

Answer 10

En un mot, AJAX. Les nouvelles balises sont conçues pour aider les développeurs du monde réel en remplaçant certains des <div class="sidebar-wrap"><div class="styling-hook"><div><ul class="nav"> types de divitis dont souffrent de nombreux sites Web. Le seul <div> restant dans le HTML5 est le crochet de style.

Les sémantiques promues en balises de classes sont celles que les développeurs ont librement adoptées en masse comme meilleures pratiques, compte tenu d'une période d'adoption xhtml / css étendue. Consultez l'édition du développeur WHATWG de la page des sections de la spécification ici . Le document lui-même est un plaisir, mais je ne le gâcherai pas si vous ne l'avez pas encore vu.

L’importance de Webkit est l’une des raisons moins évidentes de certaines décisions prises par le W3C. Si vous regardez, vous pouvez voir qu'ils ont été mieux que certains à prendre les travaux actuels du groupe de travail HTML5 et à mettre en œuvre des idées. Ils ont toujours été en avance sur leur conformité ( voir ici ). Le W3C accorde une grande priorité à leurs applications (Android, iPhone, Googlebot, Chrome, Safari, Dreamweaver, etc.). Google, utilisateurs du framework, Wordpress / Moveable Type / Joomla! les utilisateurs de type et les autres voulaient des blocs de construction autonomes, c'est donc le style que nous obtenons.

Facebook est modulaire. Les grilles de conception sensible sont modulaires. Wordpress est modulaire. Ajax fonctionne mieux avec des structures de page modulaires. Les widgets sont des modules. Les plug-ins sont des modules. Il semblerait que nous devrions essayer de trouver des solutions telles que la manière d’appliquer ces balises pour faciliter l’accrochage des éléments appropriés et leur activation dans notre Web 2.0 hybride document / application / réseau info.

En conclusion, HTML5 est destiné à être écrit au format XML (voir la spécification à nouveau) afin de garantir que les outils et les machines effectuant des demandes ajax pour une partie d'un document obtiendront une réponse utile bien formée. C'est génial de le combiner avec des choses telles que les requêtes multimédia pour des périphériques tels que les lecteurs de flux, les imprimantes braille, les annotateurs, etc. Je vois un futur (proche) où tout ce qui a un bon contenu sémantique est son propre flux de nouvelles automatiquement! Cela ne se produit que si les développeurs adoptent et écrivent des documents conformes.