Thème Dotclear 2, html 5 et sémantique

Bonsoir,

Je suis en train de passer le thème par défaut de DC2 en html 5 (site de test), la css n'a d'ailleurs quasiment pas changé, je ferai un design personnel dans un second temps. J'ai gardé la syntaxe xhtml. Les pages sont valides.

Je me pose des questions sur le bandeau à droite… Est-ce que vous procéderiez ainsi ou mettriez le tout dans un élément aside?

Si vous avez d'autres remarques, elles sont les bienvenues.

P.S. : contrairement aux gabarits d'origine, j'ai mis la recherche en dur dans le code.
Modifié par Patidou (30 Mar 2010 - 23:59)

Salut Patidou,
le passage à HTML5 (encore en draft et pas encore assez largement implémenté) n'est-il pas un peu précipité?

Salut Hermann,

J'ai essayé d'utiliser des éléments dont la spec risque de ne pas trop changer. À l'heure actuelle, il est possible d'utiliser html5 sur des navigateurs ne le gérant pas (IE<9) avec un bout de javascript et quelques règles au niveau du code html.

Au niveau accessibilité, je n'ai pas recréé une hiérarchie (h1) à chaque nouvelle sections, pour ne pas gêner les lecteurs d'écran qui ne supporte pas encore html 5.

Puis de toutes façons, c'est pour un blog, ce n'est pas comme si c'était un site commercial. Et j'apprends plein de trucs.



Un billet intéressant à ce propos sur html5doctor : How to use HTML5 in your client work right now.

EDIT: Et même sur alsacréations, on nous propose d'y passer
Modifié par Patidou (31 Mar 2010 - 13:59)

La bonne nouvelle, c'est que lorsque HTML5 sera plus répandu, il ne sera pas trop difficile de modifier les templates de Dotclear, puisque tu auras fait tout le travail

Euh oui… Faut voir si je n'ai pas fait trop d'erreurs.

Je crois que je vais garder un gabarit générique (si ça vous intéresse) qu'on pourra utiliser pour la distribution officielle et un autre avec un design plus perso.
Modifié par Patidou (31 Mar 2010 - 20:00)

Finalement c'est toute la colonne de droite dans le <aside>.

Ajout de l'attribut required sur les éléments du formulaire pour les commentaires…
Modifié par Patidou (11 Apr 2010 - 15:04)

Il pourrait être judicieux, dans un article, de séparer par des sections les différentes composantes :
- contenu
- annexes
- commentaires
- rétroliens

Concernant les annexes, il a un petit soucis je pense dans le billet Les œufs dans le même panier sont cassés, où la première pièce jointe est une vidéo (balise video), et non une url vers le fichier.

Tu pourrais également ajouter l'attribut placeholder pour les champs de formulaire.
Modifié par octopus984 (21 Apr 2010 - 19:22)

octopus984 a écrit :
Il pourrait être judicieux, dans un article, de séparer par des sections les différentes composantes :
- contenu
- annexes
- commentaires
- rétroliens

Les annexes font partie du contenu de l'article, pour moi, bien qu'à la saisie les deux soient gérés différemment. Les commentaires et rétroliens peuvent être groupés (sous l'intitulé «Discussion» ou «Réactions» par exemple).

Maintenant, est-ce utile de faire deux SECTION, une pour le contenu et une autre pour les discussions? L'exemple donné par la spec c'est:

<article>
  <header> Titre et infos </header>
  Ici le contenu de l'article
  <footer> Méta-données (peut se placer après le header, voire avant, dans certaines mises en page) </footer>
  <section>
    Commentaires:
    <article>Un commentaire</article>
    <article>Un autre</article>
  </section>
</article>

Cet exemple laisse voir une hiérarchie entre le contenu de l'article (directement dans la section ARTICLE) et les commentaires placés dans une sous-section (SECTION). Si tu mets le contenu et les commentaires chacun dans une SECTION, tu perds cette hiérarchie.

Remarques en vrac:

- Les LINK rel=contents|section|chapter, j'ai toujours trouvé ça d'une flagrante inutilité. Il est peut-être temps de laisser tomber, et de gagner au passage en légèreté des pages (même si ça aura pas un impact flagrant, on est d'accord)?

- Les feuilles de styles sont appelées avec la syntaxe @import, qui pose des problèmes à IE (ça casse les téléchargements parallèles, en gros tes deux feuilles de styles vont être téléchargées l'une après l'autre au lieu d'être chargées en parallèle, ce qui peut avoir un impact sensible sur une connexion avec une latence forte). On utilisera plutôt <link rel="stylesheet" media="..." href="...">.

- Tu peux supprimer tous les type="text/javascript" et type="text/css" si tu le souhaites (valeurs par défaut en HTML5).

- Les scripts JS, à appeler en fin de document (avant </body>) pour éviter de bloquer le rendu de la page. On laissera juste le html5shiv pour IE 8-, nécessaire au rendu de la page. Par contre, il vaut mieux placer ce dernier avant l'appel des CSS (d'après le site de ce projet).

- La ligne <style type="text/css" media="screen">@import url(http://pragmafilm.lombre.net/?pf=odt/style.css);</style> est générée par un plugin? Du coup les styles ne peuvent pas être rajoutés à la feuille de styles principale?

- C'est dommage d'avoir le nom du site en H1, et le titre de l'article en H2, y compris sur les pages d'article. OK pour la page d'accueil, mais sur les articles eux-mêmes avoir le titre de l'article en H1 serait pas mal. (De mémoire, en HTML5 on a le «droit» d'avoir un plan du document qui ne commence pas par H1. Faudrait que je revoie ça.)

- Les FIELDSET sans LEGEND, ça sert pas un peu à rien? Mais bon, ça fait pas de mal non plus.

- Détail de rien: pour l'attribut pubdate, les syntaxes acceptées sont pubdate seul, pubdate="" et pubdate="pubdate". Je préfère la première, et éventuellement la troisième si on tient à mettre une valeur. Tu utilises la deuxième (pubdate=""). Of course tu fais comme tu veux.

Pas trouvé d'autre problème ou question après une première lecture du code. Je ne commente pas l'usage de RDF et des roles ARIA, que je connais mal.
Modifié par Florent V. (21 Apr 2010 - 22:13)

OH, j'avais loupé ça:

<meta name="MSSmartTagsPreventParsing" content="TRUE" />

Cette ligne de code n'a jamais servi à rien, comme je l'écrivais ici:
http://www.alsacreations.com/article/lire/628-balises-meta.html

Florent V. a écrit :

- Les scripts JS, à appeler en fin de document (avant </body>) pour éviter de bloquer le rendu de la page. On laissera juste le html5shiv pour IE 8-, nécessaire au rendu de la page. Par contre, il vaut mieux placer ce dernier avant l'appel des CSS (d'après le site de ce projet).

A ce propos, les spécifications HTML5 pour la balise script introduisent de nouveaux attributs, dont notamment defer et async, lesquels permettent d'indiquer l'instant à partir duquel le script va s'exécuter (immédiatement, après avoir été complètement chargé ou après le parsing complet du document).
Fini donc les disgracieux blocs de script en bas de page !
Modifié par octopus984 (22 Apr 2010 - 00:23)

octopus984 a écrit :
Fini donc les disgracieux blocs de script en bas de page !

Oui, dans cinq ans, quand la grande majorité des navigateurs implémenteront ces attributs.

octopus984 a écrit :
Il pourrait être judicieux, dans un article, de séparer par des sections les différentes composantes :
- contenu
- annexes
- commentaires
- rétroliens

Je rejoins l'avis de Florent ci-dessous.

octopus984 a écrit :
Concernant les annexes, il a un petit soucis je pense dans le billet Les œufs dans le même panier sont cassés, où la première pièce jointe est une vidéo (balise video), et non une url vers le fichier.

Dans les gabarits originaux (en xhtml 1.0 strict), c'est un player flash qui est affiché (d'ailleurs ici en contenu alternatif à video). Tu as raison je vais mettre en plus un lien vers le fichier.

octopus984 a écrit :
Tu pourrais également ajouter l'attribut placeholder pour les champs de formulaire.

Je vois plus l'utilité de cet attribut pour les champs sans labels (mais avec un title) comme le champs pour la recherche.
Modifié par Patidou (22 Apr 2010 - 10:23)

Julien Royer a écrit :

Oui, dans cinq ans, quand la grande majorité des navigateurs implémenteront ces attributs.

Pfff, quel rabat-joie !

Florent V. a écrit :
Remarques en vrac:

Aïe

Florent V. a écrit :
- Les LINK rel=contents|section|chapter, j'ai toujours trouvé ça d'une flagrante inutilité. Il est peut-être temps de laisser tomber, et de gagner au passage en légèreté des pages (même si ça aura pas un impact flagrant, on est d'accord)?

Il paraît que les robots indexeurs les utilisent (à vérifier). Sur le forum dotclear, un utilisateur d'Opera utilisent les fonctionnalités de ce navigateur pour se balader rapidement dans le site grâce aux link. Je vais laisser pour l'instant.

Florent V. a écrit :
- Les feuilles de styles sont appelées avec la syntaxe @import, qui pose des problèmes à IE (ça casse les téléchargements parallèles, en gros tes deux feuilles de styles vont être téléchargées l'une après l'autre au lieu d'être chargées en parallèle, ce qui peut avoir un impact sensible sur une connexion avec une latence forte). On utilisera plutôt <link rel="stylesheet" media="..." href="...">.

OK. Je vais changer ça. Dans mon futur thème perso, je compte tout regrouper dans un fichier.

Florent V. a écrit :
- Tu peux supprimer tous les type="text/javascript" et type="text/css" si tu le souhaites (valeurs par défaut en HTML5).

Ok.

Florent V. a écrit :
- Les scripts JS, à appeler en fin de document (avant </body>) pour éviter de bloquer le rendu de la page.

Là j'ai des contraintes liées à dotclear: je dois laisser jquery dans le head, les plugins peuvent écrire dans le head ou avant le </body>; pour des raisons historiques, la majorité insère leurs fichiers js dans le head. Bien sûr si c'était pour un thème ne devant pas être redistribué, il n'y aurait pas de problèmes.

Florent V. a écrit :
On laissera juste le html5shiv pour IE 8-, nécessaire au rendu de la page. Par contre, il vaut mieux placer ce dernier avant l'appel des CSS (d'après le site de ce projet).

Ok je changerai ça.

Florent V. a écrit :
- La ligne <style type="text/css" media="screen">@import url(http://pragmafilm.lombre.net/?pf=odt/style.css);</style> est générée par un plugin? Du coup les styles ne peuvent pas être rajoutés à la feuille de styles principale?

Oui c'est un plugin, à mon avis c'est un bug, il n'est pas activé sur ce blog de test.

Florent V. a écrit :
- C'est dommage d'avoir le nom du site en H1, et le titre de l'article en H2, y compris sur les pages d'article. OK pour la page d'accueil, mais sur les articles eux-mêmes avoir le titre de l'article en H1 serait pas mal. (De mémoire, en HTML5 on a le «droit» d'avoir un plan du document qui ne commence pas par H1. Faudrait que je revoie ça.)

Toujours pour rester compatible j'ai préféré garder une hiérarchie à l'ancienne, plus accessible. Mais pourquoi pas sur un thème plus perso.

Florent V. a écrit :
- Les FIELDSET sans LEGEND, ça sert pas un peu à rien? Mais bon, ça fait pas de mal non plus.

OK je vais regarder si je peux les supprimer.

Florent V. a écrit :
-- Détail de rien: pour l'attribut pubdate, les syntaxes acceptées sont pubdate seul, pubdate="" et pubdate="pubdate". Je préfère la première, et éventuellement la troisième si on tient à mettre une valeur. Tu utilises la deuxième (pubdate=""). Of course tu fais comme tu veux.

Oui comme c'est une syntaxe xmlisée pour le contenu des articles, j'ai préféré l'utiliser partout. Et puis si un jour on passe à xhtml5, il n'y aura pas trop de boulot à faire.
Bon là j'ai eu la flemme de répéter l'attribut en valeur.

Florent V. a écrit :
Pas trouvé d'autre problème ou question après une première lecture du code. Je ne commente pas l'usage de RDF et des roles ARIA, que je connais mal.

Le dublin core était dans les gabarits d'origine, je l'ai laissé.

Pour ce qui est des roles, j'ai beaucoup appris sur le blog de Bruce Lawson et html5doctor.


Merci pour toutes ces remarques.
Modifié par Patidou (22 Apr 2010 - 11:12)

Florent V. a écrit :
OH, j'avais loupé ça:

<meta name="MSSmartTagsPreventParsing" content="TRUE" />

Cette ligne de code n'a jamais servi à rien, comme je l'écrivais ici:
http://www.alsacreations.com/article/lire/628-balises-meta.html

Héhé, je pensais l'avoir supprimé partout, je vais vérifier ça.

Salut,

Patidou a écrit :

Toujours pour rester compatible j'ai préféré garder une hiérarchie à l'ancienne, plus accessible. Mais pourquoi pas sur un thème plus perso.

En quoi est-ce plus accessible? Personnellement je préfère n'avoir qu'un seul H1 correspondant au titre de la page et des h2 pour les autres grand ensembles mais qui ne correpondent pas forcément au contenu de la rubrique.

Exemple :
<h2 class"hide">Rubriques</h2>
<h1>Titre de la page</h1>
"<h2>Contenu permanent</h2>"

A ce sujet > http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H42

Patidou a écrit :
Oui comme c'est une syntaxe xmlisée pour le contenu des articles, j'ai préféré l'utiliser partout. Et puis si un jour on passe à xhtml5, il n'y aura pas trop de boulot à faire.
Bon là j'ai eu la flemme de répéter l'attribut en valeur.

Je ne sais pas pour XHTML5, mais en XHTML1 la syntaxe attribut="" pour les attributs booléens n'est pas valide, il faut utiliser attribut="attribut" (true) ou omettre l'attribut (false).
Ben la syntaxe XML pour les attributs «binaires» c'est attribut="attribut", pas attribut="", il me semble.
Hmm, après vérification avec validator.nu la syntaxe attribut="" semble valide en XHTML5. Ça pourrait être un bug du validateur, mais la spec ne dit pas que cette syntaxe n'est pas valide en XHTML5.

Florent V. a écrit :
Hmm, après vérification avec validator.nu la syntaxe attribut="" semble valide en XHTML5. Ça pourrait être un bug du validateur, mais la spec ne dit pas que cette syntaxe n'est pas valide en XHTML5.

Non c'est bien valide mais je ne sais plus où je l'ai lu, on conseille même cette syntaxe pour xhtml5. Le validateur du w3c ne bronche pas non plus (en mode html).

Je vais chercher le lien vers la ressource.

Hermann a écrit :
Salut,

En quoi est-ce plus accessible? Personnellement je préfère n'avoir qu'un seul H1 correspondant au titre de la page et des h2 pour les autres grand ensembles mais qui ne correpondent pas forcément au contenu de la rubrique.

Exemple :
<h2 class"hide">Rubriques</h2>
<h1>Titre de la page</h1>
"<h2>Contenu permanent</h2>"

A ce sujet > http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H42

Ah, je ne savais pas... J'avais toujours dans l'idée que le premier titre rencontré devait être un <h1> que ce soit le titre du site ou celui de l'article.

Merci pour l'info.

Laurent Denis va me chauffer les oreilles...