7 commentaires sur “Réponse à « Du code HTML… »

  1. Merci pour la réponse. Ça m’aide à mieux comprendre.

    Pour le texte alternatif des images, ça reste du détail mais je trouve ça contradictoire avec l’idée que les risquent d’être lus maintenant qu’on importe les epub hors des appareils physiques, ou que les xml:lang sont utiles pour les lecteurs oraux.

    Pour moi l’avenir des epub est bien d’être un simple conteneur qui pourra être interprété sur le web aussi facilement que les documents web d’aujourd’hui. Je ne vois pas pourquoi on ne diffuserait pas des epub au lieu des PDF demain pour tout plein d’usages. Du coup je ne veux pas les restreindre à ADE et iBooks (pas plus que je n’accepte les pages web qui se contentent de vérifier que ça passe sous les navigateurs web classiques).

    Sur les vides j’avais pensé à un truc comme ça, mais du coup ne devrait-on pas plutôt améliorer les outils pour éviter une telle balise, voire inciter à faire la TOC à la main ?

    Visiblement on a des outils qui sont un peu meilleurs que ceux du web il y a 10 ans, et des pratiques légèrement meilleures aussi, mais j’ai vraiment l’impression de revivre le combat qu’on a mené il y a 10 ans auprès des intégrateurs web, et qu’on mène encore aujourd’hui pour faire abandonner la compatibilité avec les lecteurs qui imposent des bouts de scotchs limitant l’interopérabilité.

    Ça a été long, difficile, et nous n’y sommes pas totalement arrivés. Le problème c’est qu’entre temps les attentes ont aussi évoluées. Si le livre numérique explose en usages comme je l’espère, ces livres imparfaits pourront bien devenir des freins à l’innovation.

    • L’évolution de l’ePub en dehors de ADE est assez récent, on va devoir repenser une partie du code en fonction de ce futur développement probable.

      Faire les TOC à la main incite justement à « oublier » les balises (ce qui est le cas dans trop d’ePub), donc que les imprimeurs électroniques apprennent d’abord à correctement balisé les titres avant de passer à une autre méthode 😉

      Les bouts de scotch, c’est tout à fait ça. Quand on imagine qu’il faut un vide sinon iBooks ne lira pas convenablement les attributs des titres, débile…

      Pour l’instant mon combat c’est les éditeurs et leur code, mais il est vrai qu’un autre combat existe : standardiser les outils de lectures !!!

  2. Notons également qu’une partie des mauvaises pratiques de code peut être résolue avec de simples rechercher/remplacer. On peut par exemple remplacer [espace]? par [ ]? et autres joyeusetés pour les éléments typographiques dont les éditeurs ont l’habitude (points de suspension, points virgules…).
    La structure du code des ePub n’est pas si complexe que cela, pour peu que l’on veuille y jeter un oeil, et je suis persuadé que si les éditeurs ou leurs prestataires prenaient le temps de bien définir les CSS au moment de l’établissement de l’ePub, le code serait plus facile à gérer et plus propre.
    Néanmoins, on achoppe ici sur une habitude qui a la vie dure : la rétivité au changement, où éditeurs et auteurs ont leurs habitudes, et ont bien du mal à se défaire du moule papier pour passer au moule numérique.

    • A vrai dire, dans beaucoup de cas, le rip intégrale du texte pour recommencé sur une base saine est bien plus rapide, et d’autant plus personnalisable. Car nettoyer un code ou le même style est défini 3 fois, ou pire possède trois définitions différentes, c’est un travail titanesque.

      Tant que les éditeurs ne seront pas conscients de ce que font leurs prestataires (chose que je tente d’expliquer), la pérennité du système en place est acquise au détriment du consommateur.

  3. Pour les balises alt, pourquoi ne penser que liseuses (qui ont leur défauts) et lecteurs ordinaires ?
    La balise alt pour moi, n’est pas une question de code, c’est une question de situation : un lecteur normal sur une outil de lecture normal (liseuse) s’en fiche parce qu’il voit l’image (si le code est bien fait 😛 )
    Mais pensons aux lecteurs aveugles ?
    En aucun cas, un lecteur aveugle n’a accès à l’image (et on sait tous que les livres électroniques sont une bénédiction pour eux par rapport aux livres audio ou livres brailles)
    Ceux-ci ne vont pas ouvrir l’epub sur une liseuse à encre électronique, ils peuvent l’ouvrir avec des extensions de Chrome ou Firefox, et donc (je pense, je ne connais pas les logiciels en question, ce n’est donc d’hypothétique, mais ils transcrivent les pages web, donc devraient gérer les epub…) avoir accès aux textes et aux balises alt des images grâce aux logiciels de transcriptions vocale ou braille.
    Pourquoi en faire des lecteurs de second ordre en réduisant la balise alt au minimum voire à rien, au prétexte que ADE et consorts ne la gère pas ? Pour la couverture à la limite, ça peut se comprendre tant l’intérêt est souvent limité, mais pour les images dans le texte ?

  4. Pingback: In « codage » venenum | Le livre numérique

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s