HTML5, une porte ouverte à de futurs manques de rigueur ?

Salut,

Oui, effectivement, mais pourquoi ne pas avoir voulu avec le html5, "imposer" une rigueur dans le codage? Bref, avec html5, que devient l'utilité d'écrire un code "propre" ? Moi, je suis personnellement pour un code propre et comme tu le dis, rien ne m'en empêche. Je suis pour, car je m'y retrouve mieux...

Avec html5, respecter la hiérarchie des balises, mais ne pas les fermer, par exemple, ne gêne en rien la sémantique?

Pour éclaircir un peu ma pensée:

Si j'écris un livre, un roman ou autre. je peux écrire en titre: chapitre 1, puis son contenu et ensuite, chapitre 2 et son contenu... je ne suis pas obligé d'écrire à la fin du chapitre 1: ici fini le chapitre 1, etc...

Mais si les deux solutions sont acceptables et ne gênent en rien l'écriture.

Pour le web, et si j'ai bien compris, la sémantique doit être rigoureuse et formelle si l'on veut que ce qui est envoyé sur la toile soit accessible et utilisable de manière "universelle" par tous les programmes qui vont, à notre demande, chercher l'info sur ladite toile.

Et là, valait mieux écrire quelque chose comme "fin du chapitre 1", non?
Modifié par Vajra (09 Sep 2010 - 12:44)

Salut,

si tu veux plus de rigueur il ne faut pas servir tes documents en "text/html" mais en "application/xhtml+xml".

Personnellement j'aime bien avoir le choix et ça ne m'empêche pas d'être rigoureux... d'autant plus que "application/xhtml+xml" ne m'apporterait rien.

Salut,

Avec html5, on se rapprocherait alors d'une manière plus intuitive d'"écrire", d'organiser un document, tout en étant souple sur les erreurs les plus fréquentes (pour ne pas dire mauvaises habitudes) de certains codeurs ?

(non, va dire mauvaises habitudes, car une erreur c'est une erreur )
Modifié par Vajra (09 Sep 2010 - 13:19)

Vajra a écrit :
Pour le web, et si j'ai bien compris, la sémantique doit être rigoureuse et formelle si l'on veut que ce qui est envoyé sur la toile soit accessible et utilisable de manière "universelle" par tous les programmes qui vont, à notre demande, chercher l'info sur ladite toile.

Tu confonds sémantique HTML et rigueur syntaxique.
Tu peux faire des documents syntaxiquement rigoureux en XHTML5 ou XHTML1 (servi en application/xhtml+xml dans les deux cas), les validateurs te signaleront alors les fautes de syntaxe et les navigateurs considèreront les erreurs de syntaxe comme des erreurs critiques et n'afficheront pas la page (ou basculeront sur le parseur HTML). Cependant, rien ne garantit que ces documents à la syntaxe rigoureuse fassent un bon usage de la sémantique HTML.

Exemple de document à la syntaxe XHTML 1.0 rigoureuse (contenu de BODY seulement):

<div class="center-black"><div class="red-12px">
  <a href="accueil.html">Accueil</a> |
  <a href="champi.html">Champignons</a> |
  <a href="tartif.html">Tartiflette</a>
</div></div>
<!-- On saute pas mal de lignes entre le haut et le contenu lol -->
<br /><br /><br /><br /><br /><br />
<div class="blue">
<div class="titre-page">BONJOUR!</div>
<div class="texte">Premier paragraphe.<br /><br />
Deuxième paragraphe<br /><br />
Troisième paragraphe<br /><br />
Quatrième paragraphe.
</div></div>

Et encore, on peut faire pire comme exemple.

Il faut apprendre à séparer les problématiques pour savoir de quoi on parle:
- Web sémantique (microformats, RDF/RDFa, microdata, etc.);
- sémantique HTML (utiliser les éléments HTML qui décrivent le mieux chaque contenu);
- rigueur ou permissivité de la syntaxe (syntaxes XML rigoureuses, syntaxes HTML plus libres);
- conventions de codage, lisibilité du code...

Si on veut parler de la syntaxe, alors oui, HTML5 permet, comme HTML 4.01, d'écrire <br> plutôt que <br />, de ne pas encadrer les valeurs des attributs par des guillemets (du moment que la valeur ne contient pas d'espace ou de signe " > <), et d'omettre certaines balises de fermeture (ça dépend des éléments). Il décrit aussi de manière précise comment les navigateurs doivent se comporter dans ces cas de figure.

Un avantage de XHTML 1 est qu'il a permis d'unifier les pratiques syntaxiques, vu qu'il fallait respecter la syntaxe XML sous peine de se faire engueuler par le validateur. Pour 99% des développeurs web, ça a été le seul apport de XHTML 1. Il y avait aussi un intérêt pédagogique car apprendre «on fait comme ça et pas autrement» est plus simple qu'apprendre «en général on fait comme ça, mais sinon on peut faire comme ceci ou encore comme cela».

Avec HTML5 qui gagne du terrain, rien n'empêche:
- d'enseigner un «style» syntaxique précis;
- de fixer une convention de codage pour une personne, une équipe ou une entreprise donnée.

Le problème, c'est qu'on manque alors d'outils pour vérifier que les étudiants, les membres de l'équipe ou les collaborateurs de l'entreprise ont bien respecter le style enseigné ou les conventions fixées. En effet, le validateur (voir validator.nu) ne signalera pas le non-respect de ces conventions particulières, tant que le code est valide.
Pas sûr que ça soit un problème grave. Les parseurs HTML des navigateurs se débrouillent déjà très bien avec du code «peu rigoureux». De plus HTML5 ne permet pas tout et n'importe quoi, même si les règles de validation sont parfois subtiles:

<p><p></p></p> <!-- Invalide -->
<p><span></p></span> <!-- Invalide -->
<p><p></p> <!-- VALIDE -->
<p><span></p> <!-- Invalide -->

Enfin, la porte est déjà ouverte depuis longtemps à des manques de rigueur syntaxique. Ça s'appelle un parseur HTML, et ça essaie de se débrouiller avec tout ce qu'on lui envoie, même le code le plus foireux au monde. L'existence de validateurs et de XHTML 1 n'a jamais empêché:
- la création de code HTML sans numéro de version, jamais testé dans le moindre validateur;
- la création de code HTML 4 (même largesses syntaxiques que HTML5) valide;
- la création de code HTML 4 invalide, parfois jamais testé dans le moindre validateur;
- la création de code XHTML 1 invalide, parfois jamais testé dans le moindre validateur.

Ma réponse est donc: non, HTML5 n'est pas une porte ouverte à de futurs manques de rigueur syntaxique.

Quant à la sémantique HTML, c'est une toute autre affaire. HTML5 cherche au contraire à la renforcer, et il reste à voir si ça aura des effets positifs ou pas.
Modifié par Florent V. (09 Sep 2010 - 14:17)

Vajra a écrit :
Avec html5, on se rapprocherait alors d'une manière plus intuitive d'"écrire", d'organiser un document

Non, on a au contraire la possibilité d'organiser plus formellement un document, en utilisant les éléments SECTION, HEADER, ARTICLE, FOOTER, ASIDE, etc. Ce n'est pas une manière plus intuitive d'écrire du code HTML, vu que ça demande au contraire une formation spécifique et apprendre à connaitre l'algorithme d'extraction du plan du document (document outline).
Modifié par Florent V. (09 Sep 2010 - 14:17)

Perso j'utilise une syntaxe xhtml, je trouve ça plus clair et il suffit de modifier les headers pour envoyer en html5 ou xhtml5.

Exemple : site de test en xhtml5, site en html5.
Modifié par Patidou (09 Sep 2010 - 14:46)

Vajra a écrit :
et pour être case-pieds: l'important est donc + la validité du code que le style "syntaxique" employé, à chacun son style... ?

Impossible de dire «l'important c'est...» dans l'absolu.
C'est pas idiot pour un développeur qui fait du HTML4 ou du HTML5 d'adopter un style syntaxique précis et de s'y tenir... tout en sachant s'adapter à une convention de codage dans un cadre différent (équipe, entreprise, client).

Pour ma part:
- noms de balises et attributs en minuscules;
- double quotes pour les valeurs d'attributs, même si elles ne contiennent pas d'espaces;
- syntaxe <element> pour les éléments à une seule balise (BR, HR, IMG, etc.);
- pas de valeur d'attribut pour les attributs booléens (<time pubdate> plutôt que <time pubdate="pubdate">);
- fermeture explicite des éléments comme P et LI.
Voir http://covertprestige.net/ pour un exemple.
Ce n'est bien sûr qu'un style personnel, susceptible d'évolutions.

Une chose tout de même: je recommande formellement de ne pas utiliser la fermeture implicite de certains éléments (<p>1er paragraphe <p>2e paragraphe), pour les raisons suivantes:
- seule une partie des éléments de HTML5 peuvent être fermés implicitement;
- pour un élément donné (par exemple l'élément LI), l'élément doit être fermé explicitement dans certaines conditions et ne peut être laissé ouvert que dans certaines autres conditions;
- les conditions en question sont propres à chaque élément;
- au final les règles pour la fermeture implicite sont complexes, et servent surtout à décrire l'état de l'art (compatibilité arrière avec HTML4, implémentation dans les navigateurs).
C'est beaucoup de complexité (spécification) pour pas grande chose.

Et oui, il reste important d'avoir un code HTML valide. Ou du moins d'utiliser les validateurs comme outil pour corriger des erreurs de code, que cela permette d'arriver à un code complètement valide ou pas (il y a des cas de figure où on gardera un code invalide pour des raisons précises).