C’est au tour de Christophe Andrieu de prendre le clavier. Décidément, on n’est plus chez soi !

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 !

Éric a récemment abordé le cas des boutons activés, je prends le relais et je m’interroge cette fois sur le survol des liens.

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.

Petite astuce de rien du tout pour créer une bordure d’un ou plusieurs pixels entre deux colonnes.

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.

Stéphane Deschamps me pique la plume. Le sujet se prête mieux au format de ce blog qu’au sien.

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 ?

Je découvre tout à fait par hasard ce billet de Nicole qui expose une solution très intéressante pour faire des colonnages.

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.

Je déterre ce vieux billet sur les champs textes car il était plein de bonnes idées dans les commentaires.

Tac, tac, tac ! Reprenons svp !

Je laisse de côté le placeholder qui pour l’instant n’est pas envisageable (mais qui à terme viendra remplacer tout ça).

Yves poussait une idée intéressante avec le kbd. Ça pourrait donner ça :

<p>
   <label for="courriel">Courriel</label>
   <input type="text" id="courriel" name="courriel" value="" class="exemple" />
   <kbd>courriel@exemple.com</kbd>
</p>

Reste à savoir si c’est une bonne interprétation de la spécification :

KBD

Indicates text to be entered by the user.

Je met de côté samp qui semble plus indiqué pour des résultats.

Couplé à un petit JS ça pourrait le faire non ?

JS

jQuery(champs).each(function(){
    var exemple = 'ex';
    var that = jQuery(this);
    var papa = 'p';
    var fiston = 'kbd';
    var key = that.parent(papa).children(fiston);
    key.hide();
    that.addClass(exemple).val(key.text());
    that.focus(function(){
       if(that.val()==key.text())
          that.removeClass(exemple).val('');
    });
    that.blur(function(){
       if(that.val()=='')
          that.addClass(exemple).val(key.text());
    });
});
champs('input.exemple');

CSS

.ex
{
    color:#DDD;
    background-color:inherit;
}

Ou encore mieux si on a la place :

• ne pas ajouter de script ;
• laisser l’exemple à côté ;
• et se servir de value="" pour les cas d’erreur (à corriger sans tout avoir à re-saisir).

Ainsi :

HTML

<p>
   <label for="courriel">Courriel</label>
   <input type="text" id="courriel" name="courriel" value="vincentàhtmlzengarden.com" class="erreur" />
   <kbd>courriel@exemple.com</kbd>
</p>

CSS

.erreur
{
    font-weight:bold;
    color:#F00;
    background-color:inherit;
}

Reste une question : faut-il placer le kbd avant le champs pour des soucis d’accessibilité ?

HTML

<p>
   <label for="courriel">Courriel</label>
   (<kbd>courriel@exemple.com</kbd>)
   <input type="text" id="courriel" name="courriel" value="vincentàhtmlzengarden.com" class="erreur" />
</p>

ou

<p>
   <label for="courriel">Courriel (<kbd>courriel@exemple.com</kbd>)</label>
   <input type="text" id="courriel" name="courriel" value="vincentàhtmlzengarden.com" class="erreur" />
</p>

Ou encore lui placer également un label ?

HTML

<p>
   <label for="courriel">Courriel</label>
   <input type="text" id="courriel" name="courriel" value="vincentàhtmlzengarden.com" class="erreur" />
   <label for="courriel"><kbd>courriel@exemple.com</kbd></label>
</p>

À vos claviers !

PS : l’exemple est ligne est ici.

Je traine quelques questions récurrentes (d’ordre technique ou ergonomique) depuis que je fais des formulaires. Et vu que je suis sympa, je partage un peu avec vous.

Habituellement on fait ça :

Et moi, j’ai tendance à proposer cette solution (qui est généralement refusée) :

Alors, boutons radios et cases à cocher : à droite ou à gauche ?

Depuis quelques temps, il existe enfin une alternative robuste pour obtenir des « titres images ». Oubliez les images, sIFR, typeface ou autre Cufón car font-face est là et il l’est presque partout !

En effet il est supporté par :

• Opera 10+ ;
• Safari 3.1+ ;
• Firefox 3.5+ ;
• Internet Explorer 5.0+ (avec un format particulier certes).

Reste sur le bord de la route :

• les anciennes versions d’Opera ;
• les anciennes versions de Firefox ;
• les anciennes versions de Safari ;
• Google Chrome (mais ça arrive pour bientôt).

Pour ces navigateurs, il suffira alors de se servir de l’ordre de priorité des polices définies dans font-family pour obtenir une dégradation gracieuse.

Seule contrainte donc, fournir deux formats de police pour satisfaire Internet Explorer. Cet outil de convertion vous aidera à produire la version EOT de votre TTF favorite.

Reste à ne pas abuser de l’effet afin de ne pas surcharger le poids de vos pages, et à bien respecter les législations en utilisant des polices libres de droits.

Dans le cas contraire, je vous recommande chaudement ce site, qui liste le support (par pourcentage) des polices sur les principaux OS.

@font-face
{
    font-family:'Scrogglet';  
    src:url(Scrogglet.eot);
    src:local('Scrogglet'),url(Scrogglet.ttf) format('truetype');
}
h1
{
    font-family:Scrogglet,Monaco,'Palatino Linotype',sans-serif;
}

Un bon exemple est disponible chez Yves Van Goethem dans le titre de sa page : c’est lui qui m’a soufflé cette idée d’article !

Et en plus c’est son anniversaire aujourd’hui !

Sources :

• xBrowser Fonts
• Comment utiliser une fonte «non-standard» sur un site Web ?

Une fois n’est pas coutume, voici un petit script jQuery.

NB : Stéphane soulève un problème d’accessibilité dans les commentaires, ne passez pas outre.

Il permet lors de l’activation d’une ancre de déplacer progressivement l’ascenseur de la page en fonction. J’aime personnellement beaucoup cet effet car je trouve qu’il rend plus compréhensible l’utilisation des ancres.

var scrolling = function(){
    var speed     = 1000;
    jQuery('a[href^="#"]').bind('click',function(){
        var id = jQuery(this).attr('href');
        if(id == '#')
            goTo('body');
        else
            goTo(id);
        return(false);
    });
    function goTo(ancre){jQuery('html,body').animate({scrollTop:jQuery(ancre).offset().top},speed,'swing',function(){
            if(ancre != 'body')
                window.location.hash = ancre;
            else
                window.location.hash = '#';
            jQuery(ancre).attr('tabindex','-1');
            jQuery(ancre).focus();
            jQuery(ancre).removeAttr('tabindex');
        });
    }
};

Point par point, cela donne :

var scrolling = function(){

Déclaration de la fonction, qui sera à déclencher au chargement de la page.

    var speed     = 1000;

On choisi une vitesse pour l’effet. Ce paramètre peut être modifié à loisir.

    jQuery('a[href^="#"]').bind('click',function(){

On intercepte le click sur les liens qui renvoient vers des ancres…

        var id = jQuery(this).attr('href');
        if(id == '#')
            goTo('body');
        else
            goTo(id);
        return(false);

Et on déclenche la fonction d’animation en fonction de la destination (haut de page ou ancre). On annule ensuite le comportement par défaut du lien.

    function goTo(ancre){jQuery('html,body').animate({scrollTop:jQuery(ancre).offset().top},speed,'swing',function(){

L’astuce repose sur l’utilisation de la fonction animate, qui pour le coup simplifie bien le code.

            if(ancre != 'body')
                window.location.hash = ancre;
            else
                window.location.hash = '#';

En callback, on prend soin de changer le hash dans la barre d’adresse pour ne pas différer du comportement normal.

            jQuery(ancre).attr('tabindex','-1');
            jQuery(ancre).focus();
            jQuery(ancre).removeAttr('tabindex');
        });
    }
};

On place enfin un tabindex négatif sur l’ancre, afin de pouvoir ensuite forcer le focus dessus. Ainsi, logiquement, même les lecteurs d’écrans devraient s’y retrouver.

On termine enfin par un peu de ménage.

N’hésitez pas à critiquer le tout ! La démo est disponible ici.

J’ai tendance à trouver équivalents l’attribut alt (que l’on place sur les images pour l’alternative texte) et l’attribut summary (que l’on place sur les tableaux pour le résumé du tableaux).

Aussi s’il me semble logique de placer un alt vide sur une image destinée à la présentation :

    <img src="ornement.jpg" alt="" title="" width="10" height="100" />

À l’inverse de cette solution qui n’est évidemment pas conseillée :

    <img src="ornement.jpg" alt="Image de présentation" title="" width="10" height="100" />

Il me semble donc logique de placer un summary vide sur un tableau destiné à la présentation :

    <table summary="">
        <tr>
            <td>Colonne A</td>
            <td>Colonne B</td>
        </tr>
    </table>

Je crois avoir vu le conseil inverse ailleurs… je sollicite donc vos avis avisés !