Du code HTML des livres numériques

J’explore le code des ePub et je tombe sur des choses étranges : du code que je n’aurai jamais accepté d’aucun intégrateur web avec qui j’ai travaillé jusqu’à présent, même d’un débutant.

Je ne parle pas des livres extrêmement mal faits mais bien de livres dont l’ensemble du code fait croire qu’il a été produit par des outils intelligents, voire nettoyé à la main par quelqu’un dont c’est le métier.

Ces livres là continuent à avoir un code qui me semble étrange. Les moteurs de rendu des logiciels de lecture sont parfois mauvais. Il semble que les astuces et compromis se doivent d’être bien plus nombreux que ceux sur nos navigateurs web. Alors je demande à ceux dont c’est le métier, pouvez-vous m’éclairer un peu sur ce qui est normal ou pas, habituel ou pas, jugé de qualité ou pas ?

Voici quelques exemples de ce que j’ai trouvé :

Images

<img alt="image" height="97%" src="…" style="width: 373px; height: 560px; ">

La couverture a pour texte alternatif « image ». Dans d’autres exemples j’ai trouvé « couverture », « cover » et même « image.png ». Malgré mes recherches je n’ai trouvé aucun livre qui ait un texte alternatif vide ou contenant le titre du livre (qui sont les deux choix que j’aurai discuté dans le cadre d’un site web, suivant le contexte).

Dans d’autres images j’ai parfois trouvé des textes alternatifs vides mais rarement. Le plus souvent c’est « image », « carte », ou « illustration ». Je n’ai cherché que sur un échantillon mais d’origine diverse : Aucun texte alternatif présentant une réelle alternative – même limitée ou tronquée.

Sachant que le livre numérique offre potentiellement une réelle avancée sur l’accessibilité des textes aux personnes malvoyantes, je me dis qu’on gâche là une superbe opportunité.

<img alt="cover" height="100%" src="…">

Dans mes explorations j’ai vu pour un petit quart de livres contenant certaines illustrations avec un texte alternatif anglais. « Cover » revient assez souvent. Là, il y a vraiment un laissez-faire que je ne peux pas comprendre quand le code est nettoyé à la main.

<img alt="image" height="97%" src="…" style="width: 373px; height: 560px; ">

Vient ensuite, et je l’ai retrouvé sur plusieurs sources différentes, un code qui m’étonne vraiment : un attribut hauteur spécifié à 93, 95 ou 97%, cumulé à une CSS qui précise un nombre de pixel exact. J’ai même vu un 562.255px traîner, c’est dire l’exactitude – et mon incompréhension. Spécifier une taille relative en attribut ou une taille fixe en style peuvent se comprendre indépendamment l’un de l’autre. Je n’arrive cependant pas à concevoir dans cas il peut être pertinent d’associer les deux.

Titres

Les titres c’est le domaine qui devrait être simple. On fait du <h1>, du <h2>, et ainsi de suite. Pour des raisons de compatibilité je peux comprendre qu’on ait une hiérarchie qui ne soit pas la hiérarchie théorique, mais…

<h1 id="Couverture" title="Couverture"></h1>

Je vois souvent des titres vides, tout simplement. J’aurai pu le comprendre pour des raisons de compatibilité pour des entêtes de chapitre mais à y regarder de plus près j’ai une part très significative de livres qui n’ont aucune balise <h1> du tout, et qui fonctionnent très bien partout où je les ai essayé. Pourquoi ces titres vides ?

<p><a id="a2"></a><span class="t1"><b>Chapitre I – </b></span><span class="t1"><i>…</i></span></p>

À l’inverse, j’ai donc bien des livres où les titres sont de simples paragraphes mis en gras avec une police de caractère spécifique. Je ne comprends pas.

<h1 id="PageTitre" title="Page Titre"></h1>

De même, la page de titre est un mystère pour moi. La grande majorité des livres choisissent de ne pas marquer comme titre <h1> le titre du livre, et de réserver ces balises aux titres des sections et des chapitres. Je dois avouer ma grande surprise mais je soupçonne qu’il puisse y avoir une raison vis à vis de la manière de fonctionner de certains lecteurs qui construisent des sommaires automatiques.

<h1 id="PageTitre" title="Page Titre"></h1>
<div>
<span>…</span>
</div>

Sur un livre récent et probablement traité à la main j’ai même trouvé une combo avec une balise titre vide suivie d’un titre sous forme de paragraphe. C’était pour la page de titre (et non un titre de paragraphe).

Et le corps de document

<title>002</title>

Dans la plupart des lecteurs, la balise <title> reste inutilisée, mais tout de même… Une bonne majorité reprend le nom du chapitre en court ou une indication similaire. Quelques irréductibles continuent à simplement numéroter le fichier xhtml, avec de plus un numéro qui ne correspond pas à celui du chapitre. C’est dommage, on se coupe de potentielles réutilisations plus tard dans d’autres contextes.

<html xmlns="http://www.w3.org/1999/xhtml">

Un sur deux ne précise pas la langue du livre dans la balise <html> ou dans la balise <body> (ni aucune autre d’ailleurs). L’information existe peut être dans les métadonnées du livre lui-même, mais il s’agit selon moi d’une erreur si on veut permettre la lecture orale du livre.

<p>&nbsp;</p>

C’est cette marque qui m’a décidé à aller voir plus loin. J’ai l’impression de revenir aux années 2000. Même dans un traitement de texte plus aucun professionnel ne devrait faire de chose pareille, alors chez un éditeur… Je ne connais pas les problèmes de compatibilité des logiciels de lecture mais il y a-t-il vraiment des lecteurs qui ne sauront pas reprendre des règles CSS simples de marge et d’espacement ?

…moi ?</p>

C’est arrivé rarement, et plus exactement je n’ai pas réussi à retrouver de livres présentant ce problème, mais je me rappelle clairement l’avoir rencontré dans mes lectures : des manques d’espaces insécables devant ou après certaines ponctuation, avec des retours à la ligne malheureux. Sur des livres avec un éditeur dont c’est le métier c’est presque inexcusable.

<h1 id="Toc13" title="Treize">TREIZE</h1>

Dernier point relevé aujourd’hui, la présence de titres en lettres capitales, sans utiliser le style CSS dédié à cet usage. Je soupçonne un manque de compatibilité mais je doute quand même : Cette fonctionnalité est plutôt bien implémenté dans les moteurs web depuis longtemps.

Pouvez-vous m’aider ?

Vous allez me dire que je suis pointilleux et qu’on se moque de tout ça, mais je n’ai relevé que ce qui pour moi relève de la faute. Même avec les corrections ci-dessus on reste trop souvent avec un code en excès de <div> et <span>, avec des classes superflues et redondantes un peu partout, avec un mélange étrange et injustifiable de styles en ligne et styles externes.

Bref, je suis pointilleux par nature mais croyez bien que dans ce billet je suis encore loin de la qualité que j’attends d’un intégrateur web avec qui je travaille. Là j’ai l’impression de demander le minimum.

Je suis convaincu qu’il doit exister des raisons à certains de ces choix. Je ne suis donc pas vraiment là pour pointer du doigt, mais pour exposer ma pensée et espérer que vous saurez m’expliquer ces choix ou les contraintes qui ont mené à ces choix, pour que je comprenne et que je reparte moins ignorant que je ne suis arrivé.

Rejoindre la conversation

19 commentaires

  1. Initiative très intéressante ! Peux-tu nous dire quels ont été les livres numériques qui t’ont servi d’exemples ?… Je suis bien conscient que ma question peut être délicate.

    1. Je préfère éviter. L’objectif n’est pas de montrer du doigt, d’autant que ce dont je parle font plutôt partie des bons élèves si j’en crois certains retours comme celui du premier lien.

  2. Quelques remarques rapides :

    * sur l’image de couverture, le code minimal et suffisant est expliqué sur le blog ADE : http://blogs.adobe.com/digitaleditions/2009/03/working_with_the_cover.html

    * sur la lecture orale : ce n’est pas obligatoire avec epub2 (OPS, section 3 « This specification does not require that Reading Systems implement text-to-speech or other read-aloud technology. ») ;

    * sur les lettres capitales : ADE ne comprend pas la propriété ‘font-variant’, qui date de 1996 ;

    * toutes les erreurs de code données en exemple ici sont bien contraires aux « EPUB Best Practices d’Adobe » : « If you have a heading, use the heading element. If you have a paragraph, use a paragraph element, etc. ».

    1. Pour la lecture orale, la spec parle des logiciels de lecture qui ne sont pas obligés de la supporter (mais qui le peuvent, d’ailleurs certains le font). Elle ne dégagent pas du tout les auteurs du livre de faire du code accessible. Au contraire même puisque qu’en signalant que ce n’est pas une obligation des lecteurs, la spec implique bien qu’une partie des lecteurs aura cette possibilité.

      1. à peu près tous ceux qui sont simplement basés sur une intégration webkit directe dans Windows ou Mac. Même s’il n’est pas représentatif, Readium devrait donner tout ce qu’il faut pour un lecteur d’écran par exemple.

        Bon, le fait que l’image de couverture annonce « image » ne rend pas totalement mauvaise l’expérience d’une lecture d’écran non plus, mais ça reste quelque chose que je trouve dommage.

        Ça ne coutait pas cher de mettre au moins un texte alternatif vide. Quelqu’un a quand même passé du temps à remplir gentiment « couverture » ou « image » alors qu’il aurait mieux valu ne rien faire.

      2. D’accord, donc en dehors des machines dédiées. Je connaissais la fonction Read Aloud spécifique à Apple. Je vais reprendre mes fichiers et relire les bases en attendant la sortie « EPUB 3 Best Practices ».

  3. « &nbsp; »
    C’est cette marque qui m’a décidé à aller voir plus loin. J’ai l’impression de revenir aux années 2000. Même dans un traitement de texte plus aucun professionnel ne devrait faire de chose pareille, alors chez un éditeur… Je ne connais pas les problèmes de compatibilité des logiciels de lecture mais il y a-t-il vraiment des lecteurs qui ne sauront pas reprendre des règles CSS simples de marge et d’espacement ?

    Ou alors le qu’on retrouve souvent (en fait, même Sigil le fait comme ça). La simple et bonne raison pour laquelle les devs Sigil ont choisi cette solution étant que &nbsp; ne sera pas converti vers Kindle (alors que le le sera, tout comme les marges définies via CSS). D’ailleurs, Adobe a une documentation « EPUB Best Practices 1.0.3 » au format EPUB qui est bien cachée mais qui annonce clairement que les mises en page pour paragraphes, sauts de ligne, etc. doivent UNIQUEMENT passer par les styles, et pas avec un bricolage HTML, que ce soit   ou . Là, pour le coup, c’est quasiment une faute pro de remplacer par   au lieu de le faire via la CSS si on trouve que n’est pas bon…

    Pour les marges et espacements, oui, il y a des problèmes. Mais il y a des problèmes sur d’autres choses toutes simples comme les images sur ibooks, qui ne seront pas centrées si le texte est justifié dans la CSS (et qu’il faudra donc placer entre balises spans), ou des styles tout à fait standard qui ne passent parfois pas chez Adobe…

    En fait, c’est simple : on parle aujourd’hui de HTML5 et CSS3 pour EPUB3 à venir, le support EPUB « dans la vraie vie » équivaut au web de 1998. Les fabricants et devs se foutent juste de notre gueule, clairement.

  4. On se souvient de l’export de Word vers HTML. Et bien voilà les mêmes enjeux qui arrivent en masse pour les auteurs. Les auteurs utilisent des outils et n’ont aucune connaissance du HTML (et ne doivent pas forcément en avoir une). Le monde de l’édition ne dégage pas encore assez de revenus pour engager des professionnels capables (compétence et temps) de fabriquer des epubs corrects. L’outil Pages de Apple permet de faire des exports… mais malheureusement avec du code pourri.

    En fait, c’est une étude sur les outils de production qu’il faudrait réaliser et de voir sectoriellement qui utilise quoi. La chaîne de production est définitivement faible et coûteuse.

    1. Uniquement du francophone, oui. Du libre de droit (créé main), différents éditeurs (grand, petit, pure player), et j’ai volontairement cherché deux livres de groupes de contrefaçon car j’avais en mémoire qu’ils reprenaient les livres à la main pour les retoucher.

      Je n’ai pas non plus fait une étude scientifique pour autant, j’ai regardé peut être une dizaine de livres en surface, et quatre ou cinq sérieusement seulement.

      Je ne suis donc pas en train de dire « ils sont nuls ces éditeurs ». Je plus là pour embrasser leurs contraintes avant de pousser plus loin.

      1. Les ePubs anglophones sont dans la même veine contrairement à ce que l’on pourrait croire.
        N’oublions pas que la majorité sont vendu via Amazon (format propriétaire et DRM) et Barnes&Nobles (format propriétaire et DRM), c’est donc transparent pour des utilisateurs coincé dans leur éco système

  5. Le   ne devrait pas passer. Sur iBooks, un ePub avec ça va générer des erreurs et l’utilisateur en sera averti par un gros rectangle jaune en tête de livre ou de chapitre (en fonction du découpage) avec la liste des   détectés ainsi que la ligne dans le HTML sur laquelle ils se trouvent.

    J’ai eu souvent ce problème sur mes premiers ePubs de tests exportés d’Adobe InDesign et analysés, puis modifiés main sous Sigil. InDesign ajoute des   quand on importe un document Word sans styles prédéfinis et que l’on saute deux lignes pour faire une délimitation entre deux paragraphes par exemple. Avec l’utilisation des styles ça ne devrais pas arriver (au pire, on aura une balise vide si l’auteur ne sais pas gérer les marges des styles et que l’intégrateur dans InDesign ne fait rien de plus pour le corriger), mais il est possible qu’un coquille reste.

    A noter que comme dit plus haut, le   affiche des erreurs sous iBooks, mais que de façon assez surprenante, il m’a été possible de soumettre un livre avec une telle erreur via leur outil iTunes Producer et le livre a été publié sans problèmes… (heureusement qu’ils permettent la mise à jour).

  6. Je crée des livres numériques pour des éditeurs. Je suis passée à l’epub après des années de web et un peu d’expérience print, je fais mon code à la main et j’essaye au maximum de faire du code propre, sans superflu et sans incohérences. Je fais parfois des erreurs comme tout le monde et je me doute qu’en cherchant on trouvera toujours un détail à reprendre dans mes livres, mais *jamais* je ne rendrais du code à un client comme j’en ai vu dans certains livres que j’ai acheté (la plupart, même). D’ailleurs ça me démange tellement que je refais quasi systématiquement le code des livres que j’achète avant de les lire.

    Malheureusement, comme vous le dîtes, on voit beaucoup de n’importe quoi, c’est même assez choquant quand il s’agit de livres édités par des professionnels. Je pense que cela vient du fait que la plupart de ceux qui se sont reconverties en édition numérique n’ont aucune ou peu d’expérience avec le html / css, ignorent donc des principes de base derrière les règles pour valider un fichier, et n’ont souvent qu’une connaissance partielle même des balises qui servent à créer des livres.

    Ainsi donc l’attribut alt est nécessaire sur chaque image pour valider le code, mais selon le contexte, il vaut en effet parfois (souvent) mieux le laisser vide, et surtout cela n’a aucun sens d’y indiquer « image », ni même « couverture » puisque cela doit être indiqué dans les meta-données. Par contre pour l’image de couverture, y indiquer le titre du livre a du sens.

    De même je vois beaucoup d’informations de mise en forme qui devraient être précisées dans les css, et non pas dans le code html directement, comme la taille des images. Les tailles du style « 562.255px » sont des vestiges d’une conversion automatique depuis un logiciel de traitement de texte ou de mise en page papier et devraient être reprises.

    Les titres vides sont une aberration qui semble se généraliser, pourtant j’ai du mal à y voir une quelconque justification. Soit il y a un titre, auquel cas il faut le mettre dans la balise approprié, ne serait-ce que pour respecter une structure sémantique du document (sans parler de la table des matières). Si il s’agit d’un titre que l’on ne souhaite pas inclure dans la table des matières, il est possible de l’en exclure sans recourir à des bricolages de code (Sigil le fera tout seul même, il suffit de décocher une case ou de rajouter l’attribut dans la balise). Si l’on a une image que l’on souhaite faire figurer dans la table des matières (la couverture du livre par exemple), il suffit de mettre l’image directement dans la balise h, et de rajouter un attribut « title » pour définir le texte à afficher dans la table des matières (et en l’occurrence, de penser à renseigner l’attribut « alt » aussi). En aucun cas il n’est justifié de créer une balise h vide suivi du titre dans une balise p. Tout au plus, créer une balise h normal avec un titre que l’on souhaite faire figurer dans la tdm sans l’afficher dans le livre, et masquer ce titre avec une règle css (« display: none » par exemple), mais ça me parait un cas relativement rare.

    Les balises title ; selon le contexte, le plus approprié sera le titre du livre ou bien du chapitre en cours.

    La langue du livre : il s’agit de l’une des trois méta-données obligatoires pour un epub valide, il est donc superflu d’indiquer cela à nouveau dans le code html. Même en supposant que l’epub puisse être lu ailleurs que sur une liseuse, un moteur de rendu qui gère l’epub doit pouvoir lire ces méta-données et cela devrait être suffisant pour des fonctionnalités de synthèse vocal.

    Les balises p avec un espace insécable au lieu de gérer les marges dans les css, ainsi que l’absence de l’insécable pour la ponctuation ; du mauvais code, tout simplement.

    L’usage de capitales directement dans le code sans utiliser un style de transformation de texte est malheureusement dû au fait que les moteurs de rendu ne sont pas encore capables de gérer ce style, pourtant assez basique.

    C’est vrai qu’en parallèle au code automatisé ou simplement mauvais, il y a le problème des lacunes des moteurs de rendu actuels (même pour des styles basiques, comme text-transform). En plus des lacunes il y a les bugs divers et qui varient de l’un à l’autre, nous obligeant à tester sur un maximum de supports différents pour vérifier le rendu, le summum étant les implémentations propriétaires (iBooks en est jusqu’ici champion) qui obligent à utiliser des hacks à la IE6 des années noires de la guerre des navigateurs (que nous revivons version ebooks aujourd’hui, merci Apple !). Les span vides un peu partout ? C’était un bug d’iBooks qui refusait de tenir compte de la règle pour l’alignement du text (ferré à droit, centré) autrement (aujourd’hui corrigé, encore heureux, mais il en reste bien d’autres).

    Tout cela étant, optimiste, je me dis que forcément avec la généralisation du numérique on verra forcément des améliorations, autant du côté du code que du rendu. J’espère juste qu’elles ne tarderont pas trop.

    1. On est bien d’accord Zelda :)

      La langue du livre va commencer à prendre son importance avec l’apparition des dictionnaires, surtout dans un livre multi langue. Et si la gestion de la césure se développe également, ce sera une nécessité.

      Les balise   ou peuvent éviter des soucis de conversion vers MOBI. Kindlegen et autres ont parfois des soucis avec la CSS interpara, allez savoir pourquoi…

  7. Bien bien en retard mais comme c’est toujours d’actualité (erf), quelques pistes.

    Spécifier une taille relative en attribut ou une taille fixe en style peuvent se comprendre indépendamment l’un de l’autre. Je n’arrive cependant pas à concevoir dans cas il peut être pertinent d’associer les deux.

    Mobi 7.

    KindleGen te met automatiquement les images à 100 % de width, donc, pour conserver les dimensions de l’image, il faut les indiquer dans le HTML — par contre, de mémoire, il faut les indiquer avec les attributs width et height et pas avec des styles inline pour qu’ils soient pris en compte… mais je peux me tromper.

    Pourquoi ces titres vides ?

    Je devine que certains le font pour conserver l’alignement vertical (visuel) du premier paragraphe des chapitres (marge sup trop « chiante » à calculer).

    Sinon, une explication plus logique pourrait être que… comme ça sort d’InDesign ou d’un traitement de texte et que le découpage XHTML se fait par rapport à un style ou à un niveau de titre, bah tu mets le style ou le niveau de titre sur une ligne vide pour que le chapitre soit mis dans un autre XHTML lors de l’export.

    De même, la page de titre est un mystère pour moi. La grande majorité des livres choisissent de ne pas marquer comme titre le titre du livre, et de réserver ces balises aux titres des sections et des chapitres. Je dois avouer ma grande surprise mais je soupçonne qu’il puisse y avoir une raison vis à vis de la manière de fonctionner de certains lecteurs qui construisent des sommaires automatiques.

    Ouais, je pense que c’est à cause des solutions qui construisent des sommaires automatiques, même pas des lecteurs, et ce pour ne pas se retrouver avec le titre du livre dans toc.ncx.

    À l’inverse, j’ai donc bien des livres où les titres sont de simples paragraphes mis en gras avec une police de caractère spécifique. Je ne comprends pas.

    Pour l’anecdote, je me suis rendu compte il y a peu que souvent, ce genre de truc sort des solutions basées sur XML. Ce qui tend à confirmer la maxime (dont je ne connais plus l’auteur) : « XML, beaucoup d’évangélistes pour le pousser, très peu de spécialistes pour le maîtriser. » Je tendrais même à dire qu’il y a quelque chose qui ne va pas du tout dans le monde du XML parce que les fichiers les plus dégueulasses que j’ai trouvés ces derniers mois sortent systématiquement de solutions XML…

    Quelques irréductibles continuent à simplement numéroter le fichier xhtml, avec de plus un numéro qui ne correspond pas à celui du chapitre. C’est dommage, on se coupe de potentielles réutilisations plus tard dans d’autres contextes.

    Regarder du côté des outils de prod plutôt, je pense.

    Je ne connais pas les problèmes de compatibilité des logiciels de lecture mais il y a-t-il vraiment des lecteurs qui ne sauront pas reprendre des règles CSS simples de marge et d’espacement ?

    Oui. Il y en a même qui ne supportent aucune règle CSS simple encore aujourd’hui — et qui sont téléchargées plus de 5 millions de fois, coucou Android —, ce qui pousse certains à demander que l’IDPF mette en place une certification pour les solutions de lecture EPUB (cf. Editech 2014).

    Tu as également des apps qui overrident les marges sur les paragraphes. Or, le saut de ligne à beaucoup de sens en Français (parce que le concept de paragraphe est très particulier en Français et largement différent du concept dans les autres langues), donc le perdre fait perdre du sens.

    La question n’est pas de savoir si p — nbsp — p est du mauvais code ou pas. C’est juste que tu n’as absolument pas le choix.

    Par contre, nous sommes OK que faire du p — nbsp — p pour faire des marges de page, c’est pas du tout à faire.

    des manques d’espaces insécables devant ou après certaines ponctuation, avec des retours à la ligne malheureux.

    Et c’est presque la norme…

    Par contre, pour info, avec EPUB 3 et ses doctypes externes qui se sont envolés, il y a une petite problématique non négligeable : dans nombre d’outils, l’entité HTML chiffrée de l’insécable &#160; est transformée en espace sécable, et ce bug est très répandu — j’ai déjà perdu des milliers d’insécables sur un ouvrage comme ça, raison pour laquelle je me suis intéressé à ce problème.

    Dernier point relevé aujourd’hui, la présence de titres en lettres capitales, sans utiliser le style CSS dédié à cet usage. Je soupçonne un manque de compatibilité mais je doute quand même : Cette fonctionnalité est plutôt bien implémenté dans les moteurs web depuis longtemps.

    Mais les mecs de chez Adobe n’ont pas daigné intégrer cela dans leur RMSDK — ça vient d’arriver avec l’implémentation de Readium…

    Même avec les corrections ci-dessus on reste trop souvent avec un code en excès de et , avec des classes superflues et redondantes un peu partout, avec un mélange étrange et injustifiable de styles en ligne et styles externes.

    Les outils, encore et toujours. Suffit par exemple de laisser InDesign exporter tout seul comme un gland et tu te retrouveras avec quasiment tout ce que tu as listé — et Dieu sait que beaucoup de problèmes pourraient être réglés si Adobe ne persistait pas sur son discours « c’est du WYSIWYG, on va pas vous emmerder en vous imposant le panneau de balisage d’exportation à l’export EPUB » (même si ça réglerait déjà une bonne grosse moitié du problème…).

    Je ne vais pas dire que c’est la faute des outils, parce que c’est plutôt trivial de repasser derrière et d’améliorer quand tu connais ne serait-ce que les bases HTML et CSS mais force est de constater que la volonté des créateurs d’outils à persister sur le WYSIWYG aura fait énormément de mal à l’écosystème EPUB. On se retrouve quand même aujourd’hui avec des solutions de lecture qui se calent sur les exports typiques de ces outils pour appliquer des overrides, améliorer visuellement les fichiers et régler des incompatibilités (texte noir sur fond noir en mode nuit par exemple) mais, du coup, les mecs qui se cassent à faire des fichiers corrects se retrouvent comme des glands à devoir hacker ici et là pour éviter les overrides.

    Bref, comme le proposait Baldur Bjarnason il y a 2 ans, désactivons CSS dans les apps et marrons-nous un bon coup en voyant 90 % des fichiers brûler dans les flammes des div et des span.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par OVH SAS, joignable par téléphone au +33 (0)9 72 10 10 07 et dont le siège social est au 2 rue Kellermann, 59100 Roubaix, France.