Architecture HTML5 pour un site, les bonnes pratiques...

Structure HTML5:
- J'aurais mis le NAV en dehors du HEADER.
- Pour le contenu central ça va. Pas sûr que le formulaire de réponse à un article ait sa place directement dans l'élément ARTICLE, mais je ne me suis jamais vraiment penché sur la question.
- L'usage des SECTION dans la première partie du FOOTER est faux. Une simple liste UL (et donc remplacer chaque SECTION par un LI) aurait suffi.
- Pour la deuxième partie du footer, je ne sais pas si l'usage d'une SECTION est correct, mais en tout cas la série de NAV c'est overkill.
- En gros pour le contenu de ton méga-footer, soit c'est possible de mettre des NAV dans un FOOTER et là ça fait deux NAV avec dans chaque un contenu non sectionnant (UL>LI pour le premier, (DIV>H2+UL)*4 dans le second). Soit ce n'est pas possible d'après la spec et là tu te contentes de DIV à la place des deux NAV.

Dans l'ensemble ça va, à part une sur-sémantisation galopante dans ton footer.

Divers:
- L'image en header devrait avoir un attribut alt vide ou être en background CSS. L'alternative qui reprend le nom du site n'est pas pertinente.
- Ergonomie: le lien «top» sert un peu à rien. Je m'en passerais.

Merci pour tes précieux conseils fvsch, je vais les appliquer.

- Pour l'image : chaque image, liée à l'article, aura son alt personnalisé, là c'était juste pour mettre quelque chose...

- Pour le formulaire, en fait ce n'est pas un formulaire de contact, j'ai juste placé une plétore d'éléments dans la page test pour les designer. En effet : en mettant tout ce que je peux trouver comme balise dans ma page de test je suis sûr de ne rien oublier de styler. Étant donné que je vais adapter ce truc comme thème pour mon CMS toutes les balises sont susceptibles de servir.

- Le top n'a effectivement pas grand intérêt, et de toute manière me pose problème sous IE et opéra pour lesquels il faudrait que j'adapte une image. Je vais le faire sauter. [édit : finalement je vais le laisser pour les écran supérieur à 1145px de large : un petit bonus marrant qui ne gênera pas la taille de ces écrans...]

- Enfin, pour le footer, je pense que je vais remplacer les liens du fond de footer - qui n'ont pas beaucoup d'intérêt - par une présentation du site.

Et merci encore !

PS : @fvsch, si tu es encore dans les parages, que penses-tu des microformats versus microdata (comme je me met au HTML5 je penche pour ces derniers) ?
Modifié par Olivier C (19 Jan 2012 - 20:28)

fvsch a écrit :
... En gros pour le contenu de ton méga-footer, soit c'est possible de mettre des NAV dans un FOOTER et là ça fait deux NAV avec dans chaque un contenu non sectionnant (UL>LI pour le premier, (DIV>H2+UL)*4 dans le second). Soit ce n'est pas possible d'après la spec et là tu te contentes de DIV à la place des deux NAV.

Je suis allé voir les spécifications W3C : il faut effectivement éviter les nav en footer (lien). Comme pour le header d'ailleurs, j'ai déplacé la <nav> inclue dans ce dernier...

Edith du 26/01 : après relecture plus attentive des spécifications et l'analyse de thèmes WordPress de référence de reviens sur cette idée et réinclue la balise <nav> entre les <header>...
Modifié par Olivier C (26 Jan 2012 - 22:07)

Olivier C a écrit :
PS : @fvsch, si tu es encore dans les parages, que penses-tu des microformats versus microdata (comme je me met au HTML5 je penche pour ces derniers) ?

Pour ce qui est de la syntaxe: les microformats utilisent des structures HTML4 pas vraiment prévues pour ça, ce qui peut poser problème et est de manière générale peu flexible. La syntaxe de microdata est pas mal et dédiée aux métadonnées. Donc plutôt microdata.

Pour ce qui est des vocabulaires existants et de la reconnaissance par divers outils, je ne me suis pas assez penché sur le sujet.

fvsch a écrit :
Donc plutôt microdata.

Entretemps j'ai jeté un oeil sur les deux techniques : effectivement la démarche microdata semble plus viable à long terme, car liée au html5, et surtout plus propre pour ce qui est du processus d'intégration. Bref, à l'inverse du "bricolage maison" des microformats (mais c'est tout à l'honneur de ceux qui ont introduit cette technique) les microdatas ont été conçus pour cela à l'origine.

fvsch a écrit :
Pour ce qui est des vocabulaires existants et de la reconnaissance par divers outils, je ne me suis pas assez penché sur le sujet.

Le site www.schema.org répertorie les spécifications propres aux microdatas, c'est le codex réputé le plus exhaustif pour l'instant. Pour la reconnaissance, on peut imaginer que nous en sommes au même point que pour le html5 : les moteurs de recherche comme Google - tout en intégrant déjà certaines spécificités propre à ces formats - vont attendre de voir pour rééquilibrer leur balance en fonction de l'usage moyen qui en sera fait sur le net...

En fait schema.org est née de l'association de Google, Bing et Yahoo pour créer des microdata universelles.

Est-ce que cela compte actuellement dans la référencement ? Directement c'est dur à dire, mais Google s'en sert déjà pour générer ses "Rich Snippets". Autrement dit, ils sont utilisés, c'est indubitable; mais le poids au niveau du positionnement SEO est dur à juger présentement.

C'est vrais, c'est trop neuf. Mais comme je suis un amateur et que mon site n'est pas marchand je n'ai pas d'enjeu : par passion je peux me permettre de perdre du temps à m'investir dans une techno' sans avoir de compte à rendre à un employeur sur son efficacité réelle.