5568 sujets
Sémantique web et HTML
Normand Lamoureux a écrit :
bloc ne me dit rien sur l'élément p
Si, au contraire. Ça ne dit pas tout, soit, mais comme le comportement d'un paragraphe est de type bloc et que ce n'est pas accessoire, on ne peut pas dire que ça ne dit rien.
La phrase complète, Normand, était : ce n'est pas la nature de l'élément lui-même qui est décrite : bloc ne me dit rien sur l'élément p. Avec le mot nature en italique.
Si on se met à isoler des morceaux de citation pour couper le cheveu en quatre, franchement, nous y serons encore quand HTML ne sera plus qu'un lointain souvenir des premiers temps du Web !
Modifié par Laurent Denis (16 Jul 2005 - 18:09)
Humpffff 
Pardon, ça m'a échappé
Pourquoi ces éléments forcent-ils un retour à la ligne ?
Parce que, pour prendre l'exemple de p et de hr :
Ceci est extrait de la feuille de style par défaut du navigateur Firefox : oui, tout ces éléments font un retour à la ligne, à cause du display:block CSS qui n'a aucun rapport avec le fait qu'ils soient des éléments de niveau block en HTML, c'est à dire avec leur place dans l'arbre du document.
Parler du retour à la ligne associé fréquemment avec ces éléments ne fait que nous ramener à CSS : nous ne parlons plus du sens de "bloc" du point de vue HTML. Voir le message ci-dessus, à propos duquel tu disais :
Modifié par Laurent Denis (16 Jul 2005 - 18:24)
Pardon, ça m'a échappé
Pourquoi ces éléments forcent-ils un retour à la ligne ?
Parce que, pour prendre l'exemple de p et de hr :
Firefox\res\html.css a écrit :
p, dl, multicol {
display: block;
margin: 1em 0;
}
...
hr {
display: block;
height: 2px;
border: 1px -moz-bg-inset;
margin: 0.5em auto 0.5em auto;
-moz-float-edge: margin-box;
-moz-box-sizing: border-box;
}
Ceci est extrait de la feuille de style par défaut du navigateur Firefox : oui, tout ces éléments font un retour à la ligne, à cause du display:block CSS qui n'a aucun rapport avec le fait qu'ils soient des éléments de niveau block en HTML, c'est à dire avec leur place dans l'arbre du document.
Parler du retour à la ligne associé fréquemment avec ces éléments ne fait que nous ramener à CSS : nous ne parlons plus du sens de "bloc" du point de vue HTML. Voir le message ci-dessus, à propos duquel tu disais :
Normand Lamoureux a écrit :
Que display:block n'aie aucune influence sur la nature d'un élément HTML, soit (et je suis parfaitement d'accord)
Modifié par Laurent Denis (16 Jul 2005 - 18:24)
Ce qu'en disent les specs me semblait pourtant assez clair sur le comportement associé aux blocs/inline :
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3
Modifié par Raphael (16 Jul 2005 - 18:30)
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3
Traduction des spec HTML 4.01 a écrit :
7.5.3 Les éléments de bloc et les éléments en-ligne
Certains éléments HTML, qui peuvent apparaître dans l'élément BODY, sont dits être de niveau « bloc » [ndt. block-level] tandis que d'autres sont dits de niveau « en-ligne » [ndt. inline] (aussi connu comme sous le nom « niveau texte »). La distinction se fondent sur plusieurs notions :
Le modèle de contenu
De manière générale, les éléments de bloc peuvent contenir des éléments en-ligne et d'autres éléments de bloc. Et de manière générale, les éléments en-ligne ne peuvent contenir que des données et d'autres éléments en-ligne. L'idée inhérente à cette distinction structurelle, c'est que les éléments de bloc créent des structures « plus grandes » que les éléments en-ligne.
Le formatage
Par défaut, les éléments de bloc sont formatés différemment des éléments en-ligne. En général, les éléments de bloc commencent sur une nouvelle ligne, et non les éléments en-ligne. Pour des informations concernant les blancs, les sauts de ligne et le formatage des blocs, veuillez consulter la section sur le texte.
La directionnalité
Pour des raisons techniques impliquant l'algorithme de texte bi-directionnel [UNICODE], les éléments de bloc diffèrent de ceux en-ligne par la manière dont ils héritent des informations de directionnalité. Pour les détails, voir la section sur l'héritage de la direction du texte.
Les feuilles de style fournissent les moyens de spécifier la restitution d'éléments arbitraires, y compris si l'élément est rendu comme étant de type bloc ou de type en-ligne. Cela peut être approprié, dans certains cas, tel qu'un style en-ligne pour les éléments d'une liste, mais généralement parlant, on décourage les auteurs de détourner l'interprétation conventionnelle des éléments HTML de cette façon.
Modifié par Raphael (16 Jul 2005 - 18:30)
Deux choses importantes, dans cet extrait de la spécification :
- il s'agit bien d'éléments de niveau bloc et de niveau en ligne, la distinction étant fondée sur leurs relations dans l'arbre du document (exprimée ici en terme de "peuvent contenir"). La distinction n'est donc en rien fondée sur la nature, la fonction, etc. de ces éléments.
- le formatage ... Ah ! C'est la grande frilosité de HTML4.01, dont il ne faut pas oublier l'âge et l'absence d'erratas depuis belle lurette : HTML4.01 véhicule en effet l'idée selon laquelle le formatage d'une élément avait un caractère "obligé", lié à une "interprétation conventionnelle".
Hum... "interprétation conventionnelle" que la spécification se garde bien de justifier ou d'étayer. Et qu'elle semble bien embarassée pour tenter d'imposer.
Soyons lucides : qui se soucie de ce "formatage conventionnel" aujourd'hui ?
Ou alors, nous renonçons à utiliser display:block sur des éléments display:inline par défaut... Zut pour les boutons CSS sur les liens ! Inutile de compter utiliser un jour display:table pour autre chose qu'un élément TABLE... Fini, les display:block et sur les SPAN et autres éléments abondamment utilisés pour les menus coulissants. Et fini les menus coulissants par la même occasion.
Même le très attendu display:inline-block qui nous affranchira de nos tortueuses combinaisons de float me semble tout à coup suspect, si je prends ce passage de la spécification sans regard critique.
Définir une nature des éléments HTML par leur formattage visuel aboutit à revenir à une HTML de présentation, limité au seul média "écran de mon PC".
Abordons les choses, plutôt, avec le regard d'utilisateurs XML : mes éléments BROCOLIS, RDF, RSS ou FOAF n'ont aucune valeur de présentation visuelle. Je suis tout à fait libre de les styles via CSS.
HTML4.01 est loin d'être, sur certains points, une spécification bien écrite et suffisamment à jour.
Modifié par Laurent Denis (16 Jul 2005 - 19:12)
- il s'agit bien d'éléments de niveau bloc et de niveau en ligne, la distinction étant fondée sur leurs relations dans l'arbre du document (exprimée ici en terme de "peuvent contenir"). La distinction n'est donc en rien fondée sur la nature, la fonction, etc. de ces éléments.
- le formatage ... Ah ! C'est la grande frilosité de HTML4.01, dont il ne faut pas oublier l'âge et l'absence d'erratas depuis belle lurette : HTML4.01 véhicule en effet l'idée selon laquelle le formatage d'une élément avait un caractère "obligé", lié à une "interprétation conventionnelle".
Hum... "interprétation conventionnelle" que la spécification se garde bien de justifier ou d'étayer. Et qu'elle semble bien embarassée pour tenter d'imposer.
Soyons lucides : qui se soucie de ce "formatage conventionnel" aujourd'hui ?
Ou alors, nous renonçons à utiliser display:block sur des éléments display:inline par défaut... Zut pour les boutons CSS sur les liens ! Inutile de compter utiliser un jour display:table pour autre chose qu'un élément TABLE... Fini, les display:block et sur les SPAN et autres éléments abondamment utilisés pour les menus coulissants. Et fini les menus coulissants par la même occasion.
Même le très attendu display:inline-block qui nous affranchira de nos tortueuses combinaisons de float me semble tout à coup suspect, si je prends ce passage de la spécification sans regard critique.
Définir une nature des éléments HTML par leur formattage visuel aboutit à revenir à une HTML de présentation, limité au seul média "écran de mon PC".
Abordons les choses, plutôt, avec le regard d'utilisateurs XML : mes éléments BROCOLIS, RDF, RSS ou FOAF n'ont aucune valeur de présentation visuelle. Je suis tout à fait libre de les styles via CSS.
HTML4.01 est loin d'être, sur certains points, une spécification bien écrite et suffisamment à jour.
Modifié par Laurent Denis (16 Jul 2005 - 19:12)
Je m'aperçois en relisant ce qui précède que je m'autorise à dire qu'un passage de la sainte spécification HTML4.01 est abusif.
Ce qui peut surprendre. Qu'est-ce qui m'autorise à dire cela ? 4 choses.
1) D'abord, le fait que le développement d'HTML a été interrompu avec cette dernière spécification : ni errata, ni nouvelle version pour corriger et compléter ce format.
Remarquons au passage que cette "abandon" du HTML ne fait pas aujourd'hui l'unanimité, puisque la fondation Mozilla, Opera et Safari, entre autres, sont à l'origine d'un projet de HTML5.0 (les travaux actuels du WHATG).
Notons également que cette spécification a été écrite à un moment où on était loin d'avoir pu mesurer le rôle de CSS, encore largement théorique.
L'important à retenir est que nous basons toujours aujourd'hui sur un texte que l'on savait imparfait au départ, mais qui reste et restera toujours une norme supportée par le W3C, aussi gênant qu'il soit parfois. Reste à trouver comment s'en accomoder.
2) Or, pour en revenir à ce passage de la spec, il y a une première observation à faire : il ne me semmble pas cohérent en tant que texte normatif.
On suggère en effet aux auteurs de sites Web une "interprétation conventionnelle" du point de vue visuel, des éléments HTML. Soit. Mais fondée sur des termes ouvertements flous: En général, les éléments de bloc..., dans certains cas, ... mais généralement parlant... qui ne permettent aucune implémentation ou application fiable.
3) Surtout, ce passage crée une contradiction ou au moins une tension entre différentes spécifications :
- d'un côté, cette interprétation conventionnelle qu'on me déconseille de modifier
- d'un autre, CSS qui a été conçu pour me permettre de le faire.
- Tiens, une chose amusante: je modifie à ma guise la présentation via CSS en XML. Or XHTML... n'est-il pas aussi du XML ? Me voilà bien ennuyé si je suis HTML4.01 à la lettre
4) Quid d'une interprétation conventionnelle des éléments HTML dans le media speech ? Si elle se justifie quand on affiche, pourquoi ne se justifierait-elle pas quand on lit ? Mais je sens qu'elle va être nettement plus difficile à définir, celle-là.
Pour tout dire, la spécification HTML n'avait pas à aborder ce point, AMHA. S'il y a des raisons valables pour lesquels les auteurs devraient respecter une certaine "présentation visuelle conventionnelle" des éléments HTML ou XHTML (sic), c'est à un document normatif totalement indépendant de le définir et surtout de le justifier. Par exemple, la WCAG, qui aborde justement cette question, sans pour autant susciter toutes ces réserves.
On éviterait ainsi cette confusion permanente entre structure et présentation dans la compréhension des éléments HTML, qui est tout de même un comble non ?
Modifié par Laurent Denis (16 Jul 2005 - 20:49)
Ce qui peut surprendre. Qu'est-ce qui m'autorise à dire cela ? 4 choses.
1) D'abord, le fait que le développement d'HTML a été interrompu avec cette dernière spécification : ni errata, ni nouvelle version pour corriger et compléter ce format.
Remarquons au passage que cette "abandon" du HTML ne fait pas aujourd'hui l'unanimité, puisque la fondation Mozilla, Opera et Safari, entre autres, sont à l'origine d'un projet de HTML5.0 (les travaux actuels du WHATG).
Notons également que cette spécification a été écrite à un moment où on était loin d'avoir pu mesurer le rôle de CSS, encore largement théorique.
L'important à retenir est que nous basons toujours aujourd'hui sur un texte que l'on savait imparfait au départ, mais qui reste et restera toujours une norme supportée par le W3C, aussi gênant qu'il soit parfois. Reste à trouver comment s'en accomoder.
2) Or, pour en revenir à ce passage de la spec, il y a une première observation à faire : il ne me semmble pas cohérent en tant que texte normatif.
On suggère en effet aux auteurs de sites Web une "interprétation conventionnelle" du point de vue visuel, des éléments HTML. Soit. Mais fondée sur des termes ouvertements flous: En général, les éléments de bloc..., dans certains cas, ... mais généralement parlant... qui ne permettent aucune implémentation ou application fiable.
3) Surtout, ce passage crée une contradiction ou au moins une tension entre différentes spécifications :
- d'un côté, cette interprétation conventionnelle qu'on me déconseille de modifier
- d'un autre, CSS qui a été conçu pour me permettre de le faire.
- Tiens, une chose amusante: je modifie à ma guise la présentation via CSS en XML. Or XHTML... n'est-il pas aussi du XML ? Me voilà bien ennuyé si je suis HTML4.01 à la lettre
4) Quid d'une interprétation conventionnelle des éléments HTML dans le media speech ? Si elle se justifie quand on affiche, pourquoi ne se justifierait-elle pas quand on lit ? Mais je sens qu'elle va être nettement plus difficile à définir, celle-là.
Pour tout dire, la spécification HTML n'avait pas à aborder ce point, AMHA. S'il y a des raisons valables pour lesquels les auteurs devraient respecter une certaine "présentation visuelle conventionnelle" des éléments HTML ou XHTML (sic), c'est à un document normatif totalement indépendant de le définir et surtout de le justifier. Par exemple, la WCAG, qui aborde justement cette question, sans pour autant susciter toutes ces réserves.
On éviterait ainsi cette confusion permanente entre structure et présentation dans la compréhension des éléments HTML, qui est tout de même un comble non ?
Modifié par Laurent Denis (16 Jul 2005 - 20:49)