5568 sujets

Sémantique web et HTML

Code HTML5 ready en attendant la recommandation finale ?

Bonjour,

Dans la mesure ou HTML5 n'est absolument pas possible dans un contexte de production (E-commerce, site à fort traffic etc), oublions la solutions namspaces et htmlshiv qui n'est pas envisageable.

Pensez vous qu'un site produit aujourd'hui devrait incorporer du code qu'un simple parser Perl (ou autre) pourrait transformer en HTML5 demain ?

Avez vous connaissance d'un tel projet ?

Du genre : 

<div class="header"><div class="hgroup"><h1>Title</h1><h2>tagline</h2></div></div>

<div class="section"><div class="footer"></div></div>


Le problème étant pour moi d'utiliser des <H1> <H2> (class H3-h1, H4-h2 ? Smiley ohwell ) dans une div article ou section, qui en terme de référencement pourrait s’avérer catastrophique.

Pour finir pensez vous qu'en tant qu'intégrateur sur des projets important, il est de notre responsabilité que de proposer une sémantique HTML5 ready ?
Je pense pas que ce soit une nécessité à l'heure actuelle, néanmois c'est une plutôt bonne idée d'utiliser une class maintenant pour à l'avenir pouvoir le changer directement en tag Html5... Faudrait voir à trouver un truc qui fasse ça, et pourquoi pas l'inverse aussi...
rs459 a écrit :
Pensez vous qu'un site produit aujourd'hui devrait incorporer du code qu'un simple parser Perl (ou autre) pourrait transformer en HTML5 demain ?

Non.
Si le code a été conçu en prevoyant cette éventualité, je ne vois pas pourquoi il ne pourrait pas, tu peux développer fvsch ?
Salut,

J'avoue avoir quelques difficultés à suivre : en quoi HTML5 ne serait pas utilisable en production ? Il faudrait attendre quoi à votre avis :
- la recommandation finale (prévue en 2022 ...)
- que les navigateurs récents le supportent (c'est pas déjà le cas pour une bonne partie des balises ?)
- que les moteurs de recherche en tiennent compte (il tiennent déjà compte des hgroup, article, aside ...)
- que les "vieilles" versions des navigateurs disparaissent (là, on est au-delà de 2022 !)

Bref, j'ai du mal à saisir pourquoi tu ne veux pas d'HTML5 en contexte de prod. Dans mon agence, on a déjà pris le parti de l'imposer aux clients sur les nouveaux projets, notamment pour des sites à 1500 visiteurs uniques/j, sans aucun feed-back négatif ...

Est-ce que c'était à ça que tu pensais fvsch ?
Je ne me prononcerai pas sur l'utilisation de html5 sur un site commercial par contre pour ce qui des titres de sections, l'ancienne méthode est toujours valable (voir mon site) et même conseillée pour les lecteurs d'écran actuels. Le <hgroup/> présente des problèmes d'accessibilité avec JAWS. Smiley cligne
Modifié par Patidou (14 Feb 2011 - 11:42)
HammHetfield a écrit :
Si le code a été conçu en prevoyant cette éventualité, je ne vois pas pourquoi il ne pourrait pas

La question était: faut-il procéder ainsi. Ma réponse est non. Il n'y a pas d'obligation à procéder ainsi, ce n'est à ma connaissance pas une bonne pratique établie, et pour finir l'intérêt ne me semble pas évident.

MAD's a écrit :
- la recommandation finale (prévue en 2022 ...)

Rien n'est prévu pour 2022, c'est un mythe.

MAD's a écrit :
- que les navigateurs récents le supportent (c'est pas déjà le cas pour une bonne partie des balises ?)

HTML5 c'est large. Le support est partiel dans tous les navigateurs, y compris les plus récents et ceux qui sortiront dans les prochaines semaines (FF4, IE9).

MAD's a écrit :
- que les moteurs de recherche en tiennent compte (il tiennent déjà compte des hgroup, article, aside ...)

Oui, si les moteurs de recherche exploitent certaines fonctionnalités de HTML5 et que ça sert les objectifs de positionnement du site, c'est une bonne raison pour s'y mettre. Cependant je n'ai pas connaissance d'une utilisation de HGROUP, ARTICLE, ASIDE ou autre dans les algorithmes, et je ne crois pas que ça soit la priorité des ingénieurs de Google ou Bing; aurais-tu une source fiable à ce sujet? À ma connaissance la seule fonctionnalité HTML5 utilisée par les moteurs, c'est l'exploitation de deux ou trois vocabulaires microdata par Google.
MAD's a écrit :
- que les &quot;vieilles&quot; versions des navigateurs disparaissent (là, on est au-delà de 2022 !)

Si tu fais un site de premier plan avec des enjeux très clairs, par exemple un fnac.com, tu cherches normalement à être compatible avec le plus de configurations possibles. Et donc tu dois assurer, au minimum, le support de IE7 et IE8 sans JavaScript, et sans doute IE6 aussi (avec ou sans JavaScript). Donc ça fait une bonne raison pour ne pas structurer les contenus avec des éléments HTML5 (type SECTION, ARTICLE, ASIDE...) que ces navigateurs ne peuvent pas styler s'ils ne sont pas préalablement «activés» en JavaScript.

MAD's a écrit :
Bref, j'ai du mal à saisir pourquoi tu ne veux pas d'HTML5 en contexte de prod.

Je n'ai jamais dit que je n'en veux pas.
Modifié par fvsch (14 Feb 2011 - 15:08)
L'objectif de ma "méthode" est purement de préparer l'évolution rapide, par exemple ne pas utiliser les compétences de l'expert architecture/hiérarchie dans 1 ou X années, alors qu'on peut la penser aujourd'hui en nouveau projet ou en refactoring, tout en restant sur un langage éprouvé.

Niveau css également les modifications serait minimes avec par exemple une classe .aside qui deviendrait purement et simplement un aside etc.

MAD's a écrit :
Bref, j'ai du mal à saisir pourquoi tu ne veux pas d'HTML5 en contexte de prod.


C'est pas aussi catégorique que ca quand même.

Mais par exemple faire cohabiter un CRM par exemple où tous les utilisateurs n'ont pas forcement javascript activé, ou avec un site qui lui aussi ne peux pas se permettre de perdre ne serait-ce qu'un pour-cent de son audience.

Ensuite parce que si le draft change ça peut être gênant en terme de maintenance, (obligés de rectifier en urgence, retarder un autre projet avec les pénalités qui peuvent exister) je ne sais pas comment est contractualisé la maintenance mais j'imagine qu'il doit y avoir une obligation de résultat.

Il y a aussi l’accessibilité, comment garantir qu'un lecteur braille (ou voix) restitue correctement la sémantique html5, (les nouvelles versions peut être). En terme de prix un lecteur écran n'est pas donné, et les revenus pour un handicapé sont assez limités, ça peut faire encore quelques pour-cent.

Après il y aussi le référencement, aujourd'hui quel impact a un <H1> dans un <article>, est-ce que je prévois SAFE c'est à dire je reste avec une hiérarchie de titre type (x)html ? ou j'ose le h1 dans un contexte ?

Mais demain si mon h3 (h1 en html5) n'a pas autant de valeur que le concurrent, qui a opté pour un h1 embarqué dans un <article> ? Contractualisation et dédouanement des pertes possibles ou pas ? Si il n'est plus dans le carré d'or la chute du chiffre d'affaire peut être brutale Smiley ohwell

<---- PARANO INSIDE Smiley lol
Modifié par rs459 (14 Feb 2011 - 20:13)
J'ai peut être été un peu catégorique dans mes propos, je vais tacher de me modérer Smiley smile

Il est clair que la cible finale du site va conditionner les choix stratégiques en matière de techno, architecture, etc ... Néanmoins, j'aurais tendance à faire d'abord le choix de HTML5, quitte à revoir ma position durant l'étude du projet plutôt que l'inverse ...

Alors, certes, les navigateurs n'implementent pas la totalité de la recommandation, et pour cause ... Mais les plus récents sont quand même largement capables de s'en accomoder, et l'ensemble va s'améliorer de plus en plus ... Et pour les autres, on est de mieux en mieux équipés pour simuler leur prise en charge ...

Après, on peut aussi retourner la question : est-ce réellement judicieux d'essayer de concevoir un site "pré-formaté" HTML5, pour pouvoir faire la bascule quand on le jugera bon, au risque qu'à ce moment, l'ensemble du site soit dépassé et qu'il faille tout refondre ? Je suis conscient que je me tire une balle dans le pied là : pourquoi ne pas attendre un peu que les navigateurs soient plus HTML5-compliant Smiley biggol au risque de devoir tout refondre (faire et défaire, bla bla bla)

En bon normand, je n'ai pas la réponse ... J'ai commencé à faire du web en 95, et j'essaie de me rappeler si ces questions avaient été soulevées avec le passage à HTML4, et les prises de position ... Quelqu'un a la réponse ?

Voilà, encore une fois, ce ne sont que mes deux centimes ...

PS : pour les moteurs de recherche et leur prise en charge, je suis sur d'avoir lu ça quelque part, je vais tacher de retrouver ...
a écrit :
J'ai commencé à faire du web en 95


Je n'ai pas encore commencé dans un contexte pro, je m'interroge juste un peu sur la maturité de html5.

J'ai un peu l'impression que ca pourrait être un argument commercial, durant la période de transition que de proposer aux clients une évolutivité vers html5 assez rapide.

Après c'est sur que tout dépendra du client, de sa cible et de la durée de vie de son projet.

Ma question aurait du plutôt être formulé ainsi :

Si les impératifs techniques // ou le cahier des charges impose(nt) le (x)html , pensez vous que prévoir un code "préformaté" html5 via des classes est un bonne idée ?

a écrit :
J'ai peut être été un peu catégorique dans mes propos, je vais tacher de me modérer smile


J'ai été un peu catégorique aussi dans mon introduction, en prétendant que HTML5 n'est pas envisageable dans un contexte de prod.

a écrit :
PS : pour les moteurs de recherche et leur prise en charge, je suis sur d'avoir lu ça quelque part, je vais tacher de retrouver


C'est vrai que sans savoir comment les moteurs référenceront les sites html5 dans les semaines à venir, j'ai un peu de mal à me dire que c'est suffisamment mature. Je vais essayer d'approfondir tout ça parce que je me suis récemment intéressé au référencement et la hiérarchisation a un impact significatif visiblement. Html5 propose une hiérarchisation multi-niveaux, c'est un peu déroutant.

Un aside par exemple pourrait par exemple être jugé de moindre importance, qu'un simple div et tout remettre en question, dans la redistribution du link juice. C'est une période de flottement assez sévère à mes yeux, qui me fait penser que pour de gros projet html5 n'est peut être pas assez prêt (même s'il est possible que je me trompe lourdement)
fvsch a écrit :
Cependant je n'ai pas connaissance d'une utilisation de HGROUP, ARTICLE, ASIDE ou autre dans les algorithmes, et je ne crois pas que ça soit la priorité des ingénieurs de Google ou Bing; aurais-tu une source fiable à ce sujet ?


Comme d'habitude, mon enthousiasme me jour des tours Smiley smile ... J'ai réussi à remettre la main sur ça et ça aussi. Grosso modo, même si le support du HTML5 reste encore expérimental et confidentiel dans les développements des moteurs de recherche, ils sont à l'affût de son adoption *massive*. Mais son usage n'est pas pénalisant pour autant ...
MAD's a écrit :
En bon normand, je n'ai pas la réponse ... J'ai commencé à faire du web en 95, et j'essaie de me rappeler si ces questions avaient été soulevées avec le passage à HTML4, et les prises de position ... Quelqu'un a la réponse ?

Quand HTML 4.0 est sorti, les développeurs et webmasters ignoraient qu'il y avait différentes versions de HTML. Il faut dire que HTML 1 n'a jamais été défini très clairement, HTML 2 n'a jamais existé (sauf sous la forme d'un projet mort-né de l'IETF?), HTML 3.0 n'a jamais été finalisé, HTML 3.2 si mais a vite donné naissance à HTML 4. De plus la notion même de standards n'existait pas trop, on utilisait plutôt «les balises qui marchent dans Netscape», puis «les balises qui marchent dans Internet Explorer».

Ce n'est qu'au début des années 2000 que les pionniers ont commencé à mettre les standards en avant, souvent en se servant de XHTML 1.0 (= HTML 4 en syntaxe XML, du moins en théorie) comme terme fédérateur et en mélangeant ça au positionnement CSS et à l'abandon des tableaux de mise en page.
rs459 a écrit :
Si les impératifs techniques // ou le cahier des charges impose(nt) le (x)html , pensez vous que prévoir un code &quot;préformaté&quot; html5 via des classes est un bonne idée ?

Non.

- Ça fait du travail en plus (réfléchir à la bonne sémantique HTML5 à utiliser), qui n'est pas vendu.
- Très très fort risque que ce travail reste lettre morte. En intégration web, toute action remise à plus tard à toutes les chances de ne jamais être entreprise, pour tout un tas de raisons.
- La spec peut changer. L'exploitation des éléments HTML5 dans le Google de 2014 peut être différente de ce qui a été réfléchi en 2011.
- Qui, quelques années plus tard, va décider d'appliquer une moulinette à la fiabilité incertaine sur un code fonctionnel, puis de lancer toute une batterie de tests? Personne.

Mieux vaut introduire du code HTML5 quand il commence à faire sens pour le projet. Rien ne sert de courir...
Marchal a écrit :
je voit pas pourquoi vous êtes si presser de coder en HTML 5

L'attrait de la nouveauté après 5 ou 10 ans à coder en HTML 4, j'imagine.

Marchal a écrit :
car c'est même pas fini, donc pas implanté

Les standards du Web marchent plutôt comme ça: on fait une version pas finie, puis on l'implémente, puis on corrige la spécification grâce à ce qu'on appris des tentatives d'implémentation, et enfin on corrige les implémentations. Donc 4 étapes (très schématiques). Certaines parties de HTML5 sont aujourd'hui stables et plutôt bien implémentées, d'autres sont plus instables et expérimentales.

Il ne faut pas voir les spécifications complexes (HTML5, SVG, CSS3) comme des trucs monolithiques, surtout que certaines sont modulaires (CSS3, dans une certaine mesure SVG, ou encore le vocable «HTML5» qui regroupe certaines specs d'API JavaScript pas sous la houlette du WHAT WG). Et quelque part on pourrait dire la même chose de HTML4 ou de CSS2.1, specs monolithiques et stables mais dont on se contente généralement d'utiliser les parties bien implémentées.
Sujet clos
Aller à