#xhtml

    • Le W3C n’œuvre plus exclusivement pour un web ouvert. C’est terminé. Je pense que l’ouverture du web, l’interopérabilité, est condamnée à moyen terme. Vous vous demandez comment, comment le W3C a pu accepter ça ? C’est simple : regardez la liste de ses membres.
      Bien plus criant : Regardez qui sont les éditeurs de cette nouvelle norme du W3C : David Dorwin (Google), Adrian Bateman (Microsoft), Mark Watson (Netflix). Vous leur faites vraiment confiance pour œuvrer pour le bien de tous ?
      http://sebsauvage.net/rhaa/index.php?2013/10/03/10/09/24-le-w3c-enterine-les-drm

      Voir la position de l’EFF (qui rappelle l’épisode du #xhtml il y a quelques années, discuté là http://seenthis.net/messages/180689#message180692 ) :

      the W3C has now accepted “content protection”. By discarding the principle that users should be in charge of user agents, as well as the principle that all the information needed to interoperate with a standard should be open to all prospective implementers, they’ve opened the door for the many rightsholders who would like the same control for themselves.
      https://www.eff.org/deeplinks/2013/10/lowering-your-standards

      #DRM-HTML

    • Le W3C a plus l’habitude de geeker sur des points de techno que de faire de la communication politique, du coup je ne peux pas dire qu’il y a grand chose de publié qui explique un peu mieux les choses. Laissez-moi essayer de donner quelques éléments ici.

      Premièrement, il n’y a absolument rien de nouveau sur le sujet ces derniers jours. Le groupe HTML a vu un renouvellement de sa charte (le document qui encadre ce sur quoi le groupe travaille) mais ce renouvellement ne change en rien la donne sur le travail EME.

      La seule objection reçue à la charte sur le sujet DRM (je ne peux pas dire laquelle car les retours des membres sont confidentiels, je vous laisse libres de deviner qui) demandait à ce que EME ne soit qu’implicitement dans le scope au lieu d’explicitement. Cette demande a été rejetée. À titre personnel je suis d’accord avec le rejet — je trouve que ça serait hypocrite.

      En dehors de ça, la situation est exactement la même qu’avant le renouvellement. Toute agitation est donc sur un non-évènement. (Même si elle peut être justifiée par ailleurs.)

      Deuxièmement, le W3C n’a en rien ratifié la notion de DRM dans la stack Web. Depuis le début le travail sur EME a été accepté à titre exploratoire et rien ne garanti que ce qui en résulte sera accepté comme norme.

      Aussi, quand l’EFF pointe qu’un Community Group a été créé pour travailler sur la protection du code source — donc sur une autre forme de DRM — c’est de la désinformation (que j’imagine simplement erronnée plutôt que malveillante). Le principe des CGs est précisément que tout le monde peut en créer un (tant que ça a un rapport avec le Web) et que ça n’engage en rien le W3C. Il suffit que 5 personnes s’y intéressent pour qu’un tel groupe soit ouvert. Par exemple, je viens de proposer : http://www.w3.org/community/groups/proposed/#web-copyright.

      Maintenant, il va de soi que comme beaucoup de ceux qui sont parties prenantes de la communauté Web en général et de celle qui entoure le W3C en particulier, je n’aime pas la DRM. Mais ce qui m’intéresse c’est de sortir du « bouh c’est pas bien, ouhlala c’est mal » et de voir ce qu’on peut faire de concret. Je ne dis pas ça pour être méchant mais plein de gens qui se plaignent derrière leurs claviers sans rien faire d’autre ça a rarement changé quoi que ce soit.

      Plus généralement, la plupart des discours sur le sujet se posent la mauvaise question. Pour moi il y a deux questions clés, lesquelles sont liées à l’action. D’une part, si EME va arriver de tout façon que ça soit un standard ou pas (ce qui est très vraisemblable), est-il possible pour le W3C d’amoindrir le mal d’une façon ou d’une autre ? Ce n’est pas une perspective plaisante, mais c’est l’option « à minima » et je ne pense pas qu’il soit intelligent de l’exclure par avance.

      D’autre part, et c’est l’option « à maxima », je pense que la situation légale est telle qu’on risque fort de se retrouver avec du DRM dans la stack, et pas seulement pour la vidéo — les ebooks et les apps pointent leurs nez sur le sujet. Et si ça arrive, quoi que le W3C fasse n’y changera rien dans les grandes lignes (ça fait 12 ans que des gens essaient de faire entrer le DRM au W3C, ça n’a pas empêché l’arrivée de EME). L’action a conduire n’est donc pas au niveau technique ou des standards, mais se situe au niveau politique. Oui, c’est plus dur, mais en fait c’est la seule voie plausible au long terme.

      C’est pour ça que j’enjoindrais tout ceux qui se plaignent d’EME aujourd’hui à consacrer ne serait-ce que 10% de l’énergie mise à râler à essayer de trouver une solution plus large au problème, et surtout plus pérenne, au travers d’une approche politique. Sans ça, les pressions industrielles sont telles qu’aucun organisme de standardisation — et aucun navigateur même avec les meilleures valeurs, regardez la position de Mozilla — ne pourra rien changer.

    • Oui #merci beaucoup :

      L’action a conduire n’est donc pas au niveau technique ou des standards, mais se situe au niveau politique. Oui, c’est plus dur, mais en fait c’est la seule voie plausible au long terme.

      ma tentative de résumé de la chose :

      Le W3C trahit-il son esprit d’origine ? #EME
      https://fluxetfixe.wordpress.com/2013/10/12/w3c-trahit

      Une itv de Berners-Lee :
      http://blogs.computerworlduk.com/open-enterprise/2013/10/tim-berners-lee-on-why-html5-needs-drm/index.htm

      et les seens d’@0gust1 :
      http://seenthis.net/messages/183124
      http://seenthis.net/messages/183166

  • Le principe de robustesse, une bonne ou une mauvaise idée ?

    On attribue souvent le succès de l’#Internet, et notamment sa résilience, au principe de robustesse. Ce principe, attribué à #Jon_Postel, s’énonce « Be conservative in what you do, be liberal in what you accept from others. ». Que veut-il dire ? Était-ce un bon principe d’#ingéniérie à l’époque ? Et l’est-il toujours aujourd’hui ?

    http://www.bortzmeyer.org/principe-robustesse.html

    • 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.

    • 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.

    • 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...