5568 sujets

Sémantique web et HTML

Balises "inline" et validation "Strict"

Pages :
Comme suite logique du sujet http://forum.alsacreations.com/topic.php?fid=12&tid=414&p=1 je me pose la question suivante :
Pourquoi en XHTML Strict les éléments à l'intérieur d'un formulaire doivent être dans des balises de type bloc et qu'en XHTML Transitional ce n'est pas nécessaire ? Smiley hum

Des explications ?

<appât Laurent Denis> Smiley cligne
dl dl dl dl dl dl dl dl
</appât Laurent Denis> Smiley cligne
Modifié le 03 Feb 2005 - 20:54
Il me semble que la raison de fond est la même que pour l'élément <body> qui se comporte exactement de la même manière:
- en transitional, il peut être parent immédiat d'un élément inline, comme un lien <a>
- en strict, <body> ne contient que des éléments blocs, qui eux-même contiennent les éléments inline.

Donner à <body> ou à <form> la possibilité de contenir des éléments <inline> revient à appauvrir considérablement la structure et le sens donnée par celle-ci au document.

Transitional autorise par exemple:

<body>
<strong>Titre</strong>
 <form method="post" action="http://example.org">
<em>Abonnez-vous à notre newletter</em>
<br>
Votre adresse email : 
<input type="text" name="mail"> 
<input type="submit" value="OK">
</form>
</body>


On trouverait facilement des exemples tout à fait valides mais bien pires. Mais on voit déjà avec celui-ci que cette permissivité favorise un code très pauvre, peu accessible, peu manipulable. Rien n'indique en fait le titre du contenu, la légende du formulaire, l'étiquette du contrôle. Et pourtant, c'est valide et ça passe bien sur l'écran.

A l'inverse, en strict, l'obligation de balise le contenu de body, des formulaires, etc. oblige à préciser la structure du document, et favorise l'ajout d'éléments porteur de sens: titres, labels, fieldset, etc.

Comme dirait Karl Dubost: be strict to be cool Smiley cligne
Laurent Denis a écrit :

Donner à <body> ou à <form> la possibilité de contenir des éléments <inline> revient à appauvrir considérablement la structure et le sens donnée par celle-ci au document.


C'est très clair ! Merci ! Smiley smile
Laurent Denis a écrit :

A l'inverse, en strict, l'obligation de balise le contenu de body, des formulaires, etc. oblige à préciser la structure du document, et favorise l'ajout d'éléments porteur de sens: titres, labels, fieldset, etc.


Mises à part les balises <body> et <form>, y a t'il d'autres exemples qui résulteraient en un appauvrissement de la structure du document ? Parce qu'ici, on parle d'éléments requis en Strict et facultatifs en Transitional. Y a t'il d'autres éléments requis en Strict et non en Transitional ?
Modifié le 17 Nov 2004 - 09:37
Eléments en %flow dans les deux DTD stricte et transitionnelle:
- div
- object
- dd
- li
- fieldset
- button
- th
- td


Elément en %block en strict, mais en %flow en transitionnelle:
- body
- form
- blockquote
- noscript
- noframes (n'existe pas en strict)

Bref, outre <body> et <form>, le problème évoqué ici concerne surtout <blockquote>.
Ce qui est intéressant ici, c'est qu'on touche de manière très concrète, pour une fois, la différence qualitative entre les DTD stricte et transitionelle, et son enjeu.

Cette permissivité du transitionnelle sur le type de contenu de certains éléments est une nécessité pour qu'il puisse jouer son rôle, et notamment favoriser la création d'outils auteurs qui automatisent la correction de codes "soupe de tag" et facilitent la transition vers les normes plus signifiantes.

Mais d'un autre côté, elle revient à légitimer un code très éloigné des exigences qualitatives des normes. On comprend mieux, du coup, que les contraintes du strict ne sont pas si arbitraires qu'on pourrait parfois le penser.
Administrateur
Discussion très intéressante : on comprend mieux que ce n'est pas toujours si facile de passer de transitionnel à strict. Changer le doctype ne suffit pas, il faut aussi changer d'état d'esprit.
Alors on peut dire que le DOCTYPE Strict ne propose pas simplement une séparation du contenu et de la présentation, mais également une amélioration au niveau de la structure du document.
Stephan a écrit :
Alors on peut dire que le DOCTYPE Strict ne propose pas simplement une séparation du contenu et de la présentation, mais également une amélioration au niveau de la structure du document.


Oui, l'enjeu strict/transitional le plus évident est la séparation structure/contenu. Mais ce n'est pas le seul:
- incitation à une structure plus fouillée (ci-dessus)
- lâcher prise sur le comportement utilisateur (target)
- meilleure prise en compte de l'accessibilité et meilleure gestion des contenu (iframe)
- courbe d'apprentissage accélérée (CSS v. éléments de présentation - vocabulaire de base d'XHTML1.1)


Stephan a écrit :

<appât Laurent Denis> Smiley cligne
dl dl dl dl dl dl dl dl
</appât Laurent Denis> Smiley cligne


Bon, s'il n'y a plus d'abus provocatoires de dl, je retourne jusqu'à la fin de la semaine à la rédaction de... ma FAQ DTD, justement Smiley cligne

On en reparlera quand elle sera soumise à vos critiques !

-------> Smiley sleep
Administrateur
Au fait, vu qu'on n'y parle pas vraiment de sémantique (sens et fonction des balises), et que la discussion porte à réflexion, je déplace dans le Salon des discussions de fond.
Un truc très agaçant avec ces déplacements de sujet : l'url originale n'est plus valable, ils ne laissent pas de trace dans le forum d'origine, et il faut jouer aux devinettes pour retrouver le nouvel emplacement dans un nouveau forum.

Rappel : cool url don't change ! Ou alors, elles sont "traçables".
Raphael a écrit :
Discussion très intéressante : on comprend mieux que ce n'est pas toujours si facile de passer de transitionnel à strict. Changer le doctype ne suffit pas, il faut aussi changer d'état d'esprit.


Oui. Mais disons que faire du transitionnel à coup de balisage inline dans le body n'est pas vraiment l'idée que cherche à favoriser le transitionnel.

Et en fait, le passage de transitional à strict n'est pas si difficile, si on se souvient que transitional a pour but (entre autres), de faciliter l'automatisation de ce passage à l'aide d'outils auteurs. Ainsi le code transitionnel de mon exemple ci-dessus peut être converti très aisément en strict par Tidy.
Tiens, je relance ce sujet, qui me semble vraiment à creuser (Il y a des gens comme Stephan qui ont l'art de trouver de bonnes questions, ce qui est beaucoup plus difficile que d'apporter de bonnes réponses Smiley cligne )

Il y a un autre aspect de la différence entre strict et transitionnel, lié au degré d'incitation à produire une structure plus ou moins précise: le degré d'abstraction XHTML .

Quoi qu'est-ce ?

Voir avant tout un document passionnant : http://www.w3.org/2001/tag/doc/contentPresentation-26.html

Si on compare rapidement quelques langages de structuration de contenu, on constate rapidement que:
- certains sont extrèmement concret, comme PNG, PDF ou Flash.
- certains sont moyennement concrets, comme SVG ou X-Voice.
- certains sont à l'inverse très abstraits, comme RDF, RSS1.0, FOAF

"Concret" renvoie à une association étroite entre les éléments de structure et leur rendu sur le media visé.A l'inverse, "abstrait" renvoie à une notion de structure indifférente au rendu sur un media.

Plus le format d'un document est abstrait, et plus il est dépendant des langages tiers de présentation. Mais plus il peut être réutilisé sur des medias différents... Un fil RSS n'est que de l'information structurée, potentiellement présentable à l'aide d'un langage de présentation associé sur n'importe quel media (voir le vieux gag du fil RSS affichable sur l'écran de votre navigateur grâce à une CSS, ou encore celui d'un document FOAF affichable via XSLT ou CSS).

Ou se situent HTML4.01 et XHTML1.x dans cet éventail du plus concret au plus abstrait ?
- L'approche "historique" d'HTML est essentiellement concrète: ce langage s'est développé en tant qu'outil permettant d'afficher du contenu dans des navigateurs d'abord texte puis graphiques. D'où les <center> et autres <i>, mais aussi l'utilisation des tableaux comme outil de présentation visuelle.
- L'approche "transitional" en (X)HTML reste très concrète. Les éléments de présentation dépréciés sont maintenus. Comme expliqué ci-dessus dans mon premier message, une structure sémantiquement et hiérachiquement très vague reste possible, tout en étant parfaitement intelligible une fois affichée sur un écran.
- L'approche "stricte" devient plus abstraite, en renonçant à ces éléments de présentation obsolètes, et en incitant à un structure plus ferme, totalement inutile pour l'affichage, mais indispensable pour que le contenu soit doté de plus de sens interprétable par ailleurs.

Parvenu à ce point, une petite question : quel est l'intérêt de ce biau discours ? Peut-être simplement une approche plus solide de la fameuse "séparation du contenu/structure et de la présentation", qui me semble de plus en plus fumeuse Smiley biggrin
Et là on veut faire les choses jusqu'au bout avec le contenu via XML, la structuration des données pour l'affichage "lisible" via XSLT et la mise en forme esthétique via CSS

http://digital-web.com/articles/client_side_xslt/

Au sujet de l'abstraction de xhtml strict, je me demandais une chose, les <div> ayant un rôle de regroupement, non visuel, au final, elles ne servent à rien d'autre que d'aider à la mise en page en regroupant les élélments qui doivent l'être... <div> n'ayant aucun sens sémantique à part celui ci, sont elles obsolètes dans un objectif de totale séparation du contenu et de sa présentation ??? (pas taper, pas taper, je me pose juste une question, parceque perso, div ne me sert qu'à m'aider à mettre en forme, ça n'apporte rien au niveau du sens du balisage selon moi)
Modifié le 28 Dec 2004 - 19:07
ElMoustiko a écrit :
Et là on veut faire les choses jusqu'au bout avec le contenu via XML, la structuration des données pour l'affichage "lisible" via XSLT et la mise en forme esthétique via CSS

http://digital-web.com/articles/client_side_xslt/


J'oubliais de dire que plus un langage est abstrait, et plus il rend le contenu dépendant des capacités du client. De ce point de vue, XSLT côté client est actuellement un non-sens.

a écrit :

Au sujet de l'abstraction de xhtml strict, je me demandais une chose, les <div> ayant un rôle de regroupement, non visuel, au final, elles ne servent à rien d'autre que d'aider à la mise en page en regroupant les élélments qui doivent l'être... <div> n'ayant aucun sens sémantique à part celui ci, sont elles obsolètes dans un objectif de totale séparation du contenu et de sa présentation ??? (pas taper, pas taper, je me pose juste une question, parceque perso, div ne me sert qu'à m'aider à mettre en forme, ça n'apporte rien au niveau du sens du balisage selon moi)


Si, je vais taper. Et je retaperais jusqu'à ce que le message passe:
<div> ne sert pas uniquement à la présentation. C'est un élément structurel permettant d'enrichir la structure (X)HTML au-delà de la sémantique native du langage. Et c'est justement un élément abstrait entre tous Smiley cligne
Bah oui tu avais déjà dit ça une fois, l'autre jour, mais justement, je soulignais mon incompréhension, je ne vois pas l'utilité que peut avoir une division ... Oui ça regroupe les éléments, mais où est l'utilité si on enlève le coté graphique, c'est ça ma réelle question (peut être trop "cachée" dans mon post précédent).
Dans un blog, supprime le classique <div class="post">, et tente de transformer la source XHTML en fil RSS...
Ou tente de faire une présentation pour media "projection" sans baliser ton HTML avec des div... (voir OperaShow et le récent script d'Eric Meyer)
Ou trouve un balisage structurel approprié pour la date de mise à jour d'un document web ou un simple lien "skip to content" en tête de page (non, ce n'est pas un paragraphe).
Okay, donc il y a bien une utilitée réelle Smiley lol je n'ai juste pas eu l'occasion de m'en rendre compte Smiley cligne Merci pour les exemples !
Très intéressant comme discussion !

Vu la tournure de l'échange, avez-vous des suggestions pour modifier le titre en quelque chose de plus évocateur ?
Afin d'enrichir ce sujet, j'ai fait les essais suivants.

Exemple 1 : Valide

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<form method="" action="">
 <label></label><input id="" type="" name="" value="" />
 <label></label><input id="" type="" name="" value="" />
</form>

Exemple 2 : Non-valide

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<form method="" action="">
 <label></label><input id="" type="" name="" value="" />
 <label></label><input id="" type="" name="" value="" />
</form>

Exemple 3 : Valide

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<form method="" action="">
 <div>
  <label></label><input id="" type="" name="" value="" />
  <label></label><input id="" type="" name="" value="" />
 </div>
</form>

Exemple 4 : Valide

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<form method="" action="">
 <fieldset>
  <legend></legend>
  <label></label><input id="" type="" name="" value="" />
  <label></label><input id="" type="" name="" value="" />
 </fieldset>
</form>

Exemple 5 : Valide

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<fieldset> 
 <legend></legend>
 <form method="" action="">
  <label></label><input id="" type="" name="" value="" />
  <label></label><input id="" type="" name="" value="" />
 </form>
</fieldset>

Exemple 6 : Non-valide

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<fieldset> 
 <legend></legend>
 <form method="" action="">
  <label></label><input id="" type="" name="" value="" />
  <label></label><input id="" type="" name="" value="" />
 </form>
</fieldset>

Modifié le 29 Dec 2004 - 04:35
Pages :
Sujet clos
Aller à