5568 sujets

Sémantique web et HTML

Pages :
Bonjour a tous,
j'ai lu l'article sur l'arrivé de html 5, j'ai vu les nouvelles balises <header> <nav> <footer> et je me posais une question; est-ce que le fait d'utiliser ces balises imposent leur emplacement sur une page web ou
servent-elles uniquement a definir un contenu et a l'identifié comme tel plus facilement, mais pourra-t-on toujours les placer comme on veut ou on veut? (je pense plus, surtout, a la balise <nav> que l'on trouve pas forcement a gauche sous <header> comme dans le dessin sur l'article)

Merci d'avance pour vos reponses
Bonjour,

Comme pour tout élément HTML actuel, ils seront parfaitement stylable à souhaite (et donc positionable). De ce que j'ai compris on peut les assimiler à des div très particulières.
Cela aura surtout une utilité sémantique. On peux espérer une bonne utilisation des lecteurs d'écrans de ces derniers.
Enfait on peut juste mettre la <div id="entete> dans la balise <header> (par exemple) ou il faut remplacer carement la <div id="entete> par <header> avec un "id" pour la mise en page?

Et derniére question, est-ce qu'elles font buggé les versions anterieur au navigateur d'aujourd'hui ou elles ne sont tout simplement pas pris en compte et donc commencer a les utilisées?

Si ça peut apporter un point de plus a la standardisation ET (surtout) a l'accessibilité je m'y mets dés ce soir en rentrant du boulot. Smiley cligne
Modifié par shinje (03 Aug 2009 - 16:39)
shinje a écrit :
Enfait on peut juste mettre la <div id="entete> dans la balise <header> (par exemple)

Pourquoi pas, ou dans l'autre sens; mais c'est un peu lourd:
<div id="entete">
  <header>
    Contenu.
  </header>
</div><!--#entete-->

shinje a écrit :
ou il faut remplacer carement la <div id="entete> par <header> avec un "id" pour la mise en page?

C'est possible aussi, et c'est plus léger (on n'imbrique pas inutilement un conteneur dans un autre):
<header id="entete">
  Contenu.
</header>
(À noter que l'identifiant "entete" n'est pas forcément utile si on utilise un élément très identifiable comme HEADER.)

shinje a écrit :
est-ce qu'elles font buggé les versions anterieur au navigateur d'aujourd'hui

Ces éléments passent bien dans tous les navigateur récents, sauf Internet Explorer. Firefox, Safari et les autres permettent de styler un élément non reconnu comme si c'était un DIV ou un SPAN (hmm, plutôt comme un SPAN, donc il faudra peut-être utiliser du display:block si c'est le type de rendu qu'on attend). Dans IE, ces éléments ne font pas buguer le navigateur, mais les styles CSS qu'on veut leur appliquer ne sont pas reconnus. Il se peut aussi qu'on ait du mal à y accéder en JavaScript. La solution consiste à utiliser un peu de JavaScript pour forcer Internet Explorer à réaliser que certains éléments «existent»:
http://remysharp.com/2009/01/07/html5-enabling-script/

Une autre solution consiste à utiliser ces conteneurs pour leur valeur sémantique, et à utiliser des DIV pour la mise en forme. On retrouve alors le code un peu lourd que je donne comme premier exemple ci-dessus.

shinje a écrit :
Si ça peut apporter un point de plus a la standardisation ET (surtout) a l'accessibilité je m'y mets dés ce soir en rentrant du boulot. Smiley cligne

Il n'y a pas d'urgence. Si tu t'y mets ce soir, ce sera pour le plaisir, pour commencer à t'informer, et il est entendu que tu passeras les prochains mois, voire les prochaines années, à suivre de près l'évolution de cette norme. Bien sûr tu n'hésiteras pas à lire les brouillons de la spécification publiés sur le site du W3C, en te familiarisant avec leur formalisme un peu particulier.

Sinon, tu peux continuer à faire du HTML 4 (ou du XHTML 1.0 servi comme du HTML). C'est très bien, et ça permet déjà de faire des sites standard et accessibles. Plus que HTML 5, qui est un standard encore instable. Smiley cligne

La première version un peu stable de HTML 5 sera publiée cet automne. La spécification devrait être finalisée, en tenant compte d'une phase de commentaires et d'améliorations, en 2012. En 2012, on aura peut-être la chance de ne plus avoir à se soucier d'IE6, mais il faudra encore se soucier d'IE7 et IE8, donc aucun besoin de se précipiter.
Merci beaucoup Florent V. pour ton post bien detaillé, il est vrai que je me precipite un peu mais l'idée de pouvoir mieux identifier un contenu, j'y trouvais un progret surtout en matiére d'accessibilité.
Je pense opter pour la 1er solution garder les <div> et rajouter les nouvelles balises HTML 5
ça me semble la solution qui passera sur tous les navigateurs.

En tous cas l'idée de ces balises on l'air bonne, pour l'heure je garde toujours le XHTML ça va de soit, mais je pense qu'il faudra suivre de prés les evolutions de HTML 5.

Merci a tous pour vos réponses et merci a alsacréation pour leur travail d'information.
Salut,
shinje a écrit :
Je pense opter pour la 1er solution garder les <div> et rajouter les nouvelles balises HTML 5
Plutôt que de doubler tes balises, tu pourrais simplement utiliser des div et les "classer" avec le nom de la balise HTML5 :
<div class="header">
<div class="nav">
<div class="article">
.header {...}
.nav {...}
.article {...}
Le jour où tu voudras basculer en html5, tu auras très peu de changement à faire : renommer tes div et supprimer le point devant les sélecteurs dans ta CSS :

<header>
<nav>
<article>
header {...}
nav {...}
article {...}
Il est bien évidament logique qu'un robot favorise la lecture de la balise header en premier lieu après les autres suivent footer.
ça sera une bonne manière de coder ton html 5 et basta ! maintenant si tu veux faire un footer en haut ça n'engage que toi ! tout comme le faite d'avoir un h1 titre de page ou un alt ....
a écrit :
Ces éléments passent bien dans tous les navigateur récents, sauf Internet Explorer. Firefox, Safari et les autres permettent de styler un élément non reconnu comme si c'était un DIV ou un SPAN (hmm, plutôt comme un SPAN, donc il faudra peut-être utiliser du display:block si c'est le type de rendu qu'on attend).

Bonjour,

En allant dans cet logique on peut donc créer des nouveaux éléments, au hasard de mon imagination l'élément <note>, par exemple (je ne crois pas qu'il existe). Ma question est, est-ce autorisé ? En html5 version html ? En html5 version xml ? J'ai fait de nombreuses recherche depuis hier soir, je ne trouve pas de réponse, si ce n'est un non sans plus d'explication sur un forum.

J'ai bien compris que ça peut poser des problème de compatibilité, mais c'est dans un but d'apprentissage et non pour un site qui doit être visible par tous.

En m'excusant d'avance si cette question semble absurde, j'apprends la programmation depuis un an sur le tas, par nécessite à la base, par plaisir aujourd'hui, mais je n'ai pas toujours la compétence pour comprendre certaines subtilités.


Autre question, si ça n'a pas de rapport avec le sujet oubliez là, j'en suis pas encore là. L'attribut alt était, si je ne me trompe pas, "obligatoire", pour des raisons d'accessibilités dans les navigateurs ne gérant pas les images ou les non voyant. Sur différent exemple concernant l'html5, il n'apparait pas. Est ce pour simplifié les exemples et facilité la lecture que les auteurs ne l'ont pas mit ou cet attribut a été supprimé ?

Merci
pascal77 a écrit :
Ma question est, est-ce autorisé ? En html5 version html ? En html5 version xml ?

Non, ce n'est pas autorisé en HTML 5, et pas en XHTML5. Ce que permet XHTML5 par contre, c'est d'intégrer d'autres formats XML, en le déclarant clairement. Et comme tu peux créer ton propre format XML... on peut dire que tu peux «inventer» tes éléments en XHTML (1 ou 5, ça ne change pas grand chose sur ce point). Cependant il ne s'agit pas de faire tout ce qui te passe par la tête, il y a des règles à respecter. Enfin, il faut rappeler que ce mécanisme d'extensibilité ne vaut que pour les documents servis en "application/xhtml+xml"... donc pas pour les pages web compatibles avec Internet Explorer.

Je te laisse te renseigner sur l'extensibilité en XHTML, et la notion d'espace de noms (namespace).

pascal77 a écrit :
J'ai bien compris que ça peut poser des problème de compatibilité, mais c'est dans un but d'apprentissage et non pour un site qui doit être visible par tous.

Je ne voie pas trop où tu veux en venir. Tu veux créer tes propres éléments utilisant la syntaxe HTML, pour les insérer dans des documents HTML, «pour voir»?

HTML est un standard, qui définit un ensemble d'éléments et (dans une certaine mesure) leur rôle et leur restitution par les agents utilisateur (les outils qui lisent les documents HTML). Si tu crées tes propres éléments, les navigateurs ne sauront tout simplement pas quoi en faire. Dans le meilleur des cas, il vont opter pour un comportement «neutre» que l'on peut décrire ainsi:
- l'élément inconnu sera traité comme un élément conteneur neutre tel qu'un DIV;
- les attributs standards seront appliqués si possible;
- les attributs non standard seront ignorés, ou bien le navigateur rendra leur valeur disponible via le DOM (donc possibilité de récupérer en JavaScript la valeur d'un attribut).

Voilà pour le meilleur des cas. Le pire des cas (hors plantage du navigateur), ce serait que le navigateur ignore totalement l'élément et son contenu.

Dans la pratique, la plupart des navigateurs appliquent plus ou moins bien le comportement neutre que je décris ci-dessus. Internet Explorer pose un petit problème dont on a déjà parlé ci-dessus.

Il reste que les éléments que tu peux inventer, en plus de rendre ta page invalide (si tu t'en soucies), et de risquer de provoquer des erreurs dans les navigateurs, ne serviront strictement à rien. Ils ne seront pas porteurs de fonctionnalités spécifiques, et ils n'auront pas de valeur sémantique particulière qui pourrait être reconnue par un outil d'indexation par exemple.

pascal77 a écrit :
L'attribut alt était, si je ne me trompe pas, "obligatoire", pour des raisons d'accessibilités dans les navigateurs ne gérant pas les images ou les non voyant. Sur différent exemple concernant l'html5, il n'apparait pas. Est ce pour simplifié les exemples et facilité la lecture que les auteurs ne l'ont pas mit ou cet attribut a été supprimé ?

L'attribut existe toujours et il est recommandé. Il y a actuellement un débat pour savoir s'il faut le garder obligatoire (ce qui oblige à écrire alt="" lorsque un texte alternatif n'est pas pertinent) ou pas. Les rédacteurs de HTML sont plutôt pour le «ou pas». La WAI est plutôt pour le garder obligatoire.
a écrit :
Tu veux créer tes propres éléments utilisant la syntaxe HTML, pour les insérer dans des documents HTML, «pour voir»?

En fait je connaissais le problème de IE et sûrement d'autres navigateurs exotiques. donc si ce n'était qu'une incompatibilité provisoire de la part d'IE ça ne me posait pas de problème car en effet pour l'instant je fais joujou avec les prochaines normes et d'ici que j'intègre ça dans un site destiné a un public plus large, microsoft aura sûrement fait quelques efforts. Voyant que des navigateurs acceptait cela je me posais la question.

Oui, bien sûre je me soucie de la validité, sinon je n'aurais pas posé la question, j'aurais foncé voyant que ça marchait sur 3 des 4 navigateurs que j'avais testé et sachant que IE ne respecte pas encore les normes. D'ailleurs j'avais fait validé mon code et ils me mettait bien l'erreur mais comme la validateur html5 n'est pas en phase finale je préférais vos avis.

L'intérêt que j'y voyais était de mieux s'y retrouver par rapport à la balise span et certains bloc pour leur donner un nom plus juste/détaillé par rapport à leur contenu. Le nom des id et class peuvent faire ça mais je trouvais ça plus clair ainsi, et comme je redéfinit déjà pas mal de paramètres, je me disais que c'était pas plus chiant dire dire que cet élément est un bloc avec tel marge et que l'interligne devra faire tant, que de devoir lui dire de retirer les marges, la taille de la police et tout un tas d'autres choses qu'il m'a prédéfinis.

En tout cas merci pour ta réponse clair et détaillé. Je ne vais pas me lancer dans le xml que je ne connais pas suffisamment et me contenter d'utiliser la syntaxe actuelle.
Apparemment, un <header> dans une page html5 n'est pas stylé entièrement par les propriétés d'une règle "header" dans la feuille de style liée, "border: solid" ou d'autres fonctionnent, "width" ni "height" ne suivent pas sous Firefox, pour IE6 : seul "color" fonctionne.
Est-ce que ça a trait à CSS 2 ou 3?
(en tout cas, on va attendre)
Modifié par JLS (15 Sep 2009 - 09:51)
shinje a écrit :
Merci a tous pour vos réponses et merci a alsacréation pour leur travail d'information.

Oulaaaah malheureux !!! AlsacréationS !!! Des têtes sont tombées pour moins que ça ! Smiley lol
JLS a écrit :
Apparemment, un <header> dans une page html5 n'est pas stylé entièrement par les propriétés d'une règle "header" dans la feuille de style liée

En fait ça marche, pour peu que le support du navigateur pour ces nouveaux éléments (ou à défaut sa tolérance pour des éléments inconnus) soit correct.

Les navigateurs posant problème sont Firefox 2 (corrigé à partir de la version 3), et Internet Explorer (toutes versions actuelles). Pour IE, il existe un correctif qui aide IE à «se rendre compte» que ces éléments existent. C'est très simple et ne pose pas de problème de performance, mais ça repose sur JavaScript donc sans JS... pas de styles CSS dans IE pour ces éléments.

JLS a écrit :
"width" ni "height" ne suivent pas sous Firefox

Syntaxe: on dit en français «width ET height ne suivent pas» ou «NI width Ni height ne suivent». Smiley cligne
Technique: tu as utilisé un display:block qui va bien? Si le navigateur n'a pas connaissance de cet élément, il ne sait pas non plus qu'il doit l'afficher comme un bloc. Et donc largeur et hauteur ne prennent pas.

Voir à la fin de la partie «bonus» dans l'article suivant:
http://www.alsacreations.com/astuce/lire/654-feuille-de-styles-de-base.html

JLS a écrit :
(en tout cas, on va attendre)

Voilà une sage résolution. Smiley smile
Non pas que HTML5 soit inutilisable aujourd'hui. Mais si on n'a pas suivi le détail des questions de compatibilité et d'implémentation, on risque de faire des erreurs.
Modifié par Florent V. (15 Sep 2009 - 12:56)
Bonjour,

Pour l'usage de html5 n'y a t-il pas un probleme avec le doctype , qui ferait logiquement passer en "mode quirk" les navigateurs qui ne le reconnaisse pas comme un "standard" ?.

GC
gc-nomade a écrit :
Pour l'usage de html5 n'y a t-il pas un probleme avec le doctype

Non. Apparemment les développeurs des différents navigateurs ont fait preuve d'un peu de jugeote et utilisent le raisonnement suivant:
1. S'il y a un Doctype un peu particulier (HTML 4 Transitional sans URL de la DTD...), mode Quirks.
2. Autrement, s'il y a un Doctype quel qu'il soit, mode Standard.
3. Autrement, mode Quirks.

Concrètement, s'il avait fallu un Doctype plus complexe pour éviter le mode Quirks, alors HTML5 aurait proposé un Doctype complexe qui satisfasse les principaux navigateurs existants.

On peut rappeler en passant que le Doctype est complètement facultatif en HTML5. Il sert uniquement à forcer le bon mode de rendu.
"Florent V." a écrit :
Technique: tu as utilisé un display:block qui va bien? Si le navigateur n'a pas connaissance de cet élément, il ne sait pas non plus qu'il doit l'afficher comme un bloc. Et donc largeur et hauteur ne prennent pas.

C'était un <header>! J'ai fait comme si c'était un bloc par défaut, <div> ou autre, je n'ai pas donc pas précisé "display:block", or, dans html5, les notions de "bloc" ou "en ligne" n'ont pas lieu d'être, donc, si on veut utiliser celles-ci pour le style, il faut dire par css au navigateur que <header> ou <div> ou autre est soit un bloc soit un "en ligne", par "display: block ou inline"! Bon sang mais c'est bien sûr! Tu as raison que je sois maudit.
Ca me fait dire que la propriété "display" sera obligatoire en html5, puisqu'il n'y a plus de valeurs par défaut?! Mais je sais pas si j'ai raison de déduire ça... Smiley ohwell
"Florent V." a écrit :
Syntaxe: on dit en français «width ET height ne suivent pas» ou «NI width Ni height ne suivent».

Elle est bonne! Tu viens chercher une leçon de html et css et tu repars avec une leçon de français en plus! C'est le service plus, ici.
Smiley smile
JLS a écrit :
Ca me fait dire que la propriété "display" sera obligatoire en html5, puisqu'il n'y a plus de valeurs par défaut?

Il n'y a pas de valeurs par défaut non plus en HTML4. Ne serait-ce que parce que HTML4 et CSS sont des spécifications certes liées, mais différentes, et que HTML4 ne définit pas de styles par défaut des différents éléments.

Pour être précis, il existe dans CSS 2.1 un appendice non pas normatif mais informatif (donc on peut implémenter la norme sans le respecter pour autant) qui donne un exemple de feuille de styles par défaut pour HTML 4.01: http://www.w3.org/TR/CSS2/sample.html
(Dans CSS 2, cet appendice était nommé «sample stylesheet» plutôt que «default stylesheet».) En pratique, les styles utilisés par les navigateurs sont en partie différents.

Il n'y a pas de document de ce genre, dans quelque norme CSS que ce soit, pour HTML5. C'est logique, CSS 3 étant en préparation et HTML5 de même. De même, il n'est pas inattendu que les navigateurs n'aient pas encore de styles par défaut pour la plupart des éléments HTML5, vu leur caractère récent.

Pour finir: CSS 2.1 définit la propriété display. Par conséquent, et en application de CSS 2.1, chaque élément de chaque page a une propriété display, avec pour valeur:
- soit une valeur précisée dans la page HTML ou une feuille de styles ou via JavaScript;
- à défaut, la valeur par défaut définie par le navigateur (si elle existe);
- à défaut, la valeur par défaut qui est... "inline".

Il est marqué ici en noir sur blanc que la valeur par défaut de la propriété "display" est "inline":
http://www.w3.org/TR/CSS2/visuren.html#propdef-display

HTML5 ne change strictement rien à cela. Ce que tu observes n'est pas un comportement de HTML5, mais un comportement de CSS 2.1.
1/Si dans une page html vierge, je saisis 4 balises <div> à la suite en y incluant le texte "div" dans chacune, puis 4 balises <span> en y incluant le texte "span", afin de pouvoir les situer visuellement dans un navigateur graphique, les 4 textes "div" s'alignent verticalement, les 4 textes "span" horizontalement dans FF et dans IE, Lynx fait de même.
Il n'y a pas le moindre appel de css de mon fait, là-dedans (encore moins de js!), recopier le code html serait superflu étant donné sa simplicité. J'ai pris une dtd "html transitionnel" à tout hasard : un <span> non contenu par autre chose que <body> pourrait perturber peut-être mon test.
Pour "décider" de l'alignement soit vertical, soit horizontal, je n'ai ni css ni js ni style html, il ne me reste donc que l'application de style par défaut du navigateur.
Si je désactive les styles par défaut du navigateur par le moyen de l'extension Webdevelopper, le seul changement de comportement des alignements d'éléments html, est qu'un espacement est supprimé entre eux : c'est moins aéré, quoi!
Mais les alignements, vertical pour les <div> et horizontal pour les <span> demeurent, semblant indiquer un comportement (un style? pas css, en tout cas) par défaut qui me paraît ne relever que de Html, puisque j'ai éliminé tout le reste (ou pas?).
Mais je suis d'accord qu'il n'y a pas de valeur par défaut de "display" en html, puisque "display" est du css.
2/Je n'ai pas réussi à absorber intellectuellement ton développement sur css Smiley decu . J'y reviendrai.
3/ Le lien cité "Une feuille de style de base" est très instructif(bravo pour le bonus)!.
(entre autres parce que j'ai découvert qu'il était possible d'appliquer une propriété css à un attribut, et lui seul). Smiley smile
<edit 21/09 19h56>J'ai repris cette phrase qui f... en l'air tout mon raisonnement, corrigé ci-dessus : "Mais les alignements, vertical pour les <div> et horizontal pour les <span> demeurent, semblant indiquer un comportement (un style? pas css, en tout cas) par défaut qui me paraît ne relever que de Html, puisque j'ai éliminé tout le reste (ou pas?)."</edit>
Modifié par JLS (21 Sep 2009 - 19:58)
Au fait il me reste une question. Le doctype de HTMl5 est :
<!DOCTYPE HTML>
Mais quel est le doctype de XHTML5 ?
Ou autrement dit, quel est le doctype du HTML5 en syntaxe XML ?
Si c'est le même doctype, comment peut-on différencier les deux ? IL doit sûrement y avoir un autre moyen de différenciation que le simple Content-Type (à ce sujet, application/xhtml+xml n'est toujours pas supporté par IE7 et 8)
Modifié par QuentinC (21 Sep 2009 - 08:22)
Pages :