5568 sujets

Sémantique web et HTML

[Résolu] Balises personnalisées en HTML5

Pages :
Bonjour
Je recherche un tutoriel sur les balises personnalisées en HTML5.

Tout ce que j'ai trouvé jusqu'à présent semble dire que ces balises doivent être déclarées dynamiquement avant emploi, ce qui signifie en gros qu'on ne peut les utiliser que pour des pages générées dynamiquement en JavaScript.

Je constate néanmoins que les deux pages http://jeanpierre.moularde.free.fr/test/custom-tags-1.html et http://jeanpierre.moularde.free.fr/test/custom-tags-2.html donnent le même résultat, du moins sur FireFox, dès l'instant qu'on a correctement stylé toutes les balises.
En d'autre termes, tout se passe comme si le fait de définir ces balises dans l'en-tête de la page suffisait à faire en sorte que FF les reconnaisse.

SI c'est effectivement le cas et que ça fonctionne également avec les autres navigateurs, ne serait-ce pas un moyen efficace d'améliorer la lisibilité -- et donc la maintenabilité -- de nos pages?

Edit: ça marche également sous IE, Chrome et Safari sur PC et iPad
Modifié par PapyJP (25 Feb 2015 - 13:11)
SolidSnake a écrit :
Bonjour.

Ce lien là à l'air sympa : http://www.html5rocks.com/en/tutorials/webcomponents/customelements

Après j'ai une question de fond existentielle, peut-on encore vraiment appeler ça de l'HTML5 ?

Oui, c'est le premier document que j'ai vu sur le sujet. Un peu difficile de savoir où il veut en venir, car il commence par expliquer comment les créer dynamiquement en JS.

A propos de HTML5:

J'ai participé au "réseau de la recherche" en tant que directeur de plusieurs projets européens de recherche en informatique, et plus précisément à des projets mettant en œuvre le SGML.C'était au tout début des années 1990, au moment où le HTML est apparu (équipe du CERN)

L'objectif du HTML était de permettre facilement l'échange de documents de nature scientifique. Les inventeurs ont réduit les balises à ce qu'on trouvait dans un article scientifique, d'où des trucs qui ne servent plus guère pour faciliter les références bibliographiques. Comme les utilisateurs étaient intéressés à taper du texte au km, sans s'intéresser aux détails de la présentation, les balises contiennent un style de présentation implicite, dont les grandes interlignes qui précèdent les balises <ul> et <ol> sont un exemple.

Lorsque le réseau est devenu public et s'est intéressé à d'autres sujets que les communications scientifiques, les modifications se sont faites de façon Darwinienne. Le résultat actuel est que nous avons toujours des tas de balises dites plus ou moins "sémantiques" (et je j'appellerais plutôt des balises de mise en page) que nous devons corriger enrichir, voire contredire au moyen de fichiers ou sections CSS.

Les balises personnalisées, c'est une façon de passer à des balises vraiment "sémantiques" et de distinguer complètement la structure du document de la présentation.

Actuellement, j'écris très peu de HTML: j'ai des données de type objet, représentées par des classes PHP, et chaque classe génère le HTML nécessaire à son affichage.
Au lieu de générer du HTML, je devrais pouvoir insérer une structure balisée représentant les objets et en faire faire la présentation par chaque page où l'objet intervient en jouant sur le CSS.
Très ponctuellement, quand on n'a pas exactement ce qu'on veut avec ce qui existe, je ne dis pas, ça pourrait être une très bonne chose. ON pourrait voir apparaître des balises intéressantes et utiles qui auraient pu échapper au W3C.


Mais plus concrètement, ça risque d'être rapidement le bordel si chacun réinvente le HTML à sa façon, notamment en ce qui concerne l'accessibilité, la recherche et l'extraction de données.


IL n'y a qu'à voir: le balisage PDF intègre une possibilité de nommer les tags comme on veut et de fournir des mappings de rôles. Du coup tous ceux qui sont capables d'exporter en PDF balisé font un peu leurs variantes (déjà que quasiment personne n'exporte en PDF balisé), et au final ça n'apporte rien de plus en accessibilité ou en sémantique; bien au contraire, ça complique inutilement les choses.

En HTML, je suis sûr que la plupart des concepteurs moyens ne connaissent pas ou ne comprennent rien à ARIA; dans la mesure où pour des balises personnalisés il faudrait indiquer les rôles explicitement à chaque fois pour que ce soit accessible, c'est autant d'ereurs, d'imprécisions et d'oublis en perspective.

Tiens d'ailleurs, pour un lecteur d'écran, les deux pages d'exemple donnés en premier post ne sont PAS identiques. Avec la version div, chaque élément de l'adresse est bien sur des lignes séparées; avec la version balises perso, tout est sur une seule ligne, à la suite et tout collé.


Donc définitivement non, à éviter absolument!
Modifié par QuentinC (25 Feb 2015 - 22:03)
QuentinC a écrit :
Tiens d'ailleurs, pour un lecteur d'écran, les deux pages d'exemple donnés en premier post ne sont PAS identiques. Avec la version div, chaque élément de l'adresse est bien sur des lignes séparées; avec la version balises perso, tout est sur une seule ligne, à la suite et tout collé

Voilà une info intéressante. Dans les essais que j'ai faits ce matin les deux pages sont identiques â chaque fois. Avec quel(s) navigateurs/version(s) obtiens tu ce résultat?

 remarquer évidemment que cette approche consiste à définir TOUTE la présentation en CSS, ce qui est contraire aux usages en vigueur, et ce pour les raisons "historiques" que j'ai expliquées plus haut.
Après tout, quand on met des nouvelles balises <header>, <nav>, <footer>, <article>, on est dans la même situation. Par ailleurs le mélange de balises HTML et des attributs dits "syntaxiques" permet de dire "ce bout de texte qui se trouve dans un <li> représente te code postal de l'adresse de l'entreprise de l'auteur de cet article" est il plus clair?

Il est intéressant de constater qu'il aura fallu 20 ans pour que le modèle "à la mode" permette de revenir à ce qu'il aurait fallu faire dès le début bien que personne ou presque n'en parle jamais. Une petite équipe pond en quelques semaines un modèle utile pour ce qu'elle fait, sans plus, et ça devient une bible pour 20 ans....
Celà dit, je ne sais pas si me vais moi même sauter le pas, mais j'ai tout de même l'intention de creuser ce point plus avant. J'y ai pensé hier soir au détour d'une conversation sur ce site, ça m'a rappelé des choses, J'ai commencé à investigué ce matin... Il faut laisser un peu reposer avant de prendre des décisions.

Quant aux autres remarques sur le chamboulement que l'utilisation des balises personnalisées apporterait, on me faisait exactement les mêmes dans les années 1970 quand j'ai promu la programmation structurée dans mes équipes ou dans les années 1990 quand j'ai fait de même avec la programmation objet. Ces deux points sont maintenant d'usage courant. D'une certaine manière, les balises personnalisées sont une extension de l'approche objet.

 suivre...
Modifié par PapyJP (25 Feb 2015 - 23:25)
PapyJP a écrit :
Le résultat actuel est que nous avons toujours des tas de balises dites plus ou moins "sémantiques" (et je j'appellerais plutôt des balises de mise en page) que nous devons corriger enrichir, voire contredire au moyen de fichiers ou sections CSS.

Les balises personnalisées, c'est une façon de passer à des balises vraiment "sémantiques" et de distinguer complètement la structure du document de la présentation.

Le but de ces balises sémantiques est de pouvoir être compris par tout le monde, et de pouvoir découper ton site le plus simplement et rapidement possible, c'est un langage universel, avec les mêmes règles pour tout le monde, en bref une norme. Après le fait que l'on doit redéfinir le style de ces balises, vient probablement du fait que si tous les navigateurs actuelles abandonnaient du jour au lendemain leur style par défaut, une bonne majorité des sites de par le monde ce casseraient méchamment.

Mais bon perso, je préfère quand même utiliser une simple classe sur une "vieille" <div>, plutôt que de m'embêter à définir une nouvelle balise juste pour le plaisir. La lecture et la compréhension pour moi et les autres seront, je pense, identique. Dans le cas inverse, un étranger à mon code ne pourra être que perdu, et en fin de compte je ne parlerai pas aux autres, mais qu'à moi, c'est le sentiment que j'ai.

Et j'avais une autre question, est-ce que notre dieu à tous (malgré nous) Google apprécie ces balises ? (Évidemment pour les sites que l'on souhaite référencer)

EDIT : après, rien ne t'empêche de définir ta propre DTD, et comme on dit "En avant Guingamp" !
Modifié par SolidSnake (26 Feb 2015 - 08:20)
a écrit :
Voilà une info intéressante. Dans les essais que j'ai faits ce matin les deux pages sont identiques â chaque fois. Avec quel(s) navigateurs/version(s) obtiens tu ce résultat?

 
 
Tous.
 
 
C'est peut-être identique visuellement parce qu'en CSS tu fais ce que tu veux, mais pas sémantiquement, et par conséquent mon lecteur d'écran ne comprend rien; par défaut il met tout à la suite.
 
Comme je l'ai déjà dit, tu pourrais corriger ce problème en indiquant systématiquement un rôle ARIA pour chacune de tes balises perso. Mais c'est généralement mauvais comme approche: source d'erreurs et d'oublis, pas maintenable. Par principe, il ne faut spécifier le rôle ARIA et en général n'utiliser ARIA que quand on ne peut pas faire autrement plus simple; il faut au maximum profiter de la sémantique et des rôles implicites, et donc utiliser autant que possible les standards existants.
 
 
 
a écrit :
 remarquer évidemment que cette approche consiste à définir TOUTE la présentation en CSS, ce qui est contraire aux usages en vigueur, et ce pour les raisons "historiques" que j'ai expliquées plus haut.

 
Et ce n'est pas pour rien que c'est contraire aux usages. Ce que tu fais, en fait, ça revient au même que XML+XSL+XSLT, ce que certains navigateurs permettent (ou en tout cas permettaient). En bref, du XML non structuré, où chaque document a sa sémantique propre.
 
Pour prendre une image, ce serait un peu comme si chacun inventait des mots. Au final plus personne ne parle vraiment français et plus personne ne se comprend, en-dehors du cercle dans lequel tu as défini les mots que tu as inventé. C'est pour que tout le monde puisse se comprendre que l'académie française a inventé le dictionnaire et a (au moins initialement) écrit les définitions des mots à utiliser.
 
Que tu fasses ta cuisine interne pour échanger des fichiers dans ton entreprise/institution/organisation/cercle d'amis, ça ne nous regarde pas, et tant mieux parce que c'est bien pratique; le XML non structuré ou structuré à l'aide d'un schéma spécifique est un moyen d'échange très utilisé aujourd'hui.
 
Par contre, quand on veut diffuser un message au monde entier, on a intérêt à parler tous la même langue.
 
Si tu veux que ton truc avec des balises perso marche et soit compris par tous, tu dois, pour reprendre l'image, fournir le dictionnaire avec ton contenu. Au final, en tant que lecteur du message, qu'Est-ce que j'y gagne ? rien, sinon une difficulté supplémentaire à fournir pour que je puisse comprendre le message, et avec cela, automatiquement, une chance de plus pour que je le comprenne mal. Si ton but est de m'embrouiller, soit; mais ce n'est sûrement pas ce que tu veux.
 
 
a écrit :
Après tout, quand on met des nouvelles balises <header>, <nav>, <footer>, <article>, on est dans la même situation.

 
Sauf que ces balises-là ont été normées. IL y a eu un flou au début où on recommandait de ne pas trop les utiliser parce qu'elles étaient mal comprises, mais maintenant le flou s'estompe et on n'a plus beaucoup de risques de les utiliser. La même chose que quand un nouveau mot est ajouté dans le dictionnaire. Là où ma métaphore s'arrête, c'est que dans le cas de la langue française, c'est plutôt l'évolution des usages par les locuteurs qui remplissent le dictionnaire, tandis qu'en informatique c'est plutôt l'organisme de normalisation qui se réunit et qui décide ce qui pourrait être intéressant d'ajouter/supprimer/modifier. Note l'inversion.
 
a écrit :
Par ailleurs le mélange de balises HTML et des attributs dits "syntaxiques" permet de dire "ce bout de texte qui se trouve dans un <li> représente te code postal de l'adresse de l'entreprise de l'auteur de cet article" est il plus clair?

/quote]

Oui et non. Si tu penses à l'attribut class, pour toi en tant que rédacteur/éditeur du contenu ça a un sens supplémentaire, mais pour moi en tant que lecteur non. Pourquoi ? parce que les noms de classe ne sont pas standardisés.

Par contre si tu penses à itemprop & Co. alors là, oui, du moins en théorie. En pratique non parce que les lecteurs d'écran ne font pas usage de ces attributs; mais ça a du sens pour d'autres, p.ex. Google, et ça pourra peut-être avoir un sens pour moi aussi si un jour le logiciel de restitution que j'utilise les prend en compte.

a écrit :
Quant aux autres remarques sur le chamboulement que l'utilisation des balises personnalisées apporterait, on me faisait exactement les mêmes dans les années 1970 quand j'ai promu la programmation structurée dans mes équipes ou dans les années 1990 quand j'ai fait de même avec la programmation objet. Ces deux points sont maintenant d'usage courant. D'une certaine manière, les balises personnalisées sont une extension de l'approche objet.


Sauf que la programmation orientée objet est seulement une façon parmi d'autres de concevoir une application, et en tant que simple utilisateur de ton application je m'en fiche royalement; c'est ta cuisine interne, ça ne te regarde que toi et ton équipee de développeurs.
Tout comme je me contrefiche de savoir si tu as utilisé un stylo ou un crayon de papier. Ca ne fait pas réellement partie du message à diffuser, du moins pas directement et pour celui qui n'est pas en mesure de faire la distinction entre les deux.
Bonjour Quentin.
Merci de ta réponse qui alimente la réflexion que j'ai démarrée avant hier soir sur ces fameuses balises personnalisées.

Si je comprends bien, le "lecteur d'écran" est un navigateur dont la sortie est vocale? Si les balises personnalisées venaient à devenir populaires, je gage que ce navigateur évoluerait et se mettrait â les supporter

Pour le reste je ne comprends pas les remarques sur la nécessité d'avoir des balises standardisées. Ce sont les navigateurs qui lisent et interprètent ces balises, pas les utilisateurs. Quand ton lecteur d'écran lit la version "div" de ma page de test, il ne dit pas que ce sont des <div>, je suppose qu'il est fait de telle sorte qu'il reconnaît lesquelles sont en display:block; et lesquelles en display:inline-block; Il suffirait de peu de chose pour qu'il reconnaisse des balises personnalisées.

Dans les premières versions du HTML il suffisait de regarder les balises pour savoir comment ça allait s'afficher sur l'écran. On choisissait les balises en fonction du rendu désiré. Maintenant on est obligé de regarder dans le CSS et de faire la correspondance, mais il semble que tout le mode soit d'accord pour considérer la séparation entre structure de page et présentation comme un plus.
La lecture par un être humain d'une page comprenant des
<div class="first-name"> ou des <x-first-name> est une affaire d'habitude. Dans les deux cas il faut se référer au CSS associé pou savoir comment ça se présente a l'écran. Si les auteurs de pages mettent des noms de balises (actuellement les noms de classes) significatifs on non fait toute la différence.

Comme tu l'as bien compris, je travaille à partir de fichiers XML qui sont pour moi la représentation la plus efficace et lisible des objets. J'ai utilisé le XSLT il y a une petite dizaine d'années pour générer du HTML à partir de XML. Je n'avais â l'époque pas accès à un langage sur le serveur de mon entreprise qui ne permettait que de stocker des fichiers. C'est un mécanisme peu pratique, un langage de programmation descriptif et non dynamique, que j'ai remplacé dès que j'ai pu par des programmes en PHP. (Je m'attends â des protestations de la part des sectateurs de XSLT, mais ils ont l'air detre peu nombreux sur ce forum!).

En pratique, comme je l'ai dit, j'écris peu de HTML directement, je le fais générer par du PHP, et que ça génère <div class="first-name"> ou <x-first-name> a peu d'importance pratique, de toute façon la présentation est faite côté CSS.

Merci encore une fois pour ta participation â cette discussion. J'espère que d'autres vont s'y joindre pour l'enrichir..
...suite
J'ai installé NVDA sur mon PC pour en avoir le cœur net. Ce "lecteur d'écran" ne fait aucune différence (du moins â mon oreille peu exercée) entre les deux versions de la page de test.
Il est possible que la différence vienne de la version du navigateur que tu utilises, ou bien ton lecteur d'écran te donne des informations que NVDA ne donne pas.
a écrit :
Si les balises personnalisées venaient à devenir populaires, je gage que ce navigateur évoluerait et se mettrait â les supporter


Pour reprendre ma métaphore de ce matin, il y a une énorme différence entre inventer un mot que toi seul comprend et ajouter un mot dans le dictionnaire.

Si tu parviens à ajouter un mot dans le dictionnaire, tu peux bien sûr espérer qu'à terme tout le monde va le comprendre; c'est le but.
En attendant qu'une bonne majorité le comprenne cependant, il vaudrait mieux ne pas l'utiliser.

a écrit :
Pour le reste je ne comprends pas les remarques sur la nécessité d'avoir des balises standardisées. Ce sont les navigateurs qui lisent et interprètent ces balises, pas les utilisateurs. Quand ton lecteur d'écran lit la version "div" de ma page de test, il ne dit pas que ce sont des <div>, je suppose qu'il est fait de telle sorte qu'il reconnaît lesquelles sont en display:block; et lesquelles en display:inline-block; Il suffirait de peu de chose pour qu'il reconnaisse des balises personnalisées.


C'est ici que tu ne comprends pas. Les lecteurs d'écran ont leur propre mode de représentation, qui n'a rien à voir avec une représentation visuelle.
Les lecteurs d'écran n'en mont absolument rien à secouer des CSS, ça ne les concerne pas. CSS définit l'apparence visuelle du contenu, mais pas l'apparence des autres modes de représentation vocal, braille, etc.

A noter que les CSS dont on parle habituellement sont en fait les CSS screen, dédiés donc à une représentation sur écran, purement visuelle; il existe un sous-ensemble de CSS dédié à la représentation lecture vocale, CSS speech; mais aucun lecteur d'écran n'en tient et n'en tiendra probablement jamais compte, car CSS speech est il me semble surtout conçu pour une lecture vocale fondamentalement linéaire; ce que la lecture avec un lecteur d'écran n'est la plupart du temps pas du tout et heureusement; c'est beaucoup plus complexe que ça.

Les seules grandes exceptions, c'est display:none et visibility:hidden, qui s'appliquent à tous les médias (quand bien même visibility est un terme un peu maladroit).

a écrit :
Dans les premières versions du HTML il suffisait de regarder les balises pour savoir comment ça allait s'afficher sur l'écran. On choisissait les balises en fonction du rendu désiré. Maintenant on est obligé de regarder dans le CSS et de faire la correspondance, mais il semble que tout le mode soit d'accord pour considérer la séparation entre structure de page et présentation comme un plus.


Attention attention! Fan de <font>, <center> et autres cochonneries détecté!

Passons la petite blague, bien sûr que c'est un plus. Le web n'est aujourd'hui plus uniquement conçu pour être affiché sur un écran.
Si on a souhaité séparer la structure du contenu de la façon de le représenter, c'est bien parce que plusieurs modes de représentation du même contenu sont possibles et souhaitables d'une part, et d'autre part parce qu'on aimerait que la représentation s'adapte plus ou moins automatiquement lorsque le contenu change sans plus avoir à s'en soucier une fois que les règles de représentation pour le(s) média(s) cible(s) ont été définies.

Tu aimerais retourner à ton vieux Word où le simple fait d'ajouter un mot quelque part a des chances de casser toute la mise en page que tu as mis des heures à élaborer ?
Ou bien PDF, avec une probabilité non nulle que la'ffichage sur ton téléphone soit absolument pas pratique quand bien même sur un écran 22'' c'est parfait ? même combat.

a écrit :
Comme tu l'as bien compris, je travaille à partir de fichiers XML qui sont pour moi la représentation la plus efficace et lisible des objets. J'ai utilisé le XSLT il y a une petite dizaine d'années pour générer du HTML à partir de XML. Je n'avais â l'époque pas accès à un langage sur le serveur de mon entreprise qui ne permettait que de stocker des fichiers.


Du moment que les navigateurs comprennent XSLT, il n'y a aucun problème à l'utiliser pour générer du HTML. C'est le résultat en sortie qui m'intéresse, c'est celui-là qui ne doit contenir que les éléments normés.
Par contre, utiliser des éléments personnalisés sans XSLT et espérer qu'ils seront bien traités, ça ne marche pas.

a écrit :
C'est un mécanisme peu pratique, un langage de programmation descriptif et non dynamique, que j'ai remplacé dès que j'ai pu par des programmes en PHP.


Oui, bon, le gros problème de XSLT c'est qu'il est lui-même du XML. Je ne comprends pas pourquoi XML est autant populaire d'ailleurs, pour les fichiers de configuration par exemple.
Je n'ai jamais eu l'impression que le XML ait été un langage pratique à manipuler pour des humains. Pour des machines oui, mais pas pour des humains.

a écrit :
En pratique, comme je l'ai dit, j'écris peu de HTML directement, je le fais générer par du PHP, et que ça génère <div class="first-name"> ou <x-first-name> a peu d'importance pratique, de toute façon la présentation est faite côté CSS.


Sauf que, comme je l'ai déjà dit, avec <div ... > tu me parles en français, mais avec <x:first-name> tu me parles dans la langue que tu as toi-même inventée et que j'ai de bonnes chances de ne pas comprendre correctement.
Modifié par QuentinC (26 Feb 2015 - 15:10)
Merci Quentin pour ta réponse.

Sans entrer dans les détails, je crois qu'on est passé d'un monde où la présentation se faisait par l'utilisation des balises, chacune ayant son style par défaut, à un monde où les balises ne signifient plus grand chose du point de vue présentation, car tout se trouve dans le CSS.
Je suis d'accord que c'est préférable, mais en toute logique il faudrait supprimer des foultitudes de balises (que du reste je n'ai jamais utilisées ces 20 dernières années, ou que j'ai abandonnées dès que possible).

Les standards sont encore empêtrés dans les anciennes balises, à mon avis pour de simples raisons de compatibilité avec le passé.
N'oublions pas que les USA ont adhéré au système métrique en 1875, mais qu'ils restent un des 3 états au monde à ne pas en avoir fait leur système officiel. (Même les anglais l'ont fait,... mais bien sûr sans le mettre en œuvre, ce qui n'est pas très différent...) On peut donc s'attendre à ce que l'on ait encore dans 50 ans des balises <font>, <center>, etc qui trainent dans les coins...
On en arrive maintenant à mettre des <div> partout, et donc pour moi <div class="lkjh78"> n'apporte pas plus d'information au lecteur humain de la page que <x-lkjh78>. poPour moi, <div> c'est pareil que <schtroumpf> ça veut tout dire ou rien dire...

Bon, attendons quelques années pour voir ce que de jeunes gens inventifs vont faire des balises personnalisées... mais pas trop longtemps, parce qu'à mon âge 20 ans en arrière c'est très près, et 20 ans en avant c'est trop loin...
Modifié par PapyJP (26 Feb 2015 - 17:36)
a écrit :
Je suis d'accord que c'est préférable, mais en toute logique il faudrait supprimer des foultitudes de balises (que du reste je n'ai jamais utilisées ces 20 dernières années, ou que j'ai abandonnées dès que possible).


A quelles balises tu penses ?

a écrit :
Les standards sont encore empêtrés dans les anciennes balises, à mon avis pour de simples raisons de compatibilité avec le passé.


<font>, <center> et ses copines ont été clairement supprimées de la spécification officielle, ou marquées comme legacy ou deprecated. Ils ne font plus partie du standard.

Pour que les concepteurs les abandonnent définitivement, il faudrait maintenant que les navigateurs décident de ne plus les supporter, ou en tout cas pas en mode standard. Qu'il y ait un mode quirk, bon, OK, ayons pitié pour les vieux sites qui n'ont pas été mis à jour depuis 15 ans et dont on a perdu le code source et/ou les mots de passe d'accès.
Mais en mode standard, le support de <font> devrait être terminé

a écrit :
On en arrive maintenant à mettre des <div> partout, et donc pour moi <div class="lkjh78"> n'apporte pas plus d'information au lecteur humain de la page que <x-lkjh78>. poPour moi, <div> c'est pareil que <schtroumpf> ça veut tout dire ou rien dire...


Div et span sont un peu particuliers, ils sont à la limite. C'est les balises qu'il faut utiliser seulement quand aucune autre meilleure ne convient, ou quand on veut exprimer un groupage qui n'a pas nécessairement d'intérêt dans tous les modes de représentation.
Typiquement, on utilise des <div> pour grouper des éléments visuellement.

Elles ont malgré tout avec elles une sémantique fondamentale qui est implicite et que les balises perso n'ont pas par défaut: bloc ou inline.
Tu vas me dire que c'est une propriété purement visuelle, mais en fait, non, pas tout à fait.
Quand on lit en braille, les inline doivent être à la suite mais pas les blocs, qui doivent obligatoirement faire passer à la ligne suivante. Côté vocal, on n'est pas censé faire de pause entre éléments inline, alors que côté bloc on devrait logiquement l'envisager.
Bref, tu l'auras compris, la notion de bloc ou inline n'est pas uniquement visuelle.

En y réfléchissant un peu plus, et après un petit test bidon mais un peu tordu, en fait, le problème, c'est que les valeurs de la propriété display autres que none ne sont pas prises en compte par certains lecteurs d'écran.
Merci freedom scientifric. Voir mon petit test plus bas dans ce post.

Si c'était le cas, en réalité, il n'y aurait fondamentalement plus aucune différence entre <div class="machin"> et <machin>; ça aurait sémantiquement exactement la même valeur, à savoir un groupage quelconque n'ayant pas d'autre signification particulière.
A ce moment-là, beaucoup moins d'inconvénients à utiliser des balises personnalisés.

IL n'empêche que outre pour remplacer avantageusement <div> et <span>, je ne le recommanderais quand même pas, parce qu'à ce moment-là il faut indiquer le rôle sémantique de la balise explicitement et systématiquement.
Même si on pourrait techniquement le faire, mieux vaut éviter pour ne pas plomber la maintenabilité du code et le référencement.

Bon, je vous ai gardé mon petit test pour la fin du post, afin de ne pas vous égarer au milieu de mes réflexions. NVDA tient bien compte des valeurs autres que none de la propriété display, mais jaws pas. Preuve très simple :


<!DOCTYPE HTML>
<html>
<head><title>Test</title></head>
<body>
<?php
$str = 'Salut!';
for($i=0, $n=strlen($str); $i<$n; $i++) {
echo <<<END
<span style="display: block;">{$str[$i]}</span>
END;
}
?>
</body></html>


Comportement obtenu: jaws lit "Salut!" en un mot, tandis que NVDA lit "S. A. L. U. T." lettre par lettre, sur une ligne séparée dans le tampon virtuel. Que ce soit IE, firefox ou chrome c'est pareil.
Le test avec <div style="display: inline;"> aboutit à la même constatation dans le sens inverse.
Tiens... je ne connaissais pas. Du coup je suis allé voir à droite à gauche... Créer son standard perso pour le placer dans LE standard, tout ça pour que des balises html soient plus "jolies" côté dev...

Je ne suis pas convaincu de l'intérêt de la démarche. On n'arrive déjà pas à utiliser la richesse des balises html5 existantes... Par exemple : qui a déjà utilisé <var>, <command>, <samp>, <kbd> ?
Olivier C a écrit :

Je ne suis pas convaincu de l'intérêt de la démarche. On n'arrive déjà pas à utiliser la richesse des balises html5 existantes... Par exemple : qui a déjà utilisé <var>, <command>, <samp>, <kbd> ?


C'est exactement le point.

Comme je l'ai expliqué, j'étais dans la boucle au démarrage du HTML de par mes relations avec les grands programmes de recherche en informatique. Les balises ont été inventées en quelques semaines par des gens qui en avaient besoin (ou qui pensaient qu'ils pourraient en avoir besoin).
Le reste du monde s'en est servi pour faire autre chose, en utilisant essentiellement les balises pour leurs caractéristiques de présentation incluses. Par exemple j'ai pris l'habitude (horrible!) de n'utiliser que <h4> parce que je trouve que les tailles de caractère des autres balises de titre sont trop grosses ou trop petites. Et quand j'ai mis des <h2> et <h3> quelque part, c'est parce que ça va plus vite que de styler un paragraphe. C'est totalement ridicule, mais je ne suis pas le seul à faire ça.
De même pour la marge haute de <p>.
Quant on a inventé le CSS (quelques années plus tard) on aurait dû supprimer toutes ces balises encombrantes et repartir de la base.

Ayant l'habitude de travailler en XML, je trouve les fichiers XML bien plus facile à comprendre, car les personnes qui travaillent dessus se mettent d'accord sur des noms de balise qui sont un sens SÉMANTIQUEMENT, alors que <div> et <span> ne veulent plus rien dire depuis belle lurette.
Dès lors qu'on dispose de CSS display inline, et block, on peut les interchanger en stylant correctement dans la section CSS de la page (ou pire dans un fichier CSS qu'on n'a pas immédiatement sous la main).
Pour moi il est bien plus lisible d'écrire

<person>
    <first-name>Jean-Pierre</first-name>
    <last-name>Moularde</last-name>
</person>

que 


<div class="person">
    <div class="first-name">Jean-Pierre</div>
    <div class="last-name">Moularde</div>
</div>


De toute façon, je ne vais pas révolutionner les us et coutumes, mais j'aimerais savoir comment tout ça va évoluer... sans pour autant vieillir de 20 ans!

Comme je travaille essentiellement sur des fichiers XML, je me fiche un peu de ce à quoi ressemble le HTML généré. Je m'en occupe une fois dans la méthode toHTML de chaque objet et une fois quand j'écris le CSS de la page.
Modifié par PapyJP (28 Feb 2015 - 19:33)
Olivier C a écrit :
Pour moi, la seule sémantique à retenir est celle qui est interprétée par les navigateurs. Je pense que l'avenir est du côté des microformats.

Les navigateurs ne comprennent rien à la sémantique, sauf à appeler abusivement "sémantique" la structure générale d'un document.
Ce sont les renifleurs genre Google qui se servent des microformats. J'en ai effectivement mis dans les pages, mais ça n'a pas l'air de servir à grand chose. De plus ça considère qu'une page HTML doit contenir un "article", genre article de journal avec un auteur (de préférence enregistré sous Google+) un "événement" doit être futur: la naissance du Christ ou le 11 septembre 2001 ne sont pas des événements!...
a écrit :
Quant on a inventé le CSS (quelques années plus tard) on aurait dû supprimer toutes ces balises encombrantes et repartir de la base.


Quelles balises juges-tu encombrantes ?
Et pour toi, qu'est-ce que la base ?

En fait, ton problème est que tu penses beaucoup trop à l'aspect visuel. Je simplifie beaucoup, mais en somme tu utilises H1 uniquement parce que tu veux que ce soit écrit plus gros.
Quand tu rédiges un document, tu devrais plutôt avoir la réflexion suivante: j'utilise H1 parce que c'est un titre de niveau 1 par rapport au plan / à la structure de mon document. C'est tout.
Tu devrais seulement te poser la question de l'aspect visuel après, une fois que tu as terminé d'écrire et que toutes tes pensées ont été structurées correctement.

La plupart des gens ont ce défaut de vouloir penser en même temps à la structure et à l'apparence; alors qu'on a déjà prouvé que c'était beaucoup plus efficace de faire d'abord l'un, puis ensuite l'autre; même pour ceux qui ont subi une ablation partielle du cerveau suite à une mauvaise utilisation prolongée de Microsoft Word.

C'est un nouveau mode de pensée à appréhender, et je sais, ce n'est pas facile: se détacher de l'aspect visuel, et essayer de se dire que ce qu'on a écrit n'est pas uniquement destiné à être affiché sur un écran.
Les logiciels de lecture vocale ou en braille tout comme les outils d'extraction de données n'ont que faire de <font> et en général des CSS screen.
ET dans le futur, les hologrammes 3D qui parleront en langue des signes non plus...

a écrit :
Les navigateurs ne comprennent rien à la sémantique, sauf à appeler abusivement "sémantique" la structure générale d'un document.


C'est complètement faux. Ca paraît presque vrai parce que, dans le cadre des navigateurs affichant des pages sur un écran, la représentation par défaut est toujours totalement remplacée par des CSS spécifiques au site visité.
Puisqu'on peut afficher ce qu'on veut comme on veut avec à peu près n'importe quel code, certains s'en foutent royalement: cas extrême, un certain nombre de sites ne connaissent que 5 balises: <div>, <span>, <a>, <form> et <input/> (je vous jure que ça c'est déjà vu)

ON ne dirait certainement pas que les navigateurs graphiques ne comprennent rien à la sémantique si les CSS n'étaient utilisés que pour ne faire ponctuellement que quelques ajustements très localisés et que sinon la représentation par défaut était largement conservée.

En fait, je suis quelque part bien content que les CSS speech ne soient pas pris en compte par mon lecteur d'écran. Je crois qu'à la fin ça me saoulerait si chaque site m'imposait ses propres voix, intonations et rythme de lecture propres, en prenant le dessus sur mes choix personnels.
JE suis sûr que certaines personnes bien voyantes pensent un peu à la même chose parfois, et regrettent que les sites n'aient pas globalement une allure plus homogène.

Je répondrai à la suite demain.
Merci Quentin de te passionner pour ce problème.... bien plus que je ne je fais moi même
J'ai simplement, en début de ce fil, demandé si quelqu'un pouvait me fournir de l'info sur ce qui se faisait dans le domaine des balises personnalisées. Je ne m'attendais pas à tant de passion pour... pour quoi en fait?

Que les balises aient perdu tout sens, pour autant qu'elles en aient jamais eu, c'est une constatation qu'on peut faire tous les jours, il suffit de faire Ctrl-U sur les pages que l'on trouve sur internet. La fait que l'on utilise de plus en plus le CSS (qui, je le rappelle, n'est arrivé que beaucoup plus tard) ne fait que vider de sens les balises courantes.
En inventer de nouvelles comme on a fait en HTML 5 ne me semble pas avoir apporté plus de clarté.

Il faut bien comprendre que j'ai démarré au tout début, on faisait ce qu'on pouvait avec ce qu'on avait sous la main. Dans les années 90 utiliser des balises <h1> donnait un rendu visuel horrible, ét on ne savait pas comment faire mieux, sauf à utiliser d'autres balises pour obtenir la présentation qu'on voulait. Après, on prend des habitudes...

En ce qui me concerne, 7 ans après avoir pris ma retraite et utilisé un peu de mon temps pour faire des sites pour des associations le des amis indépendants, j'ai voulu regarder comment ça avait évolué. Comme ce site me semblait assez bien fait et qu'on y trouvait des infos intéressantes, je m'y suis inscrit l'an denier et je ne regrette pas, car la solitude n'est pas un moyen de progresser, et je préfère les discussions qui ont lieu sur ce site â ce que j'ai pu trouver ailleurs., en particulier la dogma de Google.

Parmi les choses que j'ai prises en compte après avoir consulté ce site, je citerai, dans le désordre, le passage à HTML5 et CSS3, une meilleure prise en compte de l'UTF-8, et plus récemment l'utilisation de jQuery et des média queries. En quelques mois., je trouve que c'est déjà une moisson intéressante. Je suis donc toujours curieux de poursuivre l'exploration des terres nouvelles et de savoir ce qu'elles nous proposent comme flore et faune inconnue.

Je demande simplement qu'on ne tente pas de me convertir â quelque religion que ce soit. Les événements récents nous confirment que l'observation du réel, la rationalité et le doute philosophique sont les seules clartés qui peuvent nous guider dans la recherche jamais terminée d'une méthode de travail et de pensée constructive.
Pages :
Sujet clos
Aller à