Carnet de notes

Catégorie : Développement informatique

  • Du code HTML des livres numé­riques

    J’ex­plore le code des ePub et je tombe sur des choses étranges : du code que je n’au­rai jamais accepté d’au­cun inté­gra­teur web avec qui j’ai travaillé jusqu’à présent, même d’un débu­tant.

    Je ne parle pas des livres extrê­me­ment mal faits mais bien de livres dont l’en­semble du code fait croire qu’il a été produit par des outils intel­li­gents, voire nettoyé à la main par quelqu’un dont c’est le métier.

    Ces livres là conti­nuent à avoir un code qui me semble étrange. Les moteurs de rendu des logi­ciels de lecture sont parfois mauvais. Il semble que les astuces et compro­mis se doivent d’être bien plus nombreux que ceux sur nos navi­ga­teurs web. Alors je demande à ceux dont c’est le métier, pouvez-vous m’éclai­rer un peu sur ce qui est normal ou pas, habi­tuel 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 couver­ture a pour texte alter­na­tif « image ». Dans d’autres exemples j’ai trouvé « couver­ture », « cover » et même « image.png ». Malgré mes recherches je n’ai trouvé aucun livre qui ait un texte alter­na­tif vide ou conte­nant le titre du livre (qui sont les deux choix que j’au­rai discuté dans le cadre d’un site web, suivant le contexte).

    Dans d’autres images j’ai parfois trouvé des textes alter­na­tifs vides mais rare­ment. Le plus souvent c’est « image », « carte », ou « illus­tra­tion ». Je n’ai cher­ché que sur un échan­tillon mais d’ori­gine diverse : Aucun texte alter­na­tif présen­tant une réelle alter­na­tive – même limi­tée ou tronquée.

    Sachant que le livre numé­rique offre poten­tiel­le­ment une réelle avan­cée sur l’ac­ces­si­bi­lité des textes aux personnes malvoyantes, je me dis qu’on gâche là une superbe oppor­tu­nité.

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

    Dans mes explo­ra­tions j’ai vu pour un petit quart de livres conte­nant certaines illus­tra­tions avec un texte alter­na­tif anglais. « Cover » revient assez souvent. Là, il y a vrai­ment un lais­sez-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 vrai­ment : un attri­but hauteur spéci­fié à 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’exac­ti­tude – et mon incom­pré­hen­sion. Spéci­fier une taille rela­tive en attri­but ou une taille fixe en style peuvent se comprendre indé­pen­dam­ment l’un de l’autre. Je n’ar­rive cepen­dant pas à conce­voir dans cas il peut être perti­nent d’as­so­cier 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 compa­ti­bi­lité je peux comprendre qu’on ait une hiérar­chie qui ne soit pas la hiérar­chie théo­rique, mais…

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

    Je vois souvent des titres vides, tout simple­ment. J’au­rai pu le comprendre pour des raisons de compa­ti­bi­lité pour des entêtes de chapitre mais à y regar­der de plus près j’ai une part très signi­fi­ca­tive de livres qui n’ont aucune balise <h1> du tout, et qui fonc­tionnent 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’in­verse, j’ai donc bien des livres où les titres sont de simples para­graphes mis en gras avec une police de carac­tère spéci­fique. 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 majo­rité des livres choi­sissent de ne pas marquer comme titre <h1> le titre du livre, et de réser­ver 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 fonc­tion­ner de certains lecteurs qui construisent des sommaires auto­ma­tiques.

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

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

    Et le corps de docu­ment

    <title>002</title>

    Dans la plupart des lecteurs, la balise <title> reste inuti­li­sée, mais tout de même… Une bonne majo­rité reprend le nom du chapitre en court ou une indi­ca­tion simi­laire. Quelques irré­duc­tibles conti­nuent à simple­ment numé­ro­ter le fichier xhtml, avec de plus un numéro qui ne corres­pond pas à celui du chapitre. C’est dommage, on se coupe de poten­tielles réuti­li­sa­tions 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’in­for­ma­tion existe peut être dans les méta­don­né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’im­pres­sion de reve­nir aux années 2000. Même dans un trai­te­ment de texte plus aucun profes­sion­nel ne devrait faire de chose pareille, alors chez un éditeur… Je ne connais pas les problèmes de compa­ti­bi­lité des logi­ciels de lecture mais il y a-t-il vrai­ment des lecteurs qui ne sauront pas reprendre des règles CSS simples de marge et d’es­pa­ce­ment ?

    …moi ?</p>

    C’est arrivé rare­ment, et plus exac­te­ment je n’ai pas réussi à retrou­ver de livres présen­tant ce problème, mais je me rappelle clai­re­ment l’avoir rencon­tré dans mes lectures : des manques d’es­paces insé­cables devant ou après certaines ponc­tua­tion, avec des retours à la ligne malheu­reux. Sur des livres avec un éditeur dont c’est le métier c’est presque inex­cu­sable.

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

    Dernier point relevé aujourd’­hui, la présence de titres en lettres capi­tales, sans utili­ser le style CSS dédié à cet usage. Je soupçonne un manque de compa­ti­bi­lité mais je doute quand même : Cette fonc­tion­na­lité est plutôt bien implé­menté dans les moteurs web depuis long­temps.

    Pouvez-vous m’ai­der ?

    Vous allez me dire que je suis poin­tilleux 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 correc­tions ci-dessus on reste trop souvent avec un code en excès de <div> et <span>, avec des classes super­flues et redon­dantes un peu partout, avec un mélange étrange et injus­ti­fiable de styles en ligne et styles externes.

    Bref, je suis poin­tilleux par nature mais croyez bien que dans ce billet je suis encore loin de la qualité que j’at­tends d’un inté­gra­teur web avec qui je travaille. Là j’ai l’im­pres­sion de deman­der le mini­mum.

    Je suis convaincu qu’il doit exis­ter des raisons à certains de ces choix. Je ne suis donc pas vrai­ment là pour poin­ter du doigt, mais pour expo­ser ma pensée et espé­rer que vous saurez m’ex­pliquer ces choix ou les contraintes qui ont mené à ces choix, pour que je comprenne et que je reparte moins igno­rant que je ne suis arrivé.

  • TEA cherche un renfort de talent pour son équipe tech­nique

    Nous commençons la réali­sa­tion d’une appli­ca­tion web desti­née prin­ci­pa­le­ment – mais pas exclu­si­ve­ment – aux tablettes. Il s’agit d’une réelle appli­ca­tion métier complexe et inno­vante, pas simple­ment d’un site de commerce ou de présen­ta­tion.

    Nous croyons fonda­men­ta­le­ment aux tech­no­lo­gies web stan­dard et à l’ou­ver­ture qu’elles apportent. Colla­bo­rer à proto­coles et formats communs ouverts ou publier en open source fait d’ailleurs partie de notre ADN et de nos inten­tions. Au lieu de gérer des appli­ca­tions natives iOS, Chrome et Android, nous allons tout faire en web : javas­cript css et html.

    Le poste

    Pour complé­ter l’équipe en cours de consti­tu­tion nous cher­chons un déve­lop­peur qui sait aller au fond des choses, cher­cher, apprendre, réali­ser et parta­ger, avec une exigence sur lui-même et qui privi­lé­gie la qualité.

    Ce peut être – préfé­ra­ble­ment – un déve­lop­peur avec déjà une bonne expé­rience sur une appli­ca­tion web mobile full javas­cript, ou quelqu’un travaillant de manière pous­sée sur tout ce qui gravite autour du terme « HTML 5 » ou « javas­cript », par exemple avec des réali­sa­tions open source. Celui que nous recher­chons sera le réfé­rent tech­nique qui sait tout ou qui saura tout assez rapi­de­ment, et qui saura trou­ver ce qui manque.

    Ensemble, nous parle­rons déve­lop­pe­ment, puisque conce­voir une appli­ca­tion complexe inté­gra­le­ment en javas­cript ce n’est pas comme faire un carrou­sel en jquery ou jouer avec la dernière librai­rie à la mode. À côté de ça nous parle­rons aussi inno­va­tion, archi­tec­ture, perfor­mance, compa­ti­bi­lité, mobi­lité, rendu écran, ergo­no­mie, latence et débit limité et plein d’autres choses très geek.

    Il faudra par exemple batailler avec des API javas­cript toutes fraiches, regar­der les diffé­rences d’im­plé­men­ta­tion des caches appli­ca­tifs navi­ga­teur, fouiller s’il faut utili­ser indexedDB ou webSQL, et proba­ble­ment aller sur caniuse.com plusieurs fois par jour les premiers temps. Des connais­sances poin­tues et à jour sur HTTP et toute la pile des tech­no­lo­gies web seront bien entendu essen­tielles.

    L’en­vi­ron­ne­ment

    Vous rejoin­drez alors une petite équipe sympa avec des déve­lop­peurs moti­vés, à jour sur les nouveau­tés et inno­va­tions web, avec une soif d’ap­prendre et de parta­ger. L’équipe fonc­tionne en méthodes agiles, auto­nome et sans chef de projet sur la partie tech­nique, en colla­bo­ra­tion avec un respon­sable produit sur le bureau d’à côté pour la partie fonc­tion­nelle.

    Il s’agit d’in­ves­tir sur le long terme pour réali­ser une appli­ca­tion qui évoluera en perma­nence et qui sera au cœur de l’ac­ti­vité. Nous n’en­vi­sa­geons donc qu’une colla­bo­ra­tion sous la forme d’un CDI dans nos locaux de Lyon. Si vous n’ha­bi­tez pas déjà Lyon et si le projet vous tente, même si nous savons que ça ne se fait pas toujours en un claque­ment de doigts, nous vous inci­tons à envi­sa­ger de venir nous rejoindre ici. Outre une ville bien sympa il y a le soleil, les plus grands lacs de France juste à côté, la mer à distance raison­nable, et les montagnes toutes proches.

    La société elle-même travaille à un projet dans le domaine du livre élec­tro­nique, avec pour ambi­tion de fédé­rer les acteurs de la chaîne du livre autour d’une plate­forme de distri­bu­tion et de services d’e-book ouverte, à l’échelle natio­nale et inter­na­tio­nale. Il y a de l’in­no­va­tion, une volonté d’ap­por­ter une vraie valeur ajou­tée au-delà de ce qui existe déjà, et l’en­vie de pouvoir dire « nous étions là » et « c’était nous » dans quelques temps.

    Le recru­te­ment

    Rien n’est gravé dans le marbre, si vous êtes le mouton à cinq pattes ou si vous avez un parcours très spéci­fique, prenez-contact quand même, ça peut être d’au­tant plus inté­res­sant. Vous trou­ve­rez un e-mail dans les liens à propos ou dans le message qui accom­pagne cette offre.

    Note à ceux qui ont exploré ou explo­re­ront le reste de ce blog : Je n’ex­prime mes opinions poli­tiques et société qu’ici, pas dans les bureaux. Vous n’avez pas à les parta­ger, et je n’ai pas à savoir si vous les parta­gez ou non. Par contre nous parle­rons avec plai­sir de numé­rique, de web, de livre, de tech­no­lo­gie, de culture et de plein d’autres sujets non polé­miques si vous le souhai­tez.

  • Making Love To WebKit

    Pour ceux qui aiment les démo, celle de Steven Wittens mérite le détour : Making Love To WebKit (oui, unique­ment avec webkit/chrome pour l’ins­tant).

    C’est tout bonne­ment génial. Nous avons de la 3D avec des effets de chan­ge­ment de point de vue, en pur CSS 3D, avec les expli­ca­tions tech­niques du comment et même un éditeur en javas­cript pour créer et placer les éléments 3D au départ.

    Pour ceux qui pensent encore que sur le web on ne peut faire que des sites de commerce élec­tro­nique ou de rédac­tion­nel barbant, voilà un peu de quoi vous réveiller. Ce n’est en soi pas un résul­tat extra­or­di­naire si on sort du web, mais la réali­sa­tion est inté­res­sante.

  • Colo­no­sco­pies, cold water and pain: How our memory works and how this relates to web perfor­mance

    Si vous vous inté­res­sez à la perfor­mance des sites web, Colo­no­sco­pies, cold water and pain: How our memory works and how this relates to web perfor­mance, est indis­pen­sable à lire.

    On y parle de la diffé­rence entre la percep­tion et la réalité. C’est là que les lenteurs des tunnels de commande prennent tout leur sens.

     

  • What’s an app anyway ?

    Je sais, c’est une vidéo, et personne n’a le temps de lire une vidéo. Moi non plus.

    Toute­fois, si vous êtes sur le point de réali­ser une appli­ca­tion native Android ou iOS, vous devriez prendre un peu de temps pour écou­ter What’s an app anyway ?, la suite du texte Mobile apps must die (à lire aussi).

    C’est encore plus vrai si vous avez une nouvelle acti­vité qui se monte. Plani­fiez sur l’ave­nir : Utili­sez le web. Ça sera certes un peu plus long, mais vous allez jouer avec pour des années, vous n’au­rez pas à faire un redé­ve­lop­pe­ment sur chaque plate­forme, et vous trou­ve­rez bien plus de gens pour faire évoluer vos logi­ciels.

    Pour faire du natif, aujourd’­hui, il faut une bonne raison. Êtes-vous certains de l’avoir ?

    Boot to Gecko peut vous donner un avant gout de ce qui se prépare pour plus tard.

  • Respon­sive image

    Il y a eu des centaines d’ar­ticles tech­niques détaillés et plus ou moins smart sur la possi­bi­lité de télé­char­ger une image plus ou moins grosse suivant la taille d’af­fi­chage, afin de ne pas utili­ser une énorme image sur mobile ou une ridi­cu­le­ment petite sur un écran 24″.

    Si vous ne devez en lire qu’un

    Le dernier pour comprendre où en sont les réflexions, c’est proba­ble­ment l’ar­ticle de Bruce Lawson. Il faut aussi lire les commen­taires.

    Tout d’abord oubliez les astuces à base de javas­cript et de noscript. Il existe des machins horribles qui résistent à peu près à tout, mais ça reste fran­che­ment bancal. Oubliez encore plus les scripts à base de cookie, qui de toutes façons ne pour­ront jamais répondre à plus du tiers de la problé­ma­tique, et encore, avec des effets de bords.

    Bruce part d’une solu­tion unique­ment basée sur des CSS, qui de plus à la bonne idée d’être théo­rique­ment déjà fonc­tion­nelle. Il suffi­rait d’amé­lio­rer le support CSS 3 des navi­ga­teurs pour que cela ne se pose plus. Pour l’ins­tant cela n’est possible qu’a­vec Opera et Chrome, et les opti­mi­sa­tions de perfor­mance de ces navi­ga­teurs risquent de faire télé­char­ger deux images au lieu d’une seule (ce qui est un peu l’op­posé du but recher­ché).

    Il propose ensuite un marquage HTML pour arri­ver au même résul­tat. C’est rétro-compa­tible avec les navi­ga­teurs actuels, et ne devrait pas être impos­sible à implé­men­ter.

    Main­te­nant ça ne me plait pas

    Tout d’abord le marquage HTML me semble le mauvais endroit pour résoudre la problé­ma­tique. On parle de répondre à des tailles d’af­fi­chage, et ça c’est typique­ment une ques­tion de présen­ta­tion, donc de CSS. Certai­ne­ment il y a des fois où un marquage HTML aura du sens, mais selon moi ce sera un cas parti­cu­lier du cas géné­ral, et utili­ser HTML est prendre le problème par le mauvais sens.

    Ensuite il y a des problé­ma­tiques qui marquent un manque de recul (pas de la personne, mais bien en rapport avec les besoins réels et les capa­ci­tés des navi­ga­teurs). Filtrer sur le fait que l’uti­li­sa­teur est en 3G est seule­ment impos­sible pour beau­coup de situa­tions (le navi­ga­teur n’a pas l’in­for­ma­tion), mais aussi n’a aucun sens. Pour une même connexion 3G je peux être à des vitesses réelles qui font presque passer mon ancien 56K pour une alter­na­tive accep­table (par exemple à cause des pertes de paquets à gogo), soit être à 7Mb/s et crâner devant la majo­rité des liai­sons ADSL de mon pays (qui est pour­tant très bien connecté). De toutes façons la vitesse de connexion sur mon propre accès est un très mauvais révé­la­teur de la vitesse réel­le­ment dispo­nible pour joindre le serveur d’en face. Le réseau peut être encom­bré chez moi, chez mon FAI, sur le serveur d’en face, ou n’im­porte où au milieu.

    Je seconde le commen­taire numéro 8 : s’il fallait vrai­ment tailler le contenu de manière fixe en fonc­tion unique­ment de taille d’écran et de vitesse de connexion, une décla­ra­tion dans les entêtes de la requête et une négo­cia­tion HTTP seraient bien plus effi­caces. L’op­tion a de plus l’avan­tage de ne poser aucun problème de compa­ti­bi­lité arrière.

    La problé­ma­tique de base

    Toute­fois, on revient au problème initial. À force de discu­ter certains ont oublié la problé­ma­tique de base : choi­sir une image en fonc­tion de la taille à affi­cher. Le méca­nisme éven­tuel ne doit prévoir que ça : permettre de spéci­fier diffé­rentes adresses (ou diffé­rents suffixes) en fonc­tion de diffé­rentes hauteurs ou largeurs.

    Charge à vous d’uti­li­ser une entête ou l’adresse IP côté serveur pour véri­fier si c’est de l’ADSL ou de la 3G (ça me semble une mauvaise idée mais vous pouvez déjà le faire). Charge à vous d’uti­li­ser des @media pour propo­ser plusieurs versions en fonc­tion de la taille de l’écran ou de son orien­ta­tion, ou de contraindre cette taille en fonc­tion. En combi­nant tout cela vous devriez pouvoir faire tout ce qui vous amuse, mais la problé­ma­tique qui nous manque c’est unique­ment celle de four­nir plusieurs URLs en fonc­tion de la taille prévue pour l’af­fi­chage. De toutes façons on ne trou­vera jamais de solu­tion qui fait le café.

    Je n’ai pas « la » solu­tion, mais selon moi (et je rejoins beau­coup le commen­taire 15) :

    • La réponse prin­ci­pale doit être côté CSS (quitte à avoir d’autres types de réponses ailleurs pour des cas niches)
    • Elle ne doit s’oc­cu­per que de propo­ser des images alter­na­tives en fonc­tion de la largeur ou hauteur prévue pour affi­cher l’image (et non de la taille du view­port ou d’autres para­mètres tiers)
    • Elle ne doit pas provoquer de double télé­char­ge­ment sur les navi­ga­teurs non compa­tibles
    • Elle doit avoir un fall­back accep­table sur les navi­ga­teurs non compa­tibles

    Le reste se fait avec les outils exis­tants, pas en les remplaçant.

    Le jeu de « ma solu­tion à moi »

    Si vrai­ment je devais créer quelque chose à chaud (ce qui se révè­lera forcé­ment une erreur), j’au­rai quelque chose comme ça :

    img.intro {
  content: content-if(attr(data-big), width > 300px),
           content-if(attr(data-small), height < 50),
           attr(src) ;
}
@media all and (max-width:600px) {
  img.intro {
    width: 300px ;
    height: 200px ;
  }
}
@media all and (max-width:320px) {
  img#thingy {
    width: 50px ;
    height : 30px ;
  }
}

    Bon, le pseudo langage sur la condi­tion n’est proba­ble­ment pas celui qu’il faut rete­nir mais il est volon­tai­re­ment basé sur un jeu de mot clefs limité et des contraintes qui le sont tout autant (hauteur et largeur dispo­nibles, c’est tout). On peut tout à fait envi­sa­ger que cela ne fonc­tionne que si les tailles width ou height sont déter­mi­nées expli­ci­te­ment dans la CSS, histoire de ne pas rendre l’im­plé­men­ta­tion irréa­li­sable. Autre avan­tage : c’est à priori compa­tible avec l’exis­tant puisqu’au pire si content-if n’est pas supporté, c’est toute la règle qui est igno­rée. Reste au navi­ga­teur qui supporte ça de prendre la première version qui corres­pond.

  • Appel à orateurs − Sud Web 2012

    Après Paris Web, c’est le tour de Sud Web. La précé­dente édition étant un succès, ils remettent ça les 25 et 26 mai 2012 à Toulouse. À vous de propo­ser des sujets via le formu­laire de l’appel à orateurs. Si vous voulez parler de concep­tion web, c’est un des événe­ments à suivre.

  • HTML5 Cross Brow­ser Poly­fills

    Ah, le graal de pouvoir utili­ser sur tous les navi­ga­teurs les dernières fonc­tion­na­li­tés qui sont encore en projet ou qui ne sont arri­vés que sur les toutes dernières versions…

    Javas­cript permet toute­fois de combler pas mal de manques, pour peu qu’un génie ait passé quelques semaines à réim­plé­men­ter tout à la main.

    Voici une belle liste de ce qu’on appelle les Poly­fills, pour juste­ment utili­ser les dernières nouveau­tés sur des navi­ga­teurs qui n’ont pas été prévus pour.

    Atten­tion, les perfor­mances ne sont pas toujours au rendez-vous.

  • Ortho­graphe et acces­si­bi­lité

    Je ne suis certai­ne­ment par meilleur qu’un autre sur ce sujet, et mon niveau d’écrit a baissé consi­dé­ra­ble­ment depuis que je travaille sur le web. Toute­fois, si d’au­cuns doutaient de l’im­por­tance de l’or­tho­graphe, voici une raison concrète d’y faire atten­tion : Stéphane Deschamps nous parle de l’im­pact de l’or­tho­graphe sur l’ac­ces­si­bi­lité des conte­nus élec­tro­niques.

  • API HTML 5 suppor­tées par les mobiles

    Vous connais­siez proba­ble­ment can i use, voici mobile html 5, dont la présen­ta­tion est un peu plus claire et simple. Passer du natif au pur web est une évolu­tion impos­sible à arrê­ter désor­mais. Si vous voulez être plus en avance qu’en retard, c’est le point de départ de vos réflexions.