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.

Paris-Web, c’était aussi il y a 5 ans une équipe de jeunes passionnés qui croisaient les doigts pour que la sauce prenne et qui trouvaient leur premier public sur les trottoirs du XIVème arrondissement.

Les joies d’une naissance en somme !… Et cette année, Paris Web attend son petit-frère.

Les futurs parents sont là ; le lieu de naissance choisi, la date programmée : le bébé s’annonce beau !

Bref, je ne saurais trop vous conseiller de réserver vos place, de casser la tirelire, ou de convaincre votre hiérarchie :

Sud Web c’est le 27 mai 2011 à Nîmes et les inscriptions courent encore pendant deux semaines ! Le tout à un prix plus que raisonnable. Foncez !

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.

• Smashing Magazine a consacré récemment un tutoriel sur le sujet ;
• quelques curieux s’y essayent en ce moment sur Twitter.

Suffisamment d’éléments pour donner envie d’en parler un peu ici. Il faut dire aussi que je suis plutôt convaincu par les possibilités offertes.

De quoi s’agit-il exactement ?

Zen-coding propose simplement quelques automatisations qui viennent se greffer sur votre éditeur habituel.

La fonctionnalité principale (implémentée en premier sur les éditeurs) est basée sur la syntaxe des sélecteurs CSS : idéal pour ne pas être dérouté.

Par exemple si j’entre :

div#content>p.intro+ul>li*3>a

J’obtiens immédiatement :

<div id="content">
    <p class="intro"></p>
    <ul>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
    </ul>
</div>

On joue donc entre les sélecteurs enfants et adjacents pour construire sa structure d’une ligne.

Les « abréviations » permettent également donc de générer un grand nombre d’éléments HTML pré-construits ainsi que des propriétés CSS.

Tout cela est très efficace, d’autant qu’une fois le code généré, il suffira de tabuler pour que l’éditeur fasse passer votre curseur sur les endroits où du contenu doit être ajouté.

Sur l’exemple précédent, c’est :

<div id="content">
    <p class="intro">ici,</p>
    <ul>
        <li><a href="ici,">ici,</a></li>
        <li><a href="ici,">ici,</a></li>
        <li><a href="ici,">et ici.</a></li>
    </ul>
</div>

Autre fonctionnalité intéressante : la possibilité de sélectionner de manière progressive des portions de code. Toujours en reprenant l’exemple précédent, et en supposant que je place mon curseur entre « et » et « ici. », à chaque fois que je déclenche la fonctionnalité je sélectionne :

• et ici. ;
• <a href="ici,">et ici.</a> ;
• <li><a href="ici,">et ici.</a></li> ;
• etc.

Et bien sûr la sélection est faite de manière à pouvoir supprimer le bloc proprement d’un coup.

Arrive également la possibilité d’ajouter autour de la structure sélectionnée une nouvelle abréviation.

Je peux par exemple facilement produire en quelques raccourcis claviers :

<div id="content">
    <p class="intro">ici,</p>
    <div class="blocs ajoutes par la suite">
        <div class="blocs">
            <ul>
                <li><a href="ici">ici,</a></li>
                <li><a href="ici">ici,</a></li>
                <li><a href="ici">et ici.</a></li>
            </ul>
        </div>
    </div>
</div>

Tout cela sans devoir à aucun moment revoir mes indentations.

Pour les utilisateurs avancés, il est également possible de (re)définir finement de nouveaux modèles, en précisant syntaxes, positions du curseurs, etc.

Plongez-vous également dans les filtres de sortie qui semblent eux aussi très puissants.

Parfait ?

Pratique en tout cas. Il faudra cependant prendre le temps d’appendre les raccourcis clavier propres à votre éditeur pour en profiter pleinement. Et surtout croiser les doigts pour que votre éditeur favori supporte le plugin convenablement.

Difficile de se défaire de nos petites habitudes acquises au jour le jour pour en adopter d’autres… mais il semblerait que ça vaille le coup d’essayer.

Bien qu’en apparence très basique, le travail du développeur web client requiert de s’assurer d’une multitude de choses (non, nous ne nous occupons pas que du rendu visuel). Pour de ne rien oublier, j’utilise une check-list qui répond aux besoins habituels.

Ce document (à adapter à fonction des besoins du projet) permet une bonne vision d’ensemble sur l’avancement et les éventuels oublis lors de la phase d’intégration.

Je la fournis aussi au format « Markdown » pour plusieurs raisons :

• ce format en texte brut est facilement compréhensible et modifiable par n’importe qui ;
• il peut être aisément convertit au format HTML et être placé à la racine du projet ;
• c’est un format que j’ai adopté dans mes processus avec lequel j’ai l’habitude de travailler.

En pratique, il s’agit au cours du développement d’annoter le document, et de compléter chaque ligne par un OK / NOK / N/A.

La première partie concernant des résultats attendus pour chaque page, elle servira aussi aisément d’index.

Comme précisé dans le document, je ne suis pas l’auteur de cette liste : je n’ai fait que reprendre et combiner plusieurs existants.

La checklist

Voici donc :

• le fichier markdown ;
• sa transformation en HTML.

Si vous travaillez en PHP le code de transformation est simpliste :

<?php
    include_once('markdown.php');
    include_once('smartypants.php');
    echo(SmartyPants(Markdown(file_get_contents('checklist.markdown'))));
?>

Et vous trouverez les sources nécessaires dans le lien donné plus haut.

Checklist
=========

Conformité et affichage {#conformite}
-------------------------------------

Maquette                     | Validation XHTML                | Validation CSS                  | Safari | Fx   | IE 6 | IE 7 | IE 8 | Opera | Chrome | Lynx [^1] | Impression | iPhone | YSlow
-----------------------------|---------------------------------|---------------------------------|--------|------|------|------|------|-------|--------|-----------|------------|--------|-------
[Accueil](accueil.html)      |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[Contact](contact.html)      |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[Rechercher](recherche.html) |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[...](#)                     |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |


[^1]: L’affichage Lynx est proche de la restitution faite par un lecteur d'écran ou de ce qui est perçu par un moteur de recherche.

Sur l'ensemble des maquettes [^2]
---------------------------------

Contenu et style                                                                                                                             | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier la ponctuation : particulièrement les apostrophes, les guillemets, les marques de citations, les traits d’union et les tirets       |
Ne faire ni d'faute d'orthographe ni de grammaire                                                                                            |
La capitalisation doit être uniforme et traitée par CSS                                                                                      |
Proscrire les phrases passe-partout ou récurrentes ("En savoir plus...")                                                                     |
Éviter les variations dans les mots ("email" vs "e-mail" vs "courriel")                                                                      |
Traitement des listes (points, virgules, ou point-virgules à la chaque fin d’élément)                                                        |
S’assurer qu’aucun contenu de test ne subsiste ("lorem ipsum...")                                                                            |
Vérifier tous les textes cachés (les `alt`, retranscriptions, les textes dans les fonctions JS)                                              |

Visibilité moteur de recherche                                                                                                               | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Les titres (`title`) des pages sont importants, s’assurer qu’ils aient un sens et soient représentatifs des mots clefs présents dans la page |
Créer des `metadata description` pour les pages importantes                                                                                  |
S’assurer que le marquage du contenu respecte la sémantique HTML (`h1`, `p`,...)                                                             |
Vérifier le format des urls (urls simples à retenir pour les utilisateurs et les moteurs de recherche)                                       |

Conformité                                                                                                                                   | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Voir [tableau ci-dessus](#conformite)                                                                                                        |


Accessibilité                                                                                                                                | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Indiquer le langage humain principal du document en utilisant l'attribut lang au sein de la balise `<html>`                                  |
Indiquer les passages en langage secondaire dans d'autres balises encadrant le passage concerné                                              |
Proposer des liens de navigation dès le début du balisage lorsque les pages contiennent beaucoup de contenu avant le contenu principal       |
Indiquer des en-têtes dans les tableaux de données avec des balises `<th>`, et associer toutes les cellules de données à leurs en-têtes      |
S'assurer que l'ordre des tabulations est logique, en utilisant tabindex au besoin                                                           |
S'assurer que la page fonctionne toujours quand les images sont désactivées                                                                  |
S'assurer que les pages restent utilisables quand les utilisateurs agrandissent le texte au double de sa taille originale                    |
Vérifier que chaque élément de la page est accessible et manipulable au clavier                                                              |
Rédiger des textes d'appel de liens qui puissent être compris hors contexte (pas de liens titrés "cliquez ici")                              |
Pour les daltoniens ou les malvoyants, s'assurer de proposer un contraste suffisant entre le contenu et le fond de la page                   |
N'utiliser aucun contenu qui clignote plus de trois fois par seconde                                                                         |
Ne pas cacher l'indicateur de focus. Quand un utilisateur navigue au clavier, il doit toujours savoir où ces éléments se trouvent            |
Ne pas attendre des utilisateurs qu'ils perçoivent du sens grâce aux polices, aux couleurs ou à d'autres modifications de style              |
Être brefs dans les textes alternatifs, mais donner du détail dès lors qu'il y a du sens à transmettre                                       |
Fournir un script, des sous-titres, et/ou une traduction en langue des signes pour toutes les vidéos ou les sons contenant du discours       |
Fournir une version "descriptive" d'une vidéo lorsqu'il est essentiel d'en comprendre le contenu pour des utilisateurs non-voyants           |
S'assurer que toutes les vidéos, si elles ne se lancent pas automatiquement, offrent au minimum une touche de lecture accessible             |
Quand du texte peut être interprété visuellement par le navigateur aussi bien que s'il s'agissait d'une image, éviter d'utiliser des images  |
Éviter les CAPTCHAs (questionnaires de test visuels anti-robots)                                                                             |
Marquer tous les champs de formulaire avec la balise d'étiquetage `<label>`                                                                  |
Utiliser les regroupements de champs (`<fieldset>`) avec des balises de titrage (`<legend>`) pour associer des demandes de saisie            |
Recenser toutes les erreurs de saisie au format texte, et placer le message à côté du champ concerné ou à un emplacement bien repérable      |
Offrir des liens d'aide ou des instructions en ligne pour remplir les champs si nécessaire                                                   |
Ne pas laisser les utilisateurs effectuer des actions importantes sans leur proposer une confirmation ou un moyen d'annuler                  |

Tests fonctionnels                                                                                                                           | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier toutes les fonctionnalités complexes                                                                                                |
Tester avec différentes configurations de résolutions d’écran                                                                                |
Tester tous les formulaires, incluant les filtres anti-spam, les réponses aux formulaires et emails, etc.                                    |
Tester sans JS, Flash et tous les autres plugins                                                                                             |
Vérifier que tous les liens externes sont valides                                                                                            |

Performances                                                                                                                                 | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier l’optimisation des images                                                                                                           |
Vérifier et mettre en place le cache quand nécessaire                                                                                        |
Vérifier le temps de chargement et le poids des pages                                                                                        |
Minimiser/compresser les fichiers statiques une fois les développements terminés (JS/CSS)                                                    |
Optimiser votre CSS : utiliser des chemins courts vers les images, utiliser la nature du CSS c’est à dire l’héritage, etc.                   |

Touches finales                                                                                                                              | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Créer des pages d’erreur / 404                                                                                                               |
Créer un favicon                                                                                                                             |

[^2]: Fortement inspiré de
      "[The Ultimate Website Launch Checklist](http://www.boxuk.com/blog/the-ultimate-website-launch-checklist)" et de
      "[La checklist d’accessibilité que je m’étais juré de ne pas rédiger](http://www.pompage.net/pompe/checklistaccessibilite)".

*[vs]: Versus
*[IE]: Internet Explorer
*[Fx]: Firefox
*[JS]: JavaScript
*[etc]: Et cætera
*[NOK]: Non OK
*[N/A]: Non applicable
*[CSS]: Cascading Style Sheets
*[AJAX]: Asynchronous JavaScript and XML
*[ARIA]: Accessible Rich Internet Applications
*[XHTML]: eXtensible HyperText Markup Language

• 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 !