Il y a déjà des dizaines de types de livres améliorés.

Ça ne sera qu’une évolution naturelle du livre. D’ici, quelques années, toutes les publications seront numériques, le papier sera quelque chose de collection ou d’élitiste et l’ebook enrichi sera la norme à mon avis.

Est-ce que les gens ont eu le même débat quand l’automobile est apparue en se demandant si on pouvait appeler ça aussi une voiture alors qu’il n’y avait plus de chevaux pour la tirer?

À mon sens, le problème vient plus du mot « livre » et de ce que chacun y met comme sens à l’intérieur, plus que de l’avenir de ses possibilités.

Oui mais… est-ce que leur HTML source sera récupérable tel quel ou faudra-t-il le corriger ? Et je dis bien « corriger », pas « modifier ».

D’où l’importance, aussi, de faire les choses correctement en EPUB. Or, la norme aujourd’hui, c’est du mauvais HTML, pas accessible pour un sou, pas balisé comme il faut, etc.

Je passe l’exemple des titres qui sont des paragraphes déguisés (h1, h2, h3, etc. c’est quand même juste la base).
Mais, par exemple, tu trouves encore des fichiers avec un vieux « trick » pour afficher une police de caractère intégrée dans iBooks dans ses premières versions : on utilise du samp parce que les classes de span et p n’étaient pas prises en compte. Non seulement samp n’est pas fait pour ça, mais en plus c’est totalement mettre de côté sa fonction pour contourner une restriction chez un revendeur…

Comment tu veux récupérer le HTML ? Dans l’état, si on le fait aujourd’hui, il faut refaire une énorme partie des bouquins en vente étant donné que le HTML est dégueulasse et que le contenu « dézippé EPUB » est en marge du web parce qu’il ne respecte absolument rien.

Y’a aussi cette problématique à prendre en compte, IMHO.

Quant à votre approche du epub et des lecteurs, je la trouve assez pertinente, mais pour une certaine frange de production seulement. Je suis d’accord qu’il faudrait presqu’un lecteur particulier à chaque œuvre qui ne soit pas classiquement un texte avec des images ou pas. Mais toutes les productions ne sont pas forcément dans ce cas, sans pour autant les rendre inintéressantes en numérique.

Actuellement, dans un epub, la structure d’un ouvrage est pris en charge par un xml de méta-données.

En n’utilisant plus la « capsule » de l’epub, ces méta-données deviennent alors essentielles pour relier les fichiers html entre eux et désigner ainsi l’accueil, les sections, le glossaire, l’auteur, le copyright etc.

Autrefois ces fameux « liens relatifs » étaient pris en charge nativement par Mozilla. Les premières versions de Firefox ont vite eu fait de supprimer le menu permettant de manipuler ces liens (que sans doute peu d’internautes utilisaient [?], difficile de le savoir aujourd’hui). La barre de navigation existe toujours, mais sous forme d’extension : https://addons.mozilla.org/fr/firefox/addon/site-navigation-bar/

Le navigateur Opera quant à lui dispose toujours nativement de cette fameuse « barre de navigation » interne aux sites (cf. http://help.opera.com/Linux/9.23/fr/toolbars.html )

Je m’en vais de ce pas tester quelques fichiers html ainsi reliés, sur ma liseuse Kobo

La seule chose qui me laisse dubitatif, c’est la conclusion. Les offres des opérateurs ont toujours suivi les usages et ne les ont jamais façonnées. La connexion permanente et illimitée ne me semble pas être le facteur de bascule entre les conteneurs offline et les livres en ligne, sinon, on attendrait toujours Spotify.