En jouant avec les arrières-plans multiples, des dégradés, les couleurs semi-transparentes, la taille des motifs et avec l’aide de pas mal d’astuce, il semble possible de réaliser des choses où il était jusque là obligatoirement nécessaire de charger un fichier graphique.

C’est évidemment impressionnant et je suis emballé par ces nouvelles possibilités.

Mais passé ce premier effet de surprise, je me pose quelques questions :

• Est-ce intéressant côté performances ? Cela fait toujours une requête de moins, mais quid du rendu de ces éléments complexes, n’est-ce pas trop gourmand en ressources (la page d’exemple est ainsi très lente au défilement) ?

• N’est-ce pas pousser la technique dans ses derniers retranchements au point de complexifier à outrance la lecture et la maintenance de ces motifs. Ou est-ce moi qui n’ai pas bien l’habitude encore de lire ces propriétés CSS ?

• Quels avantages y a t-il à s’aventurer sur ces techniques (je parle bien de ces exemples très avancés, pas juste des dégradés CSS) là où des alternatives simples fonctionnent déjà depuis longtemps ?

Je ne demande qu’à être convaincu : faites-vous plaisir.

Effet #sharethelove ajouté, ils s’embrassaient même !

Photo par Jean-François Renauld

En plus de cela et depuis maintenant plus de deux ans, je reviens de Paris Web avec (entre autres choses) la conviction qu’un dialogue se met doucement en place entre les intégrateurs, très demandeurs de nouvelles fonctionnalités ; et les implémenteurs, très demandeurs d’une priorisation de leurs tâches.

Aujourd’hui, la réponse est unanime : « Notre bugtracker est là, nous attendons vos retours d’expériences ».

Dans les faits c’est souvent beaucoup plus empirique : certains râlent dans leur coin, d’autres échangent sur des réseaux sociaux, et quelques (rares ?) courageux passent effectivement par les systèmes de suivi des bugs (j’y suis passé, c’est franchement pénible et peu adapté à nos profils).

Tout ça sans parler des disparités entre bugtrackers : certains ne proposent aucun suivi ; d’autres exigent une authentification complète ; certains sont extrêmement bien cachés…

J’ai réalisé qu’il manquait peut-être une plateforme d’échange plus simple entre ces deux communautés. Et que cette plateforme devait rassembler les idées en un seul et même endroit, quelque soit le navigateur. Après tout, cette « nouvelle fonctionnalité incroyable », nous souhaitons l’avoir partout, pas seulement dans notre navigateur favori.

Ne souhaitant pas non plus reproduire le travail déjà réalisé par chacun, je me mets à imaginer une interface :

• qui proposerait à toute personne du métier d’exprimer une idée facilement ;
• qui permettrait à la communauté d’approuver par un vote chaque idée soumise, et de trier ainsi les demandes les plus populaires ;
• qui laisserait ensuite chaque représentant navigateur formuler une réponse courte en précisant si c’est inenvisageable, à étudier, en cours ou même déjà en place.

Amis intégrateurs, respectables implémenteurs, les commentaires sont là pour recueillir vos avis sur cette idée.

Mais des projets qui prennent vie en dehors de ce blog et ça fait bien plaisir ! Séquence publicité, mais pour la bonne cause.

Un projet sur lequel je ne suis venu me greffer que tardivement, mais avec beaucoup de plaisir étant amateur de tout ce qui touche à la typographie. J’en profite pour aborder la question via l’angle technique puisque c’est ce que je connais le mieux. Amateurs de grilles et autres détails typos, c’est par ici.

Julien est venu me débaucher pour animer un tout nouveau forum consacré à l’apprentissage des métiers du Web. Avec un objectif affiché : proposer une alternative sérieuse aux offres commerciales jouant double-jeu avec le travail des graphistes. L’initiative m’a plu, j’ai signé. Allons parler bonnes pratiques côté créa.

Dernier bébé en date après une gestation de presque deux ans : un site d’interviews. Et même si techniquement je ne suis plus très fier de mon travail, l’idée principale me convainc toujours autant : donner la parole aux petites mains du web, à ceux qui le pratiquent au quotidien avec amour. Et découvrir ainsi ce qui se passe de l’autre côté du paravent dans l’open-space.

• le support des pseudo-selecteurs version selecteur::pseudo-selecteur ;
• le support du pseudo-selecteur :first-line ; notamment quand on effectue un zoom-texte associé ;
• la prise en compte (ou non) des caractères typographiques combinés avec first-letter (ici le guillemet suivi ou non d’un espace et l’apostrophe).

Support

:first-letter et :first-line sont supportés sur tous les navigateurs habituels :

• IE 6 ;
• IE 7 ;
• IE 8 ;
• Firefox ;
• Opera ;
• Safari ;
• Chrome.

Assez étonnement ::first-letter et ::first-line ne sont pas pris en compte par IE 7 et IE 8 alors qu’ils marchent partout ailleurs (IE 6 compris).

Le comportement de first-line correspond bien au comportement attendu : la sélection varie en fonction du zoom effectué sur la page et il s’agit bien en permanence de la première ligne qui est sélectionnée.

Subtilités typographiques

En théorie devrait first-letter s’appliquer à la première lettre et donc à la ponctuation qui l’accompagne.

Les caractères de ponctuation […] qui précèdent la première lettre devraient également être pris en compte

En pratique on constate un rendu plus ou moins correct de :

• Chrome (hormis un petit bug avec les espaces insécables encodés  ) ;
• Safari (avec le même petit bug) ;
• Firefox (mais sans le support des espaces) ;
• Opera (mais uniquement avec des guillemets droits et sans le support des espaces) ;
• IE6 et IE 7 (mais uniquement avec des guillemets droits, exit donc les guillemets à la française) ;
• et IE 8 (mais sans le support des espaces, ce qui est fortement pénalisant là encore).

En une phrase : seul le moteur de rendu WebKit s’en sort correctement.

Voici le fichier qui m’a permis de faire mes tests, si vous voulez compléter mon analyse ou tester à votre tour. Vous pouvez également regarder le support navigateur proposé sur Web Devout.

La lettrine, c’est la première lettre d’un paragraphe mise en exergue. Le plus souvent, elle est sublimée grâce à un corps de texte plus important et parfois à l’aide d’ornements graphiques.

Je m’intéresserai ici au cas d’une lettrine simple en utilisant la pseudo-classe CSS first-letter, a priori toute indiquée pour un contenu en HTML.

Quelques règles typographiques

En fouinant sur le web, je suis tombé sur ce vieil article qui rappelle les règles à suivre concernant les lettrines. Je les reproduis honteusement ici :

1. La lettrine porte généralement sur deux lignes, parfois plus ;
2. Elle ne doit pas être découverte ; au moins une ligne doit doubler sous la lettrine ;
3. L’espace du premier mot doit être adapté en fonction de la lettrine ;
4. La fin du premier mot s’écrit en petites capitales ;
5. Le sommet de la lettrine doit être visuellement aligné avec les ascendantes des lettres de la première ligne du texte.

C’est le point 5 qui va nous poser problème ici, à cause des différences d’interprétation par les moteurs graphiques des navigateurs (une fois n’est pas coutume)…

Un peu de code

Le code, ici, est enfantin. Le CSS :

/* font-size à 1em et line-height à 1.5 */
p{ 
    font-size: 1em;
    line-height: 1.5;
    width: 30em;
    margin: 3em auto;
}

/* font-size à 3em et line-height à 1, ce qui correspond en théorie à la hauteur de 2 lignes de texte courant
    et float pour laisser courir le texte */
p:first-letter{
    float: left;
    font-size: 3em;
    line-height: 1;
    margin-right: 0.2em;
}

/* juste pour mettre le premier mots en petites capitales */
p span{ font-variant: small-caps; }

Et le HTML :

    <p>
        <span>Lorem</span>
        ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
    </p>

Et maintenant, la partie désagréable…

Firefox le pénible

Voici les résultats des interprétations de la démo par les navigateurs :

On constatera que c’est globalement homogène chez Internet Explorer (versions « modernes »), Webkit et Opera, mais que Firefox 3.6 décale inexplicablement la lettrine vers le haut. Même Firefox 2 s’en sortait mieux (bon, il sautait une ligne supplémentaire mais au moins c’était aligné).

En tant qu’ayatollah affiché du rythme vertical, tout cela me chiffonne un brin. Non pas que j’utilise les lettrines très souvent (c’est même plutôt rare), mais j’aimerais bien comprendre d’où vient ce défaut.

J’ai trouvé cet article qui en parle mais n’aborde pas le point qui me gêne ici et se contente d’affirmer que la lettre ne passe pas en type block (malgré le float).

J’en appelle donc aux fans de prises de tête. À vos plumes, à vos idées, à votre bon cœur !

STPo

Même si sur le moment il ne m’avait pas frappé outre mesure, je repense assez fréquemment au coup de gueule de Gilles Vauvarin lors de sa conférence à Paris-web cette année : il était consterné que les intégrateurs ne respectent pas le rythme vertical de ses designs.

Ce fut l’occasion de me rappeler à quel point c’était super, le rythme vertical. Et à quel point j’en avais bavé à chaque fois que j’ai essayé de l’implémenter en CSS.

(C’est quoi le rythme vertical ? Allez lire cet excellent article de David sur le sujet)

Blueprint et les navigateurs sont dans un bateau

Remotivé par le sujet, j’attaque donc mon nouveau design avec Blueprint, framework CSS bien connu pour gérer intelligemment ce genre de problématiques délicates. On me l’a notamment conseillé pour éviter de me prendre la tête avec les calculs d’interlignages en em, qui donneraient des cauchemars à Pythagore en personne.

Hélas ! J’ai déchanté assez vite. Conserver un rythme vertical avec un vrai design (même minimaliste) est excessivement complexe, Blueprint ou pas Blueprint.

J’ai notamment buté sur les arrondis générés par les moteurs de rendu des navigateurs, qui ne sont apparemment pas calculés de la même manière.

Comme tout est défini en em, on se retrouve assez rapidement avec des styles générés assez exotiques : si mon line-height est de 1.5 et ma font-size de base de 11 px (12 px c’était trop facile), mon line-height généré va être de 1.5 × 11 = 16.5 px… et les demi-pixels, les navigateurs, en gros, n’aiment pas.

Ou du moins, ils ne l’interprètent pas tous de la même façon (ou alors j’ai vraiment raté un train). Ce qui oblige à une certaine gymnastique pour retomber sur des calculs de pixels générés entiers – qui eux sont interprétés de la même manière partout. Par exemple là, pour avoir un line-height généré de 17 px (mettons), je vais devoir mettre line-height:1.565… et encore, ça reste un arrondi.

Imaginez maintenant qu’on rajoute des bordures CSS, des images, bref toutes sortes de contenus et de styles qui décalent tout au fur et à mesure avec toujours plus d’arrondis.

Je ne vous fais pas de dessin, c’est un enfer !

Tout passer en pixels ?

Bref, j’ai été vite écœuré de cette mélasse d’em qu’on nous a pourtant appris à aimer dogmatiquement durant toutes ces années d’évangélisation aux bonnes pratiques.

D’où une question bien légitime : « mais pourquoi n’utilise-t-on pas tout simplement le pixel, unité native de notre medium ? ».

Évidemment, on sait qu’IE ne comprend pas grand-chose aux agrandissements de textes dès qu’on lui parle en pixels… et on entre alors dans des considérations plus philosophiques que techniques. Doit-on laisser IE sur le carreau ? N’est-il de toute manière pas intéressant de conserver des unités relatives pour les marges entre paragraphes (par exemple), afin de conserver nativement des proportions harmonieuses ?

Stéphane en parlait il y a deux ans de ça, les choses n’ont pas évolué depuis, et c’est bien dommage.

Bref, une piste à oublier, probablement.

Vers un mode de calcul normalisé pour tous les navigateurs ?

Revenons aux em : pourquoi les moteurs graphiques des navigateurs sont-ils infoutus de gérer les arrondis de décimales de pixels de la même manière ?

Y a-t-il des groupes de travail là-dessus ? Des ressources en ligne ? Est-ce que j’ai loupé quelque chose en route ?

Si vous avez des éléments de réponse je suis avide de les entendre…

Pour le moment, j’ai cette phrase de Stéphane qui me reste en travers de la gorge : « le rythme vertical pour moi, ne peut se tenir qu’avec des bricoles en JS : CSS n’est pas assez solide pour ça ».

Dites-moi que c’est faux !

La convention veut que les liens soient identifiés par le soulignement de ceux-ci et je reste donc dans ce cas classique. Bien souvent ensuite (dans le but de signaler l’interaction) ce soulignement sera retiré au survol.

<style type="text/css">
    a:focus,
    a:hover
    {
        text-decoration:none;
    }
    a:active
    {
        outline:none;
    }
</style>

Remarquez au passage :

• que je complète mon sélecteur pour le cas d’une navigation au clavier (j’y reviendrai plus tard) ;
• la définition de l’état actif, trouvée via ce très bon billet sur la suppression de l’outline.

Je ne sais pas pour vous, mais j’ai tendance à trouver cette technique (pourtant répandue !) contre-intuitive. C’est comme si le lien « disparaissait » au survol, et que du coup il n’était plus possible (en apparence) de cliquer.

J’aurais tendance à préférer tout autre mise en forme au survol. Comme par exemple un changement de couleur. On pourrait même reprendre celle des liens visités tiens…

<style type="text/css">
    a
    {
        color:#1C6280;
        background-color:inherit;
    }
    a:hover,
    a:focus,
    a:visited
    {
        color:#1C6280;
        background-color:inherit;
    }
    a:active
    {
        outline:none;
    }
</style>

J’aimerais lire vos avis et vos arguments, je n’arrive pas à trancher cette question.

Question bonus : les sélecteurs enrichis pour les navigations au clavier, ça ne pose pas de souci ? Je pense notamment à une personne qui d’une part survol un lien à la souris, tant en tabulant sur un autre lien en parallèle : il se retrouve alors avec deux liens mis en évidence à la fois.

C’est difficile à faire ?

Pas vraiment, mais ça se complique quand on souhaite que cette bordure soit toujours de la hauteur de la colonne le plus grande. Faut-il la placer sur le conteneur de gauche ou de droite ?

Solutions

On peut dans un premier temps penser à utiliser la techniques des colonnes factices et placer un background-image sous les colonnes, mais cela présente deux petits soucis :

• la largeur des colonnes sera alors fixée ;
• on fait appel à une image alors qu’un simple style CSS pourrait suffire.

Voici la méthode que j’utilise à la place :

<div style="overflow:hidden;height:1%;">
    <div style="float:left;width:200px;border-right:5px solid #000;">
        <p>
            Colonne A.
        </p>
    </div>
    <div style="float:left;width:200px;border-left:5px solid #000;margin-left:-5px;display:inline;">
        <p>
            Colonne B.
        </p>
    </div>
</div>

L’astuce consiste donc à placer deux bordures et à les faire se superposer ensuite via une marge négative de la largeur de la bordure. Simple, mais efficace.

Un peu d’histoire

L’idée d’ARIA c’est de permettre de décrire des rôles et des états, pour améliorer l’accessibilité des clients riches. Ainsi on peut légalement avec ARIA faire une case à cocher en image, pourvu qu’on la décrive comme une case à cocher (role="checkbox") et qu’on indique son état, cochée (aria-checked). C’est pratique pour faire des graphismes modernes, tout en permettant de ne pas sacrifier l’accessibilité au seul profit de ceux qui ont des yeux et une souris, pour résumer.

Quand ARIA a été introduit, on ne parlait pas encore de HTML 5 au W3C : c’est XHTML qui prévalait. Or en XHTML une notion fondamentale est celle des espaces de nommage, permettant de rattacher au document courant (dont l’espace de nommage HTML est implicite) des extensions. ARIA bénéficiait donc d’une déclaration dans le document pour permettre à chacun de ses attributs d’être déclaré avec le préfixe aria:. Par exemple le rôle d’un élément s’écrivait aria:checkbox. Facile.

Avec l’avènement de HTML 5 et ses choix différents en termes de formalisme, qui privilégient l’écriture de code avec la syntaxe HTML, ARIA a dû faire machine arrière : tout a été renommé sans espace de nommage. Les deux points des propriétés spécifiques à ARIA ont été remplacés par des tirets : aria:checked devient aria-checked. Certains attributs quant à eux, qui ont du sens même hors du contexte d’ARIA, n’ont carrément pas de préfixe. C’est le cas de role, qui était prévu dans la spécification XHTML 2.

Pour l’accessibilité dans le monde réel, c’est presque une bonne chose : à ce jour, la revue d’écran la plus utilisée (Jaws) ne reconnaît pas les attributs préfixés. J’en ai fait la douloureuse expérience lorsque mon site est passé en XHTML : Jaws ne comprenait pas les attributs xml:lang et les ignorait purement et simplement ! (Il a fallu doubler tous ces attributs avec l’attribut HTML classique lang).

Oui mais voilà : et la validation dans tout ça ?

À ce jour, le validateur du W3C s’appuie sur le DOCTYPE que vous déclarez dans votre code pour vérifier que vous respectez bien sa grammaire. Or dans une spécification ancienne (XHTML 1.1 date de 2001), il n’était évidemment pas prévu d’intégrer des attributs dont on ignorait qu’ils existeraient un jour ! Sans compter que la logique même d’extensibilité du XHTML venait de l’idée qu’on intégrerait tout ça avec des espaces de nommage, donc l’extension était prévue, mais avec un formalisme que le brouillon courant de HTML 5 remet en cause. Bref, nous voilà au pied du mur : faut-il faire du code invalide, ou respecter maniaquement la spécification et trouver des contournements « légaux » ?

Une solution : opter pour du code invalide

La solution simple serait d’opter pour du code invalide. Eric Meyer considère qu’on peut prôner les standards en étant fidèle à l’esprit mais pas toujours à la lettre : c’est ce qu’il appelle standards-oriented.

En l’occurrence, imaginons que j’aie écrit une page conforme et que j’y rajoute des attributs ARIA. Elle devient non-valide, mais j’ignore les erreurs en connaissance de cause parce que je suis un développeur Web avisé, et que je sais que ça ne posera pas de souci aux navigateurs tout en améliorant l’accessibilité pour tous.

Utiliser un attribut HTML existant et manipuler ses valeurs avec JavaScript

La deuxième solution est plus sportive : je crée du code valide, et je profite de JavaScript pour ajouter les attributs qui me manquent.

Cas classique : je repère l’élément via son id (identifiant unique dans la page), et j’ajoute le ou les attributs dont j’ai besoin pour faire de l’ARIA.

Oui mais : tous mes éléments ne sont pas forcément nommés, pourtant je risque d’avoir besoin de nombreux endroits auxquels me raccrocher pour ajouter des propriétés ARIA.

Le plus simple sera alors d’utiliser un attribut HTML, d’en extraire le contenu et de générer les attribut ARIA à partir de là.

Quel attribut choisir ?

J’ai déjà vu des gens utiliser l’attribut rel des liens, par exemple pour faire des popins (rel="popin,450,300" indique qu’à ce lien sera ajouté un comportement JavaScript d’affichage de la popin, et les dimensions de ladite popin). Pour ma part j’en suis très gêné, il me semble qu’il s’agit là d’un détournement assez osé de l’attribut. Par ailleurs, ça ne fonctionne que sur des liens ; il faut donc trouver un attribut plus générique.

En revanche, la bonne idée depuis plusieurs années, c’est tout de même qu’on tente de ne pas mettre de comportement dans le code. On s’appuie sur le DOM pour inventorier les éléments auxquels affecter tel ou tel comportement, souvent en passant par l’attribut class. Pour revenir à notre exemple de popins, il y a quelques années on aurait fait la même chose en popup, en s’appuyant sur la classe : class="popup".

Essayons donc de nous appuyer sur la classe : il nous semble moins nocif d’utiliser cet attribut plutôt qu’un autre.

Quelle méthode ?

Maintenant que nous avons choisi la classe, quelle convention d’écriture adopter pour tous ces attributs ?

Première proposition, utiliser une notation héritée de JSON : class="{role:contentinfo;}". Son intérêt c’est qu’elle est facile à interpréter, et qu’elle sera extensible si nous devons ajouter plusieurs attributs : class="{role:checkbox;aria-checked:true;}". Son gros défaut c’est qu’elle a l’apparence d’une verrue dans le code, sans compter que cette notation ressemble suffisamment à la notation classique des paires propriété / valeur de CSS pour au mieux prêter à confusion chez le développeur moins au fait que vous, au pire faire tousser un navigateur dont le parseur de code y reconnaîtrait de la CSS (scénario catastrophe, me direz-vous ; oui mais on a déjà vu pire dans certains navigateurs).

Deuxième proposition : utiliser une notation à base de tirets, class="role-contentinfo", et manipuler la chaîne en l’explosant pour générer l’attribut et sa valeur.

Deux situations à différencier

Attention cependant, ARIA propose une approche deux-en-un :

1. description d’éléments de structure de la page à travers le rôle (les landmarks) ;

2. description d’éléments interactifs (typiquement les éléments de formulaire).

Selon moi ces deux cas peuvent impliquer une approche différente : le premier cas doit tant qu’à faire fonctionner même sans JavaScript, le deuxième n’a souvent de sens que si JavaScript fonctionne (puisque le changement dynamique d’état ne peut se faire qu’avec JavaScript).

Conclusion

Je serais enclin à faire du code invalide, en particulier dans le cas des landmarks, mais plus partagé sur les propriétés dynamiques (rôles et états des éléments interactifs).

À votre avis ? Faut-il du code invalide, et si oui, quelle méthode choisiriez-vous ?

L’astuce consiste à placer la propriété overflow sur le contenu, pour que celui-ci puisse s’adapter en fonction de son contexte : il n’est alors plus besoin de lui préciser une largeur. On peut alors, modifier la largeur de la colonne, en ajouter, en supprimer : le contenu s’adaptera toujours.

Elle utilise d’ailleurs cette technique sur son projet Object-Oriented CSS.

Seules précautions à prendre pour IE 6 :

• appliquer un hasLayout (via un zoom:1 ou un height:1% au contenu ;
• ne pas oublier de corriger le « Three Pixel Text Jog » (via un margin-left:-3px ou margin-right:-3px;).

Seuls inconvénients trouvés :

• l’impossibilité de « faire sortir » un élément en dehors du cadre contenu, celui-ci ayant un overflow ;
• l’ordre du contenu qui se trouve inversé par rapport à l’affichage lorsqu’on utilise une colonne placée à droite.

Mon petit fichier de tests est ici si vous le souhaitez.