[uZine 3] W3C go home !

#mozilla #https

Et relire aussi :

W3C go home ! - (c’est le HTML qu’on assassine)

►http://www.uzine.net/article1979.html

#résilience #force & #robustesse (et plus bas : #html #xhtml #W3C)

Les premiers navigateurs acceptaient n’importe quoi, donc les webmestres ont pris l’habitude d’écrire du HTML sans faire attention à la syntaxe

On peut penser que en partie cela qui a contribué au succès de la plateforme ; on pouvait bricoler, c’était très tolérant, et marrant. Si les premiers navigateurs avaient été très très chiants, il n’y aurait peut-être pas eu autant de webmestres… voire plus du tout, si une autre techno plus cool avait pris le dessus. C’est une des leçons du succès de facebook ou tumblr : bien plus faciles à utiliser qu’un hébergement perso + FTP.

Et aucune autorité (et certainement pas le W3C, dans ce cas, où l’IETF pour les protocoles réseau) ne peut décider autrement, elles n’ont ni le pouvoir, ni l’envie.

Bien sûr qu’elles en ont eu l’envie : XHTML était l’exemple type, notamment quand il a été décidé qu’un navigateur lisant une page servie en XHTML, devrait afficher un message d’erreur incompréhensible à la moindre imperfection technique.

De ce point de vue, le passage à HTML5 a signé la déroute totale de cette volonté de contrôle (justement dénoncée par @arno il y a quelques centaines d’années®), et le retour à la raison pragmatique.

=> “W3C Go Home”
►http://www.uzine.net/article1979.html

@fil est donc l’exemple typique de l’utilisateur qui a abusé du soi-disant « principe de robustesse » pour être libéral à la fois dans ce qu’il reçoit (peut-être, mais plus probablement, du fait du lazy programming, cela plantera) et libéral dans ce qu’il envoie (a.k.a. j’envoie n’importe quoi et bonne chance aux autres).

@x_cli libre j’ai passé un nombre d’heures assez conséquent à essayer de ne pas tomber dans l’ornière que tu décris, et à reprogrammer tous les machins pas bien standards de #SPIP pour produire un résultat conforme… Si j’ai échoué, je t’en prie, envoie tes sarcasmes.

Mon argument ici est que, si on avait suivi la règle d’airain du « ça plante si c’est pas du XML bien formé » proposée par XHTML, on aurait moins de choses sur le net car on aurait découragé bon nombre d’amateurs. Je me réjouis que HTML5 ait balayé tout ça.

@fil Tant qu’on parle d’HTML, tout va bien, au pire, ça fait juste un site moche. Mais au final, un site moche parce qu’on a codé comme un pied n’est-il pas une forme à peine plus subtile du bon vieux message d’erreur rouge « code de merde » ?

Je ne connais pas ton oeuvre, mais une chose est certaine : coder proprement est dans la règle de robustesse (envoi strict). C’est accepter n’importe quoi qui fait débat (être libéral ou non, accepter les erreurs accidentelles).

Coder comme un mal-propre et envoyer n’importe quoi, c’est juste être mauvais et nocif/dangereux pour l’écosystème.
De ce fait, oui tout le monde devrait valider ses envois (pages HTML) avec un validateur strict comme celui du W3C (ou équivalent suivant le contexte).

Simple question pratique : s’il n’y a pas de message d’erreur bloquant et interdisant de faire n’importe quoi, alors où est la chance d’apprendre qu’on fait les choses mal et de s’améliorer ? En ce sens, je suis partisan de n’accepter que ce qui est parfait en entrée, afin de tirer le niveau vers le haut et non vers le bas. Et mon dieu ce qu’il est bas, le niveau de nos développeurs moyens.

Très rigolo, le texte d’@arno cité par @Fil, avec notamment la charge contre le Web de données (« je ne veux pas qu’on réutilise mon contenu »).

Je pense surtout que le débat n’a pas trop de sens aujourd’hui. J’avais cité HTML comme un exemple historique. Aujourd’hui, ce débat spécifique est dépassé car peu de gens (à part @Fil) font de l’HTML à la main (même moi, j’ai arrêté).

Mais oui, on pourrait très bien avoir de bons outils à visée pédagogique, expliquant par un signal discret que la page n’est pas conforme. Ca permettrait aux gens d’apprendre.

Il y a des sites moches codés proprement, et des sites jolis avec du code de merde, ça n’a absolument rien à voir.

L’autre jour, pour la petite anecdote, j’étais à un atelier du W3C, où des slides (traitant d’accessibilité !), étaient diffusées en petits caractères rouges sur un fond blanc… Selon ton bon conseil, j’aurais dû me lever et interdire au conférencier de continuer à nous parler ? Lui mettre un coup de latte dans les tibias ?

Pour moi l’important avec le Web est que tout un chacun puisse s’exprimer. Décider de mettre à plat un site pour des raisons techniques soi-disant supérieures, c’était aller à l’encontre de cet objectif, et in fine réserver l’expression aux gens qui maîtrisent l’outil, des gens comme toi quoi.

@stephane ton site programmatique est valide, bravo, mais si on suit les liens de la marge, on voit rapidement des pages faites à la main et qui ne passent pas la validation. Et bien : on les voit. Tant mieux !

L’argument « je ne veux pas qu’on réutilise mon contenu » a autant de sens que d’interdire le clic droit sur les images avec du javascript. Séparer les données du contenu est juste la même bonne vielle pratique de design logiciel qu’on appelle MVC et qui exporte le côté V au consommateur (et qui a de multiples avantages, à commencer par pouvoir se passer de refaire toute l’interface M->V lorsqu’on porte un site sur mobile).

Sinon, je suis d’accord que peu de gens font du HTML à la main. En revanche, beaucoup de développeurs web le font, à commencer par ceux qui sont spécialisés dans le DOM, le javascript, et l’actionscript si complexes qu’on en arrive à créer un nouveau métier (les développeurs coté-clients). Et ces développeurs là, vu que c’est leur métier, n’ont aucune raison de ne pas se manger des messages d’insultes de la part d’un compilo, tout comme le fait n’importe compilateur de n’importe quel langage système, afin de s’améliorer et faire des programmes corrects (qu’ils sont payés pour faire).

Un dernier mot en réponse à @x_cli, ça ne me semble pas une bonne pratique de mélanger les tests et les situations de fonctionnement réel.

@stephane : on ne dit plus robustesse de nos jours, on dit #antifragile. ▻http://www.lesbelleslettres.com/livre/?GCOI=22510100181870

On ne peut pas vraiment remettre en cause le principe sur le constat que certains mauvais élèves ne l’appliquent pas (en n’étant pas rigooureux eux-mêmes). Comme tous principes, c’est un but à viser, et il reste tout à fait valable à mon avis. Très peu de gens dans l’industrie (informatique, télécoms) mettent en application ce précepte, en particulier en France. Il y a des raisons culturelles à cela, je pense.

@x_cli :

Et ces développeurs là, vu que c’est leur métier, n’ont aucune raison de ne pas se manger des messages d’insultes de la part d’un compilo, tout comme le fait n’importe compilateur de n’importe quel langage système, afin de s’améliorer et faire des programmes corrects (qu’ils sont payés pour faire).

Dans un monde théorique, je veux bien, le problème est qu’il n’y a pas de compilateur (ou plutôt interpréteur) unique du html (et surtout du css et du javascript), donc les développeurs web auront plutôt tendance à développer jusqu’à ce que « ça marche » sur les navigateurs cibles et non pour le pur respect de normes. Notons il est vrai que les différences entre navigateurs se sont considérablement réduites mais on n’est pas encore au stade où respecter les normes du W3C suffirait a ne pas tester chaque rendu de chaque navigateur, sans compter que tout le monde n’a pas la dernière version installée sur sa machine. Quoiqu’il en soit, les normes introduites par XHTML étaient inutilement complexes à mon sens et le HTML5 a tout de même simplifié les choses.

Personnellement j’aurais un autre point de vue face à son principe, à son application plus ou moins heureuse, et la conclusion que j’entrevois.

A mon sens ce principe est excellent pour les protocoles réseau (je ne vois aucun contre-exemple mais quelqu’un peut toujours en trouver un).

En revanche dans le domaine de l’applicatif, (e.g. html cité par Stephane Bortzmeyer) il conviendrait d’être effectivement moins libéral pour ce que l’on reçoit.

La différence est de nature et aussi d’objectif.

Nature :

un protocole de communication contrairement à une application n’est pas un but en soit, il faut pouvoir echanger des données pour pouvoir aller plus loin vers le service rendu ou à rendre.

Combinatoire de contact (ou « promiscuité »)

dans le réseau la combinatoire des implémentations différentes est moindre que coté applicatif.

Coté applicatif le nombre et la diversité de connexion est beaucoup plus large,

voila pourquoi selon moi il faut une certaine rigueur dans la réception pour assurer un fonctionnement correct.

enfin c’est ce que je pense humblement et partage non moins humblement...

Pas d’accord. Comme je l’ai déjà fait remarquer, il n’y a pas xhtml. Alors que je me souviens qu’on a subit une imposition du XHTML juste sidérante (du simple fait d’autofermer des balises, tous les problèmes de la planète allaient être résolus).

En revanche, dans ce graphique, du logo HTML5, ça on en bouffe. Ce qui me fait penser qu’on est à nouveau entré dans une période de pensée magique, simplement HTML5 remplace XHTML.

Hum, Arno* il me semble que c’est un vieux débat... en son temps n’avais-tu point pesté contre ces fichus emmerd.. du W3C et leurs feuilles de styles, alors que les <table>, ça c’était du web ;-)))
Mais il me semble que le débat entre les webdesigners et les normalisateurs a de réels enjeux. On a écrit un papier avec un collègue là dessus il y a deux ans : « Évolutions de l’architecture du web et des documents
numériques ».
Tiens, il n’est en ligne nulle part. Va vraiment falloir que je fasse un site ;-(((

Hervé, je ne vois pas l’intérêt, dix ans après, de continuer à me faire écrire ce que je n’ai pas écrit :
►http://www.uzine.net/article1979.html

Quand je le relis, évidemment il y a des approximations, mais je défendrais encore la plupart des arguments aujourd’hui. Le fait qu’aujourd’hui on fasse un graphique qui oublie XHTML pour survendre HTML5 étant un argument parmi d’autres en faveur de ce très vieux texte :-)

Et toujours ce non-dit horripilant :
►http://seenthis.net/messages/32064

Arno*, si tu savais comme j’en ai bavé avec ce « vieux » texte. Tous mes étudiants se le refilaient et riaient devant moi ouvertement car tu prenais le contrepied exact de ce que nous essayions de leur apprendre. C’était devenu leur bannière pour réfuter tout ce que nous disions sur HTML.
Je maintiens que le côté « loosy » de HTML n’est pas ce qui lui va le mieux au teint. Si on veut des navigateurs légers (des ebook readers par exemple, ou des systèmes embarqués) il faut du code solide pour ne pas avoir à détricoter les choses à l’arrivée.
Et puis comme enseignant, le DOM, la logique de l’arbre du document composé de fragments cohérents (i.e. avec des balises fermantes), c’est plus explicite que le recueil de trucs et astuces qu’il y avait auparavant.
Mais je partage aussi ton point de vue sur les webdesigners, qui choisissent volontairement la simplicité. Mon mot d’ordre a toujours été KISS : Keep It Simple Stupid.
Il y a beaucoup de choses à reprocher à la hype HTML5 (j’ai fait passer un papier que j’ai trouvé intéressant là dessus la semaine passée). Mais l’enjeu reste déterminant. Notamment quelle sera la place du navigateur dans la recomposition des forces médias sur le web.
Seenthis, et ses multiples outils réseaux, ses API et son interface en constant progrès est un merveilleux exemple du web qui se construit. Et je t’en suis très reconnaissant (et aussi un peu jaloux, tant je trouve ça bien ;-)
Bon, faut juste que je trouve cinq minutes (heures, jours, semaines ?) pour faire un site et placer mes papiers pour qu’on puisse faire des liens. Tu pourrais suivre le fil de ma pensée, qui n’est pas si éloignée de ce que tu dis, mais qui ajoute simplement la rigueur comme une corvée qui enrichit la manière de penser le web. Mais je m’occupe trop des livres des autres pour avoir le temps.

Personnellement je trouve que XHTML c’est plus facile à apprendre que du HTML à la con mal fermé. Et c’est aussi plus facile à parser. Et on comprends mieux le DOM du coup. Bref ça simplifie les choses. Maintenant si quelqu’un veut faire du HTML 4 pas XML-compliant, je m’en fout un peu tant que j’ai pas à reprendre son code ^^

HTML5 est par contre l’exemple typique de la spéc faite par des professionnels voulant tout compliquer, à l’encontre du web et des amateurs, et au seul profit des commerciaux. C’est la raison pour laquelle j’ai claqué la porte du HTML-WG qui est une usine à perdre du temps sur une spéc immonde.