5568 sujets

Sémantique web et HTML

HTML5 balise <header> <nav> <footer>...?

Pages :
(reprise du message précédent)

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)
Je crois que c'est le même. D'ailleurs html5 accepte la syntaxe xml-isée de xhtml5. Amha, il est préférable d'xml-isé la syntaxe, c'est plus propre et le jour où tous les navigateurs comprendront application/xhtml+xml il y aura peu de modifications à apporter sur les sites.
Modifié par Patidou (21 Sep 2009 - 11:03)
Patidou a écrit :
Je crois que c'est le même.

Non. Il n'y a PAS de Doctype en XHTML5. C'est juste totalement inutile, (X)HTML5 n'étant pas défini par une DTD. La seule raison pour laquelle il y a un Doctype en HTML5, c'est pour que les navigateurs ne passent pas en mode Quirks.

Pour être clair:
- HTML5 est une norme qui définit des éléments, attributs, les fonctionnalités et les interfaces DOM associées.
- Cette norme définit ensuite deux syntaxes: une syntaxe HTML, et une syntaxe XHTML.
- Les documents HTML5 utilisant la syntaxe HTML doivent être servis en text/html (pas d'exception). La syntaxe HTML admet un marqueur nommé «Doctype» qui doit être placé en tout début de document; ce marqueur est facultatif, il existe uniquement pour des questions de compatibilité (éviter que les pages soient affichées par les navigateurs en mode Quirks).
- Les documents HTML5 utilisant la syntaxe XHTML doivent être servis en application/xhtml+xml (pas d'exception). Les Doctypes sont facultatifs en XML (ce n'est qu'un mécanisme de description de format parmi d'autres). Si on inclut un Doctype dans un document XML, il est censé référencer une DTD. Or il n' Il n'existe pas de DTD pour HTML5. Il ne peut donc pas y avoir de Doctype en HTML5 avec syntaxe XHTML.

Note: je ne suis pas 100% sûr de cette dernière affirmation. Le brouillon actuel de HTML5 est plutôt ambigu sur l'utilisation d'un Doctype en syntaxe XHTML.

Patidou a écrit :
et le jour où tous les navigateurs comprendront application/xhtml+xml il y aura peu de modifications à apporter sur les sites.

Pour peu que l'on ait un intérêt réel à passer un site en application/xhtml+xml. C'est loin d'être évident. Smiley cligne
Modifié par Florent V. (21 Sep 2009 - 14:24)
a écrit :
Pour peu que l'on ait un intérêt réel à passer un site en application/xhtml+xml. C'est loin d'être évident.

En effet, c'est loin d'être évident : tu peux citer quelques intérêts qu'on peut avoir à passer à application/xhtml+xml ?
Personnellement, je n'en vois pas vraiment, y compris si on ne tient pas compte d'IE, bien que je suis passé depuis bien longtemps à XHTML 1.0 strict, que je passerai sans doute ensuite en HTML5 en syntaxe XML, et que je suis depuis longtemps convaincu que la structure d'un document doit être valide. Concrètement, ça change quoi ? Rien...
QuentinC a écrit :
tu peux citer quelques intérêts qu'on peut avoir à passer à application/xhtml+xml ?

Intégrer d'autres formats XML dans un document. Comme par exemple MathML ou SVG.
C'est utile également quand tu produits un contenu HTML qui doit être servi en tant que format XML en vue d'être utilisé par un outil tiers ne gérant pas le HTML.

Si le but est d'utiliser uniquement des éléments de HTML4 et d'afficher les pages dans un navigateur web (comme 99,9% des utilisations concrètes de HTML), faire du XHTML 1.0 est inutile.

QuentinC a écrit :
je passerai sans doute ensuite en HTML5 en syntaxe XML

Faisant ainsi une croix sur Internet Explorer 6, 7 et 8 (à voir pour le 9).

QuentinC a écrit :
et que je suis depuis longtemps convaincu que la structure d'un document doit être valide

Tu peux faire du HTML 4.01 valide, et rigoureux. Même chose en HTML5 (syntaxe HTML).
Florent V. a écrit :

C'est utile également quand tu produits un contenu HTML qui doit être servi en tant que format XML en vue d'être utilisé par un outil tiers ne gérant pas le HTML.

Bof, tu peux déjà te servir d'un parseur XML même quand c'est servi en text/html, pour autant que le document soit syntaxiquement valide XML... C'est pas rigoureusement correct mais ça marche.

a écrit :
Si le but est d'utiliser uniquement des éléments de HTML4 et d'afficher les pages dans un navigateur web (comme 99,9% des utilisations concrètes de HTML), faire du XHTML 1.0 est inutile.

Donc autrement dit 99,9% du temps, XHTML 1.0 ne sert à rien. Tu viens de casser un mythe.


a écrit :
Faisant ainsi une croix sur Internet Explorer 6, 7 et 8 (à voir pour le 9).

Rien ne m'empêche de continuer à délivrer en text/html. De toute façon pour IE c'est de la soupe, alors il s'en fout.
Bon, du coup ça interdit d'intégrer d'autres formats XML comme SVG ou MathML.... mais si on ne les utilise pas c'est pas grave. Au fait, est-ce qu'il existe un navigateur qui sait déjà le supporter, ça ?

a écrit :
Tu peux faire du HTML 4.01 valide, et rigoureux. Même chose en HTML5 (syntaxe HTML).

Oui, ça je savais. Mais ça peut être utile d'avoir un document à la structure syntaxiquement valide XML, on ne sait jamais. Et puis dans la tête, on se fait une meilleure représentation du DOM si on ferme strictement toutes les balises ouvertes.
QuentinC a écrit :
Bof, tu peux déjà te servir d'un parseur XML même quand c'est servi en text/html, pour autant que le document soit syntaxiquement valide XML... C'est pas rigoureusement correct mais ça marche.

Ben oui, mais ta question était, indirectement, «à quoi ça sert de faire du HTML en XML»? Je rappelle juste une utilisation actuelle (même si pas très courante): produire un document XHTML bien formé destiné à un outil tiers et pas aux navigateurs. Je n'ai pas dit que ce document devait être le même que celui envoyé aux navigateurs. Smiley cligne

QuentinC a écrit :
Donc autrement dit 99,9% du temps, XHTML 1.0 ne sert à rien.

Ah mais parfaitement. Et le mythe a été cassé il y a belle lurette. Un des principaux adversaires de ce mythe était d'ailleurs Ian Hickson, éditeur de HTML5.

Mais il faut remettre les choses dans leur contexte. On a poussé à l'utilisation de XHTML (pas tellement moi, je suis arrivé après la bataille et j'ai relayé la «bonne pratique» que j'avais apprise) pour les raisons suivantes:

1. Parce qu'on pensait que le XML était le futur, que HTML s'arrêterait à la version 4, et que on passerait à XHTML 2 en passant par une phase de transition avec XHTML 1. Le but était donc de faire des documents XHTML 1.0 servis en text/html, mais qui seraient bien formés et qui pourraient à l'avenir être servis en application/xhtml+xml dans un site en XHTML 2.

2. Parce que la rigueur imposée par la validation XHTML (à l'inverse des largesses de la validation HTML 4) était un formidable outil pédagogique pour sortir des années de soupe de balise. La rupture entre HTML 4 et XHTML 1 était peut-être artificielle, mais elle était nécessaire pour changer les pratiques.

On a donc en #1 une vision prometteuse mais qui s'est progressivement avérée erronée; et en #2 une stratégie pragmatique qui a eu des effets très positive sur la mise en place de bonnes pratiques de codage. Le prix à payer de cette stratégie, c'est une certaine confusion maintenant que l'avenir semble être de passer du XHTML 1 à HTML5.

QuentinC a écrit :
Au fait, est-ce qu'il existe un navigateur qui sait déjà le supporter, ça ?

MathML: Firefox (Gecko) et Opera en natif, Internet Explorer via un plugin.
SVG: Firefox (Gecko), Safari/Chrome (Webkit) et Opera en natif. Le support est partiel dans les trois cas, SVG étant une spécification assez importante divisée en plusieurs niveaux (tiny, basic et full). Les navigateurs implémentent donc progressivement, niveau par niveau. Quant à Internet Explorer, pas de support natif; il y avait des plugins, dont un plugin d'Adobe (avant qu'ils ne rachètent Macromedia et donc la technologie propriétaire concurrente Flash), mais ils ne sont plus maintenus pour la plupart.
JLS a écrit :
xhtml5 n'existe pas encore, me semble-t'il...

Ça dépend de ce que tu appelles «exister». Si tu considères qu'HTML5 n'existe pas car la spécification a le statut de brouillon de travail pour le W3C (Working Draft), d'accord. Autrement, HTML5 existe, et HTML5 définit deux syntaxes:
- une syntaxe HTML, nommée «HTML5»;
- une syntaxe XHTML, nommée «XHTML5».

Donc je dirais que si, XHTML5 existe. Smiley cligne

(D'ailleurs on peut faire du XHTML5 aujourd'hui, si on le souhaite.)
Modifié par Florent V. (21 Sep 2009 - 20:09)
Florent : donc si on résume, à l'avenir, tu conseilleras de faire du HTML et non plus du XML.
Bon, j'avoue que la non obligation de fermer les <li> et les <p> peut être pratique aussi, ça simplifie un peu le codage des BBCodes, wikicode et autres markdown, sans parler des éditeurs WYSIWYG (surtout IE). Donc effectivement ça a ses avantages, surtout dans les applications complexes.

Peut-on néanmoins parler de rigueur de codage ? Ne risque-t-on pas de revenir à une soupe de balises comme autrefois ?
a écrit :
JLS a écrit :
xhtml5 n'existe pas encore, me semble-t'il...

Je croyais l'avoir supprimé après vérif, celui-là... Smiley decu

Florent V., je ne sais pas si tu as vu mon développement furieux et maniaque sur l'hypothèse d'un style par défaut au niveau de html (en fait, je ne sais pas très bien de quoi il s'agit) :
http://forum.alsacreations.com/topic-2-43362-1-HTML5-balise-ltheadergt-ltnavgt-ltfootergt.html#p311926
Bref : sans css ou style par défaut du navigateur, les blocs s'alignent verticalement, et les en-ligne horizontalement, c'est pas un style (ou un comportement) par défaut de html, contrairement à ce que tu établissais ?
"Florent V." a écrit :
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.


"QuentinC" a écrit :
Bon, j'avoue que la non obligation de fermer les <li> et les <p> peut être pratique aussi

Je n'aurais pas l'idée de ne pas fermer mes balises, même si c'est sans conséquence sur le rendu, c'est trop utile pour s'y retrouver dans le code...
Modifié par JLS (22 Sep 2009 - 18:12)
QuentinC a écrit :
Florent : donc si on résume, à l'avenir, tu conseilleras de faire du HTML et non plus du XML.

Concrètement, aujourd'hui, personne ne fait des pages web en XML. Donc à l'avenir je conseillerai de continuer à faire du HTML, sauf si le HTML tombe en désuétude (ça n'a pas l'air parti pour). La continuation logique du XHTML 1.0 servi en text/html, ce sera HTML5, pas XHTML5.

JLS a écrit :
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!

Je ne sais pas ce que fait cette option et à quoi elle correspond. N'ayant pas développé cette extension moi-même, je ne peux pas garantir que ton test est fiable et permet d'arriver à une conclusion quelle qu'elle soit.

JLS a écrit :
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?).

Ou pas. Je soupçonne cette fonctionnalité de ne pas désactiver tous les styles par défaut du navigateur, que ce soit volontaire ou non (bug).

JLS a écrit :
(entre autres parce que j'ai découvert qu'il était possible d'appliquer une propriété css à un attribut, et lui seul)

Non. On peut attribuer un style CSS à un élément ou à un ensemble d'éléments, en le ou les sélectionnant en fonction de la présence d'un attribut et de la valeur de cet attribut.

Tu peux voir dans la spécification CSS 2.1 le chapitre sur les sélecteurs. Ça te fera une découverte plus rapide et plus fiable que tes speculations. Smiley cligne
http://www.w3.org/TR/CSS2/selector.html

Autre bout d'information qui peut t'intéresser: certains navigateurs ont des styles par défaut lisibles par tous, car il s'agit de feuilles de styles CSS installées avec le navigateur et chargées automatiquement pour les pages HTML. On peut ainsi consulter les styles par défaut de Firefox en tapant resource://gre/res/html.css et resource://gre/res/forms.css dans la barre d'adresse (depuis Firefox uniquement).
Modifié par Florent V. (22 Sep 2009 - 22:38)
Florent V" a écrit :
Je ne sais pas ce que fait cette option et à quoi elle correspond. N'ayant pas développé cette extension moi-même, je ne peux pas garantir que ton test est fiable et permet d'arriver à une conclusion quelle qu'elle soit.

Ca tombe bien, moi non plus je ne sais pas : je pose des questions. Smiley cligne
Toujours à propos de Webdevelopper :
Florent V" a écrit :
Ou pas. Je soupçonne cette fonctionnalité de ne pas désactiver tous les styles par défaut du navigateur, que ce soit volontaire ou non (bug).

c'est bien possible!
a écrit :
JLS a écrit :
(entre autres parce que j'ai découvert qu'il était possible d'appliquer une propriété css à un attribut, et lui seul)
Florent V a écrit :
Non. On peut attribuer un style CSS à un élément ou à un ensemble d'éléments, en le ou les sélectionnant en fonction de la présence d'un attribut et de la valeur de cet attribut.
Tu peux voir dans la spécification CSS 2.1 le chapitre sur les sélecteurs. Ça te fera une découverte plus rapide et plus fiable que tes speculations. cligne

Le mot "spéculation" n'a aucune connotation péjorative, bien sûr.

Je me basais sur un extrait de ce document, par ailleurs excellent :
a écrit :
/* Met en évidence les abréviations (ayant un attribut title) */
abbr Smiley title {
border-bottom: 1px dotted;
cursor: help;
}

(il y a des crochets autour de "title" qui restent invisibles, je croyais que c'était ça qui attribuait le style sur l'attribut précisément...)
(source:feuille de style de base)

J'avais déduit à partir de l'affichage dans le navigateur que seul l'attribut "title" était stylé. Bordure et style de bordure n'apparaissent qu'à "l'intention" du contenu de "title", et pas de l'élément <abbr> lui-même, apparemment grâce aux crochets ([]). Je voulais forcément tester ça de plus près sur mon site.
Merci infiniment de ta patience et de ta science, et bonne journée.
Modifié par JLS (23 Sep 2009 - 16:38)
QuentinC a écrit :

Mais quel est le doctype de XHTML5 ?
Ou autrement dit, quel est le doctype du HTML5 en syntaxe XML ?


C'est du XML pur... pas de doctype
http://www.w3.org/TR/html5-diff/#syntax (en anglais)

<edit>oups pardon... déjà répondu Smiley smile ... mais j'ai une excuse!! la liste déroulante qui indique le nombre de pages du fil prétend qu'il n'y en a qu'une seule!! Smiley smile </edit>


Florent V. a écrit :

Concrètement, aujourd'hui, personne ne fait des pages web en XML. Donc à l'avenir je conseillerai de continuer à faire du HTML, sauf si le HTML tombe en désuétude (ça n'a pas l'air parti pour). La continuation logique du XHTML 1.0 servi en text/html, ce sera HTML5, pas XHTML5.


D'ailleurs... en étant un peu prudent et en se limitant aux balise HTML4 "normales" rien n'empêche de se mettre déjà a utiliser HTML5. Ne serais-ce que pour:
- Ne pas avoir à écrire un doctype de 2 lignes!
- Pouvoir utiliser les attributs data-* !!! un vrai plaisir pour passer des données à javascript

(d'ailleurs, allez voir le source de google.com Smiley smile )
Modifié par Nathan- (20 Oct 2009 - 17:21)
Pour ma part, j'ai décidé d'adopter les attributs étendus pour les formulaires. C'est hyper pratique pour faire un script de vérification non intrusif et automatique. J'ai aussi adopté les attributs data, c'est bien utile des fois, et ça marche partout à condition d'utiliser get/setAttribute uniquement. Ca ne passe évidemment pas la validation W3C mais qu'importe, du moment que c'est réfléchi et qu'on assume.
Au fait, un input avec un type inconnu sera par défaut considéré comme un type text, et ce, avec n'importe quel navigateur actuel, y compris IE6.

En ce qui concerne les éléments structurels, j'ai décidé de faire du pseudo HTML5. En attendant que le support de <header>, <nav>, <footer> et <article> soit correct, j'utilise des div avec les id ou class correspondants : <div id="header"> ou <div class="article">. Le jour où l'avènement de HTML5 sera effectif, un simple rechercher-remplacer suffira.
QuentinC a écrit :
...Ca ne passe évidemment pas la validation W3C...

même en mettant le doctype HTML5 ???
J'ai pas essayé, mais je ne crois pas que le validator puisse déjà vérifier la validité des pages HTML5.
QuentinC a écrit :
J'ai pas essayé, mais je ne crois pas que le validator puisse déjà vérifier la validité des pages HTML5.

Si.

Il y a un parseur HTML5 développé par Henri Sivonen, intégré de manière expérimentale à Firefox (dans Firefox 3.6 il me semble, mais pas activé par défaut), et qui sert de base à un validateur HTML5 également développé par Henri Sivonen. Et enfin, ce validateur est repris dans le validateur du W3C, pour son mode de validation HTML5. La seule différence est que validator.nu a en général une version plus récente du code de validation HTML5.

Donc:
- avec le validateur du W3C, on peut valider du HTML5 (la détection selon le doctype devrait marcher);
- mais autant utiliser directement validator.nu.
Pages :
Sujet clos
Aller à