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.