5569 sujets

Sémantique web et HTML

Un peu de HTML 5 (brouillon) pour s'amuser ?

Pages :
Hello tout le monde,

Via un commentaire de Lanza (si ma mémoire est bonne), le document suivant :
http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html#new-elements

C'est un résumé des différences entre HTML4 et HTML5 (qui semble-t-il sera décliné en XHTML5, et donc pas XHTML2... mais j'ai pas suivi toute l'affaire).

Bon, pour les affolements, les « qu'est-ce que je dois faire alors ? comment je code mon document ? » et autres joyeusetés, on attendra que la spécification soit prête, hein. Mais d'ici là on peut toujours jeter un oeil.

Je vous refait pas le menu, mais juste pour le plaisir :
- relativement anecdotique : <acronym> déprécié au profit de <abbr> ;
- moins anecdotique : <frame>, <frameset> et <noframes> dépréciés (mais pas <iframe>).
Modifié par Florent V. (20 Jun 2007 - 11:22)
Florent V. a écrit :
<acronym> déprécié au profit de <abbr>

Pourquoi cette évolution? À ce que je sache, une abbréviation n'est pas synonyme d'acronyme. Smiley sweatdrop
D'après ce brouillon, certains éléments et attributs dépréciés en HTML 4 font leur retour en HTML 5.

Quant au doctype, il est on ne peut plus facile à retenir :
<!DOCTYPE html>

Smiley lol

En tout cas, il faudra dire adieu à IE si l'on veut produire du (X)HTML 5. Smiley rolleyes
Il y a des spécifications qui me laissent pour l'instant franchement perplexe, ce n'est peut-être qu'à l'utilisation que l'on se rendra compte de l'intérêt de ces dernières, dont celle-ci:

[b][#black]VALIDE[/#][/b]

<div>
 <em>…</em>
 …
</div>
<div>
 <p><em>…</em></p>
 <p>…</p>
</div>


[b][#black]INVALIDE[/#][/b]

<div>
 <em>…</em>
 <p>…</p>
</div>


Notre division ne pourra contenir à la fois que directement du contenu d'un certain type (bloc ou en ligne) et non les deux simultanément. Je ne vois à priori aucun intérêt à une telle limitation, et vous?
Benjamin D.C. a écrit :
Pourquoi cette évolution? À ce que je sache, une abbréviation n'est pas synonyme d'acronyme. Smiley sweatdrop

Alors, pour faire simple :
- ces deux éléments ont la même fonction technique et sont sémantiquement proches... ils posent donc de nombreux problèmes inutiles aux rédacteurs qui devraient faire un choix informé entre les deux dès que nécessaire... bonjour l'angoisse ;
- un acronyme est un cas particulier d'abréviation (si si, sans déconner) ;
- « acronym » (en anglais) a un sens spécifique, qui est propre à la langue et que l'on ne retrouve pas dans d'autres pays.

Sur ce dernier point :
- « acronyme » en français ne correspond pas à « acronym » en anglais ;
- pour d'autres langues à l'alphabet latin, c'est peut-être aussi le cas (ou pire) ;
- et pour les langues non occidentales, il est possible que la notion d'acronyme n'existe même pas.
Autre point perplexe : la nouvelle sémantique des éléments b et i sera encore plus abstraite (quelqu'un pourrait-il traduire un tel jargon ? Smiley ohwell ) que les éléments strong et em tels que nous les connaissons actuellement.

Bref, de quoi désorienter plus d'un. Heureusement qu'on n'est pas vendredÿ... Smiley rolleyes
Modifié par Victor BRITO (18 Jun 2007 - 15:42)
Victor BRITO a écrit :
quelqu'un pourrait-il traduire un tel jargon ? Smiley ohwell

<b> = de la mise en forme visuelle, vecteur d'information (attirer l'attention, insistance...) visuelle à priori non retranscrite par une synthèse vocale...
<i> = une inflexion de sens (et donc probablement de ton)... là encore, la référence première est celle de l'écrit et des usages des italiques dans l'imprimé... bien noter au passage la mention des disparités d'une langue à l'autre, c'est à dire qu'en gros la sémantique de <i> dépendra de la langue, de la culture...
<em> = emphase
<strong> = l'importance plutôt que l'emphase forte... (pas évident, celle là...)

Pour ma part, je trouve que ça clarifie et complexifie à la fois. Smiley ravi
Mais bon, on verra à la version finale ce qu'il en reste...
Modifié par Florent V. (18 Jun 2007 - 18:22)
a écrit :
D'après ce brouillon, certains éléments et attributs dépréciés en HTML 4 font leur retour en HTML 5.

Comme <menu> par exemple. D'ailleurs je n'ai pas compris pourquoi il avait été abandonné au profit d'une simple liste <ul>, dans le sens où un menu est à mon avis bien plus qu'une simple liste d'items. Donc, ils méritent d'être différenciés.

Une chose que je trouve intéressante, c'est les ajouts qui sont prévus pour les formulaires. Enfin une prise en charge native attendue depuis longtemps qui comble un fossé actuellement couvert par l'utilisation de javascripts (plus difficilement maintenables que du simple HTML)
Je ne vois juste pas quel avantage procurerait <datalist> avec <input list="..." /> par rapport à <select>.

Autre question que je me pose, quel est l'intérêt du couplé <header> et <section> par rapport aux titres <hn> ?

Dans tous les cas donnons-nous rendez-vous sous Firefox 4 qui sortira en 2008 ou 2009 et ... Internet Explorer 9.0 prévu en 2018 pour tester HTML5.

Non sérieusement, combien de temps faudra-t-il attendre avant qu'on puisse dire qu'on va faire son site en HTML5 ??
Dans tous les cas, les applications web ont un bel avenir ... pour autant que cette hypothétique version 5 de HTML devienne réellement utilisable un jour.
QuentinC a écrit :

Comme <menu> par exemple. D'ailleurs je n'ai pas compris pourquoi il avait été abandonné au profit d'une simple liste <ul>, dans le sens où un menu est à mon avis bien plus qu'une simple liste d'items. Donc, ils méritent d'être différenciés.


Parce que cette différenciation d'éléments n'avait de de sens que si elle se traduisait par une implémentation spécifique de l'élément menu; seulement voilà: menu a historiquement été implémenté comme un simple clone de ul. D'où sa dépréciation en retour d'implémentation.

En fait, je crains qu'il n'y ait pas un centime à parier sur l'avenir de ce come-back, si l'industrie n'est pas réellement disposée à implémenter une gestion spécifique des menus dans les interfaces de navigateurs (parce que si c'est pour garder les menus de navigation dans l'interface de page, l'intérêt est très limité). A voir l'enterrement progressif et déterminé des link rel de navigation, j'avoue avoir un gros doute...

QuentinC a écrit :


Autre question que je me pose, quel est l'intérêt du couplé <header> et <section> par rapport aux titres <hn> ?


S'affranchir des contraintes liées à des niveaux de titrage fixes, et bénéficier d'une gestion en contexte du niveau de chaque titre. le gain est considérable lorsqu'un contenu va être utilisé dans des contextes de page différents.
Modifié par Laurent Denis (19 Jun 2007 - 08:31)
Florent V. a écrit :

Pour ma part, je trouve que ça clarifie et complexifie à la fois. Smiley ravi
Mais bon, on verra à la version finale ce qu'il en reste...


Cela ne change surtout strictement rien aux difficultés d'usage de ces deux élément i et b. Mais c'est un point qui est appelé à être beaucoup discuté et, en effet, à évoluer.

Sinon, juste en passant: la mort annoncée (proposée) d'une partie des attributs d'accessibilité des tableaux de données mériterait qu'on s'y arrête, surtout dans ce forum, il me semble Smiley ravi
Modifié par Laurent Denis (19 Jun 2007 - 08:36)
Laurent Denis a écrit :

S'affranchir des contraintes liées à des niveaux de titrage fixes, et bénéficier d'une gestion en contexte du niveau de chaque titre. le gain est considérable
lorsqu'un contenu va être utilisé dans des contextes de page différents.

Peux-tu en dire un peu plus, avec un exemple ? Je ne suis pas sûr d'avoir saisi...

Laurent Denis a écrit :

Sinon, juste en passant: la mort annoncée (proposée) d'une partie des attributs d'accessibilité des tableaux de données mériterait qu'on s'y arrête, surtout dans ce forum, il me semble Smiley ravi

Bof, ceux qui ont été supprimé n'ont qu'une utilité anecdotique, à mon avis.
Personnellement, je n'ai en tout cas jamais trouvé une utilité quelconque à axis, scope, et au combiné id/headers. Avec jaws, je n'ai jamais remarqué de différence qu'ils y soient ou pas.
Suffit d'avoir un peu de bon sens quand on construit ses tableaux de données : thead/tbody, et ne pas oublier les très importants th pour les en-têtes.
Ce qui est effectivement un peu plus étonnant, c'est la disparition de summary. Mais je pense qu'on peut le remplacer par <caption>. L'effet vocal n'est pas tout à fait le même mais ça reste proche.
Laurent Denis a écrit :


Parce que cette différenciation d'éléments n'avait de de sens que si elle se traduisait par une implémentation spécifique de l'élément menu; seulement voilà: menu a historiquement été implémenté comme un simple clone de ul. D'où sa dépréciation en retour d'implémentation.

En fait, je crains qu'il n'y ait pas un centime à parier sur l'avenir de ce come-back, si l'industrie n'est pas réellement disposée à implémenter une gestion spécifique des menus dans les interfaces de navigateurs (parce que si c'est pour garder les menus de navigation dans l'interface de page, l'intérêt est très limité). A voir l'enterrement progressif et déterminé des link rel de navigation, j'avoue avoir un gros doute...


M'est avis que c'est surtout prévu pour Google. Comme ça il pourra séparer le vrai contenu de la navigation et il sera content.

A propos des rel, si on pouvait m'expliquer concrètement l'attibut rev, j'en serais ravi, j'ai jamais bien compris dans quel contexte on l'utilisait.
Lanza a écrit :
A propos des rel, si on pouvait m'expliquer concrètement l'attibut rev, j'en serais ravi, j'ai jamais bien compris dans quel contexte on l'utilisait.

D'après la documentation officielle, rev désigne un lien en arrière (une sorte de chapitre précédent). Autrement dit, pour une liaison entre deux pages Web, les deux lignes de code suivants sont équivalents :
Page A <link href="b.html" rel="foo" />
Page B <link href="a.html" rev="foo" />
Laurent Denis a écrit :

S'affranchir des contraintes liées à des niveaux de titrage fixes, et bénéficier d'une gestion en contexte du niveau de chaque titre. le gain est considérable lorsqu'un contenu va être utilisé dans des contextes de page différents.
QuentinC a écrit :

Peux-tu en dire un peu plus, avec un exemple ? Je ne suis pas sûr d'avoir saisi...


Déjà il peut arriver qu'on ait besoin de h7, h8, h9... Donc là en imbriquant les <section>, les niveaux de titrages sont virtuellement illimités.

Ensuite imagine un même article sur deux documents différents : l'un dans une liste d'articles, l'autre sur sa propre page (au hasard sur un blog). On rencontre souvent le problème suivant :

Dans le cas de la liste on a une structure dans le genre :

<h1>Liste d'articles</h1>
<h2>Titre du premier article</h2>
<p>Corps du premier article</p>
<h2>Titre du second article</h2>
<p>Corps du second article</p>


Et lorsque l'article est tout seul sur sa page :


<h1>Titre de l'article</h1>
<p>Corps de l'article</p>


Voilà, le titre de l'article est dans un cas un h2, dans un autre un h1 suivant le contexte. Et pour peu que l'article contienne des sous titres, il faut les décaler de la même manière. Les <section> et <header> permettent de créer un contexte propre à l'article qui ne nécessite pas ce décalage au niveau de la structure des titres.

Par contre ça permet également ce genre de structure piège (mais qui peut être également très utile, à mon avis).


<section>
<header>Titre 1</header>
<p>Ce texte est en relation avec le titre 1.</p>
<section>
<header>Titre 2</header>
<p>Ce texte est en relation avec le titre 2</p>
</section>
<p id="texte_problematique">Ce texte est en relation avec le titre 1</p>
</section>


le paragraphe #texte_problématique ici est en dehors de la section introduite par le titre 2 et donc appartient logiquement au titre 1. Par contre au niveau de la présentation, il va falloir faire vachement gaffe à bien marquer cette spécificité, car vu qu'il suit Titre 2 on peut logiquement penser qu'il est en relation avec lui, et ça peut enduire le lecteur d'erreur.

Mais en fait, je pense que si <section> et <header> ont été introduits dans HTML5, c'est juste pour faire enrager Daniel Glazman. (voir le point 7 de cet article) Smiley biggol

Edit : Merci Victor, j'avais déjà lu cet exemple, mais j'ai toujours du mal à saisir comment on peut s'en servir concrètement. En fait ça signifie que la relation donnée dans le rel et le rev a un sens ("sens" au sens de direction, pas au sens sémantique Smiley confus ), et j'ai du mal à imaginer comment la mettre en œuvre.
Modifié par Lanza (19 Jun 2007 - 16:15)
Lanza a écrit :
Merci Victor, j'avais déjà lu cet exemple, mais j'ai toujours du mal à saisir comment on peut s'en servir concrètement. En fait ça signifie que la relation donnée dans le rel et le rev a un sens ("sens" au sens de direction, pas au sens sémantique Smiley confus ), et j'ai du mal à imaginer comment la mettre en œuvre.

D'autant plus que l'attribut rel peut recevoir, entre autres valeurs, "next" et "prev". Smiley langue
Modifié par Victor BRITO (19 Jun 2007 - 11:28)
Lanza a écrit :

Déjà il peut arriver qu'on ait besoin de h7, h8, h9... Donc là en imbriquant les <section>, les niveaux de titrages sont virtuellement illimités.

J'ai pas pensé à ça effectivement, mais pourquoi ne pas garder <hn> en étendant n à un nombre quelconque ?
Les navigateurs sont largement capables de capturer une balise de type <h{0-9]+>.

Lanza a écrit :

Ensuite imagine un même article sur deux documents différents : l'un dans une liste d'articles, l'autre sur sa propre page (au hasard sur un blog). On rencontre souvent le problème suivant :

Dans le cas de la liste on a une structure dans le genre :

<h1>Liste d'articles</h1>
<h2>Titre du premier article</h2>
<p>Corps du premier article</p>
<h2>Titre du second article</h2>
<p>Corps du second article</p>


Et lorsque l'article est tout seul sur sa page :


<h1>Titre de l'article</h1>
<p>Corps de l'article</p>


Voilà, le titre de l'article est dans un cas un h2, dans un autre un h1 suivant le contexte. Et pour peu que l'article contienne des sous titres, il faut les décaler de la même manière. Les <section> et <header> permettent de créer un contexte propre à l'article qui ne nécessitent pas ce décalage au niveau de la structure des titres.

Merci pour l'explication. C'est sûr que de ce point de vue là, ça peut faciliter bien des choses pour le rédacteur.

Lanza a écrit :

Par contre ça permet également ce genre de structure piège (mais qui peut être également très utile, à mon avis).


<section>
<header>Titre 1</header>
<p>Ce texte est en relation avec le titre 1.</p>
<section>
<header>Titre 2</header>
<p>Ce texte est en relation avec le titre 2</p>
</section>
<p id="texte_problematique">Ce texte est en relation avec le titre 1</p>
</section>


le paragraphe #texte_problématique ici est en dehors de la section introduite par le titre 2 et donc appartient logiquement au titre 1. Par contre au niveau de la présentation, il va falloir faire vachement gaffe à bien marquer cette spécificité, car vu qu'il suit Titre 2 on peut logiquement penser qu'il est en relation avec lui (...)

Cette structure me paraît complètement illogique et incohérente, justement parce que ce à quoi se rattage le paragraphe problématique n'est pas clair, si on lisait le texte à haute voix en ignorant le balisage par exemple.
Avec les titres <hn>, il est impossible de faire cette confusion : le paragraphe se rapporte au dernier titre, et point final.
Je n'arrive vraiment pas à comprendre dans quelles circonstances une telle structure peut être valable. Exemple ?

Lanza a écrit :

et ça peut enduire le lecteur d'erreur.

Aïe la peinture rouge dégouline, tu m'as effectivement enduit d'erreur... PS : ne pas confondre "induire en erreur" et "enduire d'erreur".

Lanza a écrit :

Mais en fait, je pense que si <section> et <header> ont été introduits dans HTML5, c'est juste pour faire enrager Daniel Glazman. (voir le point 7 de cet article) Smiley biggol

Remarque il n'a pas tout tort, ça complexifie la lecture/compréhension du code CSS.
h1 { ... } h2 { ... } est nettement plus évident à lire, comprendre, maintenir que section>section>header { ... } section<header { ... }
Lanza a écrit :


A propos des rel, si on pouvait m'expliquer concrètement l'attibut rev, j'en serais ravi, j'ai jamais bien compris dans quel contexte on l'utilisait.


C'est normal: on ne l'utilise pas. C'était une tentative sémantique avant l'heure, avortée depuis;
Modifié par Laurent Denis (19 Jun 2007 - 13:57)
Lanza a écrit :



<section>
<header>Titre 1</header>
<p>Ce texte est en relation avec le titre 1.</p>
<section>
<header>Titre 2</header>
<p>Ce texte est en relation avec le titre 2</p>
</section>
<p id="texte_problematique">Ce texte est en relation avec le titre 1</p>
</section>


le paragraphe #texte_problématique ici est en dehors de la section introduite par le titre 2 et donc appartient logiquement au titre 1.


Perdu, c'est une strucrture défectueuse (mais bien vue sur le fond). soit il n'a rien à faire là, soit il lui manque un titre. HTML est bêtement linéaire, et c'est une limite essentielle pour les contenus actuels.
Modifié par Laurent Denis (19 Jun 2007 - 13:53)
Ceci dit, la structure proposée par Lanza est courante dans différents textes structurés, notamment des travaux universitaires. En général, l'agencement des contenus dans ces documents étant pensé en partie en termes visuels, on joue sur l'espace à gauche pour indiquer la profondeur dans la démonstration, ou bien à la rigueur sur des sauts de ligne.
Lanza a écrit :

Mais en fait, je pense que si <section> et <header> ont été introduits dans HTML5, c'est juste pour faire enrager Daniel Glazman. (voir le point 7 de cet article) Smiley biggol


La réponse sur le fond s'appelle peut-être mapping et possibilité de styler non les header, mais spécifiquement les niveaux résultants.
Pages :
Sujet clos
Aller à