La tête dans le Flux !

Papa, c’est quoi un mirage ? CSS3 mon fils !

Aujourd’hui, tout le monde parle de CSS3, tout le monde veut du CSS3, tout le monde s’extasie devant les démos faites en CSS3. Mais pourtant, CSS3 est un parfait mirage des temps modernes.

Voici le support des spécifications “CSS avancées” et CSS3 sur l’ensemble des navigateurs employés aujourd’hui :

Les chiffres sont éloquents : on ne peut raisonnablement pas employer CSS3 massivement en production aujourd’hui. Pour une raison simple : Internet Explorer.

J’ai bien commis un article semblant prôner le contraire, mais le constat est inéluctable : le support de CSS3 est quasi-inexistant sur IE6 à IE8 inclus. Point.

Même si IE6 et IE7 se meurent, leur frère IE8 n’est pas près de disparaître, et tout ce que IE8 sait faire, c’est reconnaître enfin la spécification CSS2 (12 ans après sa finalisation). Pour ce qui est de CSS3, il est dans les choux. Complètement.

De plus en plus de personnes souhaitent suivre mes formations CSS3, mais peu s’attendent à entendre autant de mauvaises nouvelles concernant sa compatibilité en production. Bien sûr il existe des alternatives, des “polyfills” et des bidouilles… mais un bon nombre de mes stagiaires espéraient vraiment pouvoir appliquer mes préceptes dans leur travail d’intégration au quotidien.

Au final (à cause de la “mode” ?), il passent à côté d’une multitude de bonnes pratiques vraiment utiles en production et facilitant la gestion d’un projet en CSS. Des CSS avancées et des bonnes pratiques datant de CSS2 bien entendu.

Je le répète encore : en 2012, il est grand temps d’apprendre… CSS2 !

Ne me faites pas dire ce que je n’ai pas dit : CSS3 est un outil qui s’annonce magnifique, mais en cours de rôdage et quasiment inutilisable en production sans concessions ou dégradation sur les anciens navigateurs.

Allez-y, tapez-moi dessus à grand coup de border-radius, même pas mal ! (PS : border-radius est compatible depuis… IE9)

Contribution à WedDesign Friday

“Introduction à la performance pour le Web mobile” est le sujet que j’ai traité sur le site du Webdesign Friday.

Comme je le précise, il s’agit d’une mise en bouche. Il y aurait matière à décortiquer chaque conseil et aller beaucoup plus loin que ce court article, mais il faut bien commencer par quelque chose, non ? ;)

Voici donc le billet en question : “Introduction à la performance pour le Web mobile”. Bonne lecture et n’hésitez pas à laisser vos retours directement sur l’article.

Rencontres Experts Eyrolles

Il y a quelques jours s’est déroulée chez Eyrolles une soirée de conférences autour du thème des meilleures pratiques du Web, et durant laquelle quelques auteurs ont pu s’exprimer devant un public d’une bonne centaine de personnes.

En compagnie de mon très estimé collègue Rodolphe Rimelé et d’autres gens tout aussi recommandables tels que Isabelle Canivet, Olivier Andrieu, Dominique Hazaël-Massieux, Gautier Barrère et Éric Mazzone, j’ai eu la délicate tâche de proposer une petite présentation de 15 minutes.

Officiellement sans slides, mais j’avoue avoir un peu triché :)

Ma présentation s’appelait “Bonnes pratiques pour le Web mobile”, est disponible sur Slideshare, et s’est articulée autour de trois axes essentiels : s’adapter aux dimensions, s’adapter au média et s’adapter aux performances.

Encore un énorme merci à Karine, Muriel, Elsa, Guillaume et les autres eyrolliens qui ont rendu cette manifestation possible et réussie !

Note : vous trouverez quelques photos de l’événement sur Facebook.

table-cell et responsive design

Il y a quelques jours, Vincent de Oliveira (futur orateur de notre presque célèbre Kiwi Partÿ) s’est amusé avec display table en vue de créer un gabarit “responsive”, c’est à dire qui s’adapte aux différentes résolutions d’écran.

Sa conclusion fut que l’exercice n’est pas aussi simple que prévu, et qu’en production il faudrait cumuler les imbrications d’éléments.

Étant un grand fan des tableaux, j’ai bien évidemment été frustré par ce verdict. Il n’en fallait pas plus pour me titiller et j’ai pris ça pour un défi à relever.

Le modèle d’affichage de type “display: table” a des particularités extraordinaires. L’une d’entre-elles est d’automatiquement générer des conteneurs anonymes. Par exemple, si un élément de type display: table-cell n’a pas de parent physique sous forme table-row ou table, il l’invente.

Le mécanisme des ancêtres anonymes est pour le moins complexe et alambiqué, mais va bien nous arranger pour relever le défi lancé.

En fait, je ne vais pas faire durer le suspense : il suffit de changer le rendu d’un seul élément en table-cell sans intervenir sur ses frères.

Vous verrez le résultat sur cette page de test.

Explications :

• En mode grand écran, chaque élément est affiché en mode de rendu “table-cell”. Il s’affichent donc 3 colonnes.
• En mode “tablette”, un seul des éléments passe en table-cell. Il se crée alors un contexte anonyme autour de lui (il s’invente un parent de type “table-row” et un grand-père “inline-table” ?) qui conduit à un affichage sous forme de 2 colonnes.
• En mode “mobile”, les éléments sont affichés sous forme de blocs, les uns sous les autres pour ne former qu’une seule colonne

Je vous disais bien que les tableaux de mise en page, c’est bien ! :)

Des CSS conditionnels ?

Les sélecteurs d’adjacence directe (signe “+”) et indirecte (signe “~”), respectivement issus des spécifications CSS2.1 et CSS3 mais qui ont la bonne idée d’être tous deux supportés depuis IE7 comptent parmi mes chouchous pour de nombreuses raisons.

L’une de ces raisons est qu’ils ouvrent la voie à des techniques de mises en forme conditionnelles : si je suis dans ce contexte, alors il va se passer ceci.

Quelques exemples concrets ne font jamais de mal…

Marge à gauche… ou pas

• Contexte : J’ai parfois une image à gauche de mes contenus, et parfois pas. L’image est flottante à gauche et le reste des contenus aura une marge à gauche de la largeur de l’image… mais ne doivent pas avoir de marge gauche s’il n’y a pas d’image.
• Sélecteur : img ~ *
• Explications : Ce sélecteur cible tous les éléments frères directement ou indirectement placés après une image. Il ne cible des éléments que s’il y a une image avant eux.
• Exemple : http://www.goetter.fr/livres/

Oh label verte !

• Contexte : Dans un formulaire, lors du clic sur une case à cocher, je souhaite que l’étiquette associée soit mise en exergue.
• Sélecteur : input:checked + label
• Explications : Le sélecteur cible un label qui suit immédiatement un champ coché, il ne s’active donc que si la case est cochée.
• Exemple : page d’inscription aux formations Alsacréations

Un bouton de soumission sous condition

• Contexte : Le bouton de soumission d’un formulaire ne doit apparaître que lorsqu’une case requise (par exemple CGV) est cochée.
• Sélecteur : input:invalid ~ [type=submit]
• Explications : un champ requis non rempli ou coché est considéré comme statut invalide. Le sélecteur masque donc (display none par ex.) le champ submit tant que la case n’est pas cochée.
• Exemple : http://www.ie7nomore.com/fun/form/

Planquez-vous derrière moi !

• Principe : Un menu de navigation apparaît au clic sur un lien. Tout le reste des contenus de la page doit être semi masqués (opacité réduite)
• Sélecteur : nav:target ~ section
• Explications : le sélecteur :target indique la cible d’une ancre. Lorsque la navigation apparaît, toutes les sections suivantes dans le DOM bénéficieront d’une opacity de 0.2 par exemple.
• Exemple : http://www.ie7nomore.com/fun/responsive-menu/menu2.html (réduisez la fenêtre)

Autres idées ?

Pas toujours très intuitif et explicite, ce type de sélecteur - compatible depuis des lustres je le rappelle - ouvre de larges horizons qui semblent généralement réservées à JavaScript.

Pour ma part, je ne me lasse pas de trouver chaque jour de nouveaux exemples concrets d’usage des sélecteurs d’adjacence.

Si vous avez d’autres expériences de ce type à partager ici, n’hésitez pas !