Chez Jérémie - Mot-clé - CSS

Des kiwis sans pépins

Jeremie — Sun, 06 May 2012 22:52:00 +0200

J’ai eu la chance de participer à la Kiwi Party organisé le 4 mai 2012 par l’agence Alsacréations. En toute simplicité, j’ai envie de dire : « c’était vachement bien ! ».

Avant toute chose, un grand bravo au staff qui a assuré grave pour faire de cette journée un franche réussite et un remerciement tout spécial à Mme. Goetter qui a passé 15 jours en cuisine pour nous offrir un goutaÿ™ épique

En suite, un grand merci également a tous ceux qui sont venu à Strasbourg pour assister à l’événement. votre enthousiasme, votre plaisir manifeste à être là ont fait de ce moment un moment exceptionnel.

Au niveau des conférences, nous avons eu droit à un panel de très bon orateurs avec des sujets allant du référencement au développement en passant par l’accessibilité et la conception. Une partie des conférences ayant eu lieu en parallèle les unes des autres, je n’ai pas pu voir tout ce que je voulais, mais heureusement, elles ont toutes été filmées. Vivement que ces vidéos soient diffusées car j’ai hâte de voir les conférences de Vincent de Oliveira sur les effets graphiques avancés et celle de Frédéric Kayser sur la gestion des images pour le Web.

Parmi celles que j’ai pu voir, deux ont plus particulièrement retenu mon attention :

« Le développement HTML5 au sein de Windows 8 » présenté par David Rousset. Il s’est agit d’une excellente introduction aux principes de développement d’applications HTML5 pour Windows 8. Ce fut vraiment l’occasion de voir à qu’elle point Microsoft a décidé de jouer le jeu des standards du Web. Et même si toute la couche d’accès au système (appelée WindowsRT) reste encore une API JavaScript propriétaire, je suis persuadé que le développement des Web API standards permettra à Microsoft de d’offrir toujours plus d’interopérabilité.
« Conquérir l’internet des objets avec les technologies web » présenté par Steren Giannini. Si j’ai malheureusement raté le début de la conférence, ce que j’en ai vu m’a passionné. En particulier, il est vraiment intéressant de voir à quel point le Web sort de plus en plus des navigateurs traditionnels pour aller se nicher là ou on ne l’attend pas. C’est également très instructif de réaliser à quel point la diversité des supports rend toute forme de prédiction sur l’usage, l’interactivité ou le rendu visuel complètement hasardeuse.

De mon coté, j’ai eu la lourde tache de clôturer la journée en proposant une introduction aux transitions et animations CSS3. Je suis bien sur très mal placé pour juger ma performance, mais le nombre de retours extrêmement positifs que l’on m’a fait laisse penser que ça s’est plutôt bien passé (J’ai même eu droit à une tape sur l’épaule et à un « super » de la part de Karl Dubost… je croie que désormais, je peux mourir l’esprit en paix :P). Les slides de cette présentation sont bien sur disponible en ligne :

Voila encore merci à tous. Vivement l’année prochaine

Lier CSS à Javascript : une mauvaise idée

Jeremie — Mon, 13 Feb 2012 09:30:00 +0100

J’ai récemment lancé un twitt qui a généré un nombre important et plutôt surprenant de réactions. Vous n’êtes pas sans savoir qu’actuellement, l’utilisation des préfixes vendeur en CSS est une source de grande tension. Parmi toutes les solutions qui existent pour essayer de limiter l’impact de l’usage de ces préfixes, le script -prefix-free de Lea Verou est une solution actuellement très en vogue… mais dont je déconseille très fortement l’usage.

Soyons clair, je n’ai pas l’intention d’alimenter le débat sur l’opportunité ou non d’utiliser les préfixes vendeur. Si vous les utilisez, utilisez les bien, utilisez toutes les variantes de tous les vendeurs. C’est tout.

Non, mon sujet ici, ce sont tous ces scripts Javascript qui vont conditionner l’usage de CSS lorsqu’ils sont utilisés dans un navigateur Web. -prefix-free bien sûr, mais également less.js, respond.js, cssFX, mediatizr, WebFont loader, etc. Je n’ai pas ici la prétention de vous convaincre de ne pas les utiliser. D’une part parce que vous faites bien ce que vous voulez (c’est aussi ça le Web) et d’autre part parce qu’il m’arrive même à moi de m’en servir et ce serait quand même assez gonflé de ma part de vous dire « faites ce que je dit, pas ce que je fait »

L’idée, c’est plutôt de vous détailler les risques auxquels vous vous exposez pour que vous puissiez ensuite faire votre choix en votre âme et conscience.

Performance

L’usage de ces scripts induit un certain nombre de biais dans les performances de vos sites. Souvent, les scripts comme -prefix-free sont appréciés car « ils permettent de réduire le poids des CSS ». Ce qui est vrai mais au prix du poids du script lui-même (le jeu en vaut-il la chandelle) et de requêtes HTTP supplémentaires (vous êtes sûr de n’avoir aucun problème de latence ?).

Au delà de ces points largement discutables il y a tout de même quelques autres éléments à considérer :

Le rendu complet de votre site est suspendu au chargement de vos scripts. Le temps de rendu peut donc être altéré si vous êtes sur des connexions de mauvaise qualité comme du EDGE en réseau mobile. Cela peut se constater de manière bénigne avec la présence d’un léger FOUC ou bien plus gravement en cas de problème de chargement du script ce qui peut complètement casser votre design.
Le rendu devient également dépendant des performances globales d’exécution de vos scripts. Avec un seul petit script qui va agir sur une petite feuille de style, vous ne verrez jamais de problème. Mais que va-t-il se passer avec plusieurs centaines de Ko de scripts et de feuilles de style ? Par exemple, un script comme -prefix-free est un script linéaire : plus la feuille de style sera grosse, plus il prendra de temps pour s’exécuter car il l’examine entièrement. Que se passera-t-il alors si ce script est ralenti ou gêné ou traité après tous les autres scripts de la page (ce qui inclut vos scripts, mais également ceux que vous ne connaissez pas et qui sont utilisés par les extensions ou les bookmarklets de l’utilisateur) ?

Bref, utiliser ce genre de script vous fait consommer des ressources que vous pourriez utiliser pour des choses plus importantes que du style avec tout les effets de bords potentiels que je viens de vous énumérer.

Maintenabilité

Un des principaux avantages mis en avant pour ces scripts, c’est la simplification de la maintenance. Raphael Goetter l’a d’ailleurs bien expliqué sur son blogue. Là, je crois qu’il faut s’y arrêter quelques minutes.

Chaque script apporte son lot d’avantages, mais il apporte également son lot de problèmes. Aucun script n’étant parfait du premier coup, vous allez également devoir assurer sa maintenance. Il vous faudra le mettre à jour en fonction de ses propres évolutions ou prendre le risque de vous retrouver coincé avec un outil qui ne vous rendra plus les services que vous attendiez.

Il faut prendre en considération que ces scripts sont intimement liés à vos feuilles de style car plus vous les voudrez génériques plus ils seront volumineux et potentiellement bugués. Concrètement, cela veut dire qu’à chaque fois que vous allez mettre vos feuilles de style à jour, vous allez devoir vous assurer que le script fait bien son travail. Cela signifie plus de tests et en cas d’erreur, plus de temps pour débuguer car vous aurez alors deux sources d’erreurs potentielles.

C’est particulièrement vrai avec un script du type de -prefix-free. Pour vous épargner de saisir quelques lignes de CSS en plus, vous vous rajoutez un risque projet non-négligeable. Tant que ça marchera, oui, vous gagnerez du temps. Par contre, à la seconde ou vous allez rencontrer un problème, vous allez perdre beaucoup de temps. Sera-ce plus ou moins que le temps gagné ? Difficile à dire car cela dépendra énormément de votre connaissance des technologies en jeu ainsi que des outils que vous utilisez. Mais encore une fois, pourquoi prendre un risque là ou vous n’en aviez pas avant ?

Et l’utilisateur dans tout ça ?

Alors malgré tout ça, faut-il vraiment renoncer à utiliser tous ces scripts pourtant bien pratiques ? Il n’y a pas de réponse simple à ça. Pour être franc, il n’y a jamais de réponse simple en matière d’utilisation des technologies Web. Les contextes projets sont tous différents et certains justifient pleinement l’usage de ces scripts.

Néanmoins, avant de les utiliser, je vous invite à vous poser les questions suivantes :

Le script que je vais utiliser me permet-il de compenser un manque de compétences (techniques ou organisationnelles) de l’équipe projet ?
Dans l’affirmative, cela reviens à essayer de mettre un pansement sur une plaie ouverte. Si la plaie est petite, cela permettra de patienter le temps que l’équipe se forme aux techniques requises. Si la plaie est profonde, ça ne fera que retarder le moment où il faudra prendre des mesures drastiques (et donc coûteuses) pour éviter l’infection.
Préférez un bon plan de formation à moyen terme et à court terme, prévoyez l’intervention d’un développeur sénior capable d’épauler l’équipe. Si vous travaillez seul, faites l’effort de vous former ou changez de métier.
Le script que je vais utiliser est-il là uniquement pour mon propre confort ?
Si c’est le cas, sachez que j’ai alors assez peu de considération pour vous (je sais, ça vous fait un belle jambe, mais au moins c’est dit). Ce genre d’attitude égoïste est exactement ce qui fait que le Web ouvert, standard et interopérable s’étiole. Si vous pouvez faire la même chose sans utiliser de script, faites le. Vous rendrez service à tout le monde en commençant par vous-même
Le script que je vais utiliser me permet-il d’améliorer l’expérience utilisateur ?
Là, effectivement on peut sans doute se permettre de l’utiliser. L’utilisateur devrait toujours être votre point de référence. Quand vous réalisez un site Web, il y aura toujours au final un utilisateur qui va s’en servir. C’est compliqué de se dire qu’on travaille pour un utilisateur. En effet, trop souvent, les promoteurs et acteurs d’un projet se concentrent sur leur propres préoccupations. Les developpeurs et la pureté technique, les responsables métier et leur ROI, les chefs de projet et leur suivi budgétaire, Les designers et leur égo démesuré… autant d’écueils qu’on a tous un jour rencontrés. L’utilisateur, c’est un peu la petite lumière dans la nuit… ne le perdez jamais de vue, c’est votre bouée de sauvetage.

Alors voilà, malgré toute ma bonne volonté et même si je trouve que -prefix-free ou cssFX sont de très beaux projets, les utiliser revient, pour moi, à répondre « oui » à ma deuxième question. Vous comprendrez donc qu’en ce qui me concerne, je ne peux pas cautionner son usage sur un site en production. Je peux comprendre qu’on n’ait pas envie de passer des heures à maintenir des listes sans fin de propriétés préfixées. Mais dans ce cas, faites plutôt le choix des préprocesseurs CSS (LESS, SASS, etc.) qui vous permettront de manipuler des feuilles de style plus simples tout en vous assurant qu’elles comporteront bien tous les préfixes qui vont bien au moment de leur publication.

PS : Merci à Julien et Richard pour la relecture de mon orthographe déficiente

Des effets pour le Web

Jeremie — Thu, 12 Jan 2012 09:00:00 +0100

Cet article est la traduction d’un article de Christian « Schepp » Schaefer à propos des nouvelles propriétés de filtres CSS3 et montre comment commencer à les utiliser tout en proposant des solution de repli basées sur ce que supportent les navigateurs actuels.

A la fin des années 90, CSS 2.1 nous a fourni un ensemble d’outils de base pour pouvoir enfin se débarrasser des mises en page en tableaux. Maintenant c’est le tour de CSS3 qui nous donne de nouveaux outils plus précis pour gérer les détails de mise en forme : Les fontes embarquées, les coins arrondis, les dégradés, la transparence des éléments et des couleurs, les ombre portées sur le texte et les boites, etc.

Évidement, lorsqu’on compare notre outillage à celui de logiciels comme Photoshop, on se dit qu’on pourrait rêver mieux. Ce genre de logiciel permet, par exemple, de désaturer une image ou bien de la rendre plus nette ou plus floue. Pourquoi aurions-nous besoin de ce genre d’outil pour le Web ? Et bien, désaturer ou flouter une partie de page Web peut être un moyen de guider le regard de vos visiteurs sur des zones choisies. Ça pourrais aussi aider vos visiteurs à concentrer leur attention sur les zones qui n’ont pas été modifiées. Par exemple, on peut utiliser ce genre d’effets pour mettre en scène une galerie d’images :

D’un autre coté, un effet de netteté peut être utile lorsque vous réduisez une image dans le navigateur. Sans lui, vous allez perdre un certain nombre de détails sur cette image.

Voila, ce serait génial si nous pouvions avoir ce genre d’effets à notre disposition, un peu comme la propriété CSS opacity qui nous permet de rendre un élément transparent. Malheureusement, ce n’est pas le cas.

Le status quo actuel

Au lieu de cela, pour simuler un effet de désaturation/niveau de gris nous sommes actuellement obligés de passer en revue « à la main », via Javascript, toutes les propriétés utilisant de la couleur sur un éléments donnée pour leur attribuer la valeur de gris que l’on veut. Dès que l’on doit faire face à des images ou de la vidéo, c’est encore plus compliqué : Dans ce cas-là, nous avons besoin de nous appuyer sur la balise Canvas de HTML5 pour pouvoir changer leur couleur pixel par pixel puis pour remplacer l’élément d’origine. Même si nous nous appuyons sur des bibliothèques tel que CamanJS ou Hoverizr, ça reste quand même un truc assez sale.

Un effet de flou peut également être simulé à l’aide des propriétés text-shadow et box-shadow en leur appliquant la même couleur que le texte ou l’arrière-plan auquel elles se rapportent. Le problème, c’est que cette illusion ne fonctionnera pas avec les boîtes multicolores non plus qu’avec les images ou les vidéos comme précédemment. Une fois de plus, il faudra se reposer sur des manipulation à base de Canvas HTML5. Arf!

Á propos de la balise Canvas: La bibliothèque blurry.js propose une solution particulièrement brutale à cette histoire de flou. Elle va extraire tout le contenu à flouter, va le recréer dans une balise Canvas (en utilisant partiellement Cufón), va le flouter et enfin va réinjecter le tout à l’emplacement de l’original.

En ce qui concerne la netteté, il n’existe actuellement aucun truc basé sur CSS pour réaliser un tel effet, ce qui nous laisse une fois de plus seul face à la balise Canvas.

SVG à la rescousse

Il est intéressant de noter que SVG connaît la notion de filtres depuis des lustres avec, entre autre, les mélanges de couleurs, l’ajustement de la luminosité et du contraste, les effets d’éclairage, le « displacement mapping », les flous gaussien et de déplacement, le bruit, la netteté, etc.

Ainsi, maintenant que SVG est de plus en plus largement supporté, nous pourrions essayer de placer nos contenus, non plus dans du HTML, mais plutôt dans du SVG que l’on placerait dans du HTML. Nous serions alors capables d’appliquer n’importe quel effet à notre contenu. Le problème, c’est que la plupart des intégrateurs HTML risquent de ne pas être très chauds pour se mettre à produire du balisage SVG de ce genre :

<text font-family="Arial" font-weight="900" font-size="40" x="20" y="55%">SVG Example</text>

Il existe un truc un peu plus sympa en SVG, c’est la balise foreignObject. Elle nous permet d’inclure n’importe quel type de balisage à l’intérieur d’un contenu SVG. C’est un peu comme mettre du SVG directement dans un document HTML5, mais dans l’autre sens. Dès que vous avez inclus vos trucs dans du SVG, vous pouvez y appliquer des filtres comme vous le feriez pour n’importe qu’elle autre partis de votre contenu SVG. Vous pouvez embarquer une page HTML entière et lui appliquer des filtres, ou vous restreindre à une simple image bitmap. Bien sûr, vous devez mettre votre contenu SVG lui-même dans une page HTML, ce qui peut conduire à quelques migraines (du HTML embarqué dans du SVG embarqué dans du HTML). Le support navigateur pour la balise foreignObject est plutôt bon. Seul Internet Explorer reste à la traine. Heureusement, Internet Explorer 10 va rattraper le coup en supportant à la fois les filtres SVG et la balise foreignObject.

Les filtres SVG sur du contenu HTML via CSS

Depuis sa version 3.5, Firefox va encore plus loin. Il vous permet d’appliquer un filtre SVG, défini dans un document externe, à n’importe quel contenu HTML en passant simplement par une feuille de style. Nous pouvons, par exemple, définir dans un document SVG un filtre de flou gaussien (feGaussianBlur) ayant un rayon de 2 pixels et lui donner l’identifiant gaussian_blur :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="1" height="1" version="1.1" 
xmlns="http://www.w3.org/2000/svg" 
xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
    <filter id="gaussian_blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="2" />
    </filter>
  </defs>
</svg>

On peut alors référencer ce filtre à l’aide du nom du fichier SVG et de son l’identifiant au sein de notre feuille de style pour l’appliquer à toutes les images :

img {
    filter: url(blur.svg#gaussian_blur);
}

Vous pouvez voir cette démo en live ici. Hélas, comme je vous le disais, ça ne fonctionne qu’avec Firefox.

Bien heureusement, ce n’est pas la fin de l’histoire. Internet Explorer connaît lui aussi les filtres. Ceux-ci ne sont pas basés sur SVG, mais sur des mécanismes propres à la bibliothèque graphique de Windows : DirectX. Parmi ces filtres certains sont bien connus pour nous aider à résoudre certains bugs (le filtre alpha pour les image PNG) ou pour imiter certaines fonctionnalités de CSS3 (le filtre des dégradé). Néanmoins, il en existes d’autres très similaires aux filtres SVG :

/* Flou de 2 pixels de rayon */
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
/* Flou de mouvement de 13 pixel avec un angle de 310° */
filter: progid:DXImageTransform.Microsoft.MotionBlur(strength=13, direction=310);
/* niveau de gris / désaturation */
filter: gray;
/* Effet « Rayon X » (inversion des niveaux de gris) */
filter: xray;
/* cône de lumière */
filter: light();
/* Extrusion */
filter: progid:DXImageTransform.Microsoft.emboss();

Vous trouverez une liste complète de ces filtres ici : http://msdn.microsoft.com/en-us/library/ms673539(v=VS.85).aspx

Ainsi, à l’aide de commentaires conditionnels, nous pouvons désormais proposer un certain nombre d’effets à deux familles de navigateurs qui à elles deux représente une part non négligeable du marché :

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--> <html lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

margin: -2px permet de contre balancer le changement de dimension de l’image provoqué par le filtre. zoom: 1 est necessaire pour que la plupart des filtres fonctionnent avec in IE6/7. Malheureusement, IE10 ne supporte plus les filtres propriétaires de Microsoft et n’autorise pas encore les filtres SVG sur du contenu HTML

Vous trouverez ici la version modifié de l’exemple

Un certain nombre de personnes ont apprécié l’idée de Firefox d’ouvrir les filtres SVG au contenu HTML. Ils ont donc formé un nouveau groupe au W3C appelé W3C FX Task Force dont l’objectif est de standardiser et simplifier l’usage des filtres SVG dans tous les navigateurs. Puisque Firefox avait défriché le terrain des filtres d’effets, le premier brouillon de spécification est vite arrivé sous le nom de W3C Filter Effects 1.0. Les mécanismes proposés dans ce brouillon fonctionnent à peu près comme dans Firefox tout en offrant en plus un certain nombre de raccourcis vers les effets les plus intéressants. Les filtres bénéficiant d’un raccourci fonctionnent sans l’aide d’un fichier SVG externe. Ils sont directement codés au cœur du navigateur. Les raccourcis en question sont :

grayscale
sepia
saturate
hue-rotate
invert
opacity
brightness
contrast
blur
drop-shadow

Un autre avantage de ces raccourcis, c’est qu’ils peuvent être animés via les transformations et les animations CSS :

.foo {
  filter: blur(2px);
  transition: filter 1s ease-in-out;
}
 
.foo:hover {
  filter: blur(0);
}

Ce serait plus difficile et moins efficace de réaliser cela dans un document SVG.

Pour finir, les effets de filtre prévois d’être enrichie à l’aide des vertex shaders et fragment shaders d’OpenGL/WebGL. Les vertex shaders permettront d’appliquer un maillage 2D sur un élément que vous pourrez alors déformer en déplaçant tous les points du maillage selon une formule mathématique de votre choix. Les fragment shaders d’un autre côté permettront de réaliser ces transformations mathématiques sur les couleurs de chacun des pixels de cet élément. Ces deux types de filtres bénéficieront en plus de l’accélération matérielle de votre carte graphique.

Par un heureux hasard, il y a quelques semaines les premières implémentations de ces filtres sont apparues dans les compilations nocturnes de Webkit et sont à présent disponibles dans Chrome Canary. Ça veut dire que d’ici 3 mois les filtres CSS seront disponibles dans la version stable de Chrome et à brève échéance dans Safari. Ça veut également dire que nous ne sommes pas loin de pouvoir commencer à utiliser des filtres CSS sur 90 à 95% du marché des navigateurs !

Si l’on en revient à notre exemple, tout ce que nous avons à faire pour supporter Webkit est de rajouter un simple -webkit-filter: blur(2px);. Néanmoins, il faudra faire attention de le placer après la propriété filter non-préfixée. La raison étant que lorsque Webkit supportera la version non-prefixée de la propriété filter, la syntaxe propre à Firefox créra des problèmes avec la transition CSS que nous allons appliquer pour passer doucement entre la version flou et nette de l’image via -webkit-transition: -webkit-filter 1s ease-in-out;.

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie"> <![endif]-->
<!--[if gt IE 9]><!--> <html> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
  -webkit-filter: blur(2px);
  -webkit-transition: -webkit-filter 1s ease-in-out;
}
img:hover {
  filter: none;
  -webkit-filter: blur(0);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
.ie img:hover {
  margin: 0;
  filter: none;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

La dernière version de l’exemple

Et voila, des effets de filtres pour tout le monde ! Faisons de 2012 l’année des filtres CSS et amusez-vous bien avec.

Paris-Web 2010 : CSS3 Aujourd'hui

Jeremie — Wed, 16 Feb 2011 13:00:00 +0100

Maintenant, que les vidéos sont en ligne, voici un petit retour sur Paris-Web 2010 ou j’ai animé un atelier sur le thème “CSS3 Aujourd’hui”.

Depuis maintenant 5 ans, Paris-Web, c’est un peu le rendez-vous annuel des faiseurs de Web français. Cette année fut assez exceptionnelle, et tous les participants (visiteurs, orateurs et organisateurs) sont tous à peu près d’accord pour dire que c’était un excellent millésime (si ce n’est le meilleur pour l’instant). Les conférences étaient d’un niveau exceptionnel, l’organisation sans tache et le hashtag #sharethelove a été largement employé sur Twitter pour qualifier l’ambiance générale (bon, on n’a pas pu éviter tous les trolls, mais ça s’est bien passé).

Sur les conférences, j’ai noté en particulier celle de Anne-Sophie Fradier sur la macro-typographie (qui a subtilement servi de tremplin au projet que j’ai monté avec elle et d’autres d’un site dédié à la typographie sur le Web) et celle de Paul Rouget sur les nouvelles API issu de HTML5. Paul était super content car d’une part tout a marché et les démos montrées étaient franchement bluffantes (faire un sondage en live grâce aux Web Sockets, c’est un peu la classe quand même).

De mon coté, j’ai animé un atelier sur le thème “CSS3 Aujourd’hui”. J’y ai passé en revue ce qu’il est possible de faire dès à présent avec CSS3 en commençant quand même sur quelques rappels importants liés à CSS2. En effet, CSS3 n’est jamais qu’une “amélioration” de CSS2. L’atelier s’est bien passé mais il a duré 1h30, là ou j’avais du matériel pour 3h. Ceci dit, grâce à la vidéo, je me rends compte que ça ne s’est pas trop vu (sauf vers la fin), même si je n’ai pas pu entrer dans le code autant que je le voulais. Ceci dit, il a été possible de bien discuter avec la salle (c’était le but, mais dans la vidéo c’est un peu frustrant car il n’y avait pas de prise de son d’ambiance) et les principaux thèmes ont pu être vu.

Si vous y étiez ou si vous voulez voir les exemples en même temps que vous regardez la vidéo, toutes mes slides sont disponibles :

http://jeremie.patonnier.net/experiences/parisweb2010/

Ainsi que tous les exemples de code :

http://jeremie.patonnier.net/experiences/parisweb2010/exemples/

Et donc, la vidéo de l’atelier car cette année pour la première fois, certains ateliers ont été filmés (merci aux étudiants de Cifacom et à l’équipe Paris-Web pour le boulot réalisé) :

Arrétez de me casser les gonades avec border-radius

Jeremie — Mon, 03 Jan 2011 09:00:00 +0100

Ça faisait longtemps que je ne m’était pas énervé et pour bien commencer la nouvelle année, sachez le, j’en ai un peu marre. Marre de quoi me diriez-vous ? J’en ai marre de ces intégrateurs qui se gargarisent avec border-radius, marre de ces gens qui ne jurent que par box-shadow, marre de ces crétins qui réduisent CSS3 au module “Border & Background”. Border-radius, c’est l’arbre qui cachent la forêt. CSS 3 est d’une richesse incroyable et pour l’instant, les constructeurs de navigateurs n’implémentent que de toutes petites choses, le gros reste à venir (et si vous prenez 5 minutes pour aller survoler les specs, même pas les lire, juste les survoler, vous verrez qu’il y a du lourd).

Soyons clairs, aujourd’hui, les seuls gars que je prend au sérieux à propos de CSS 3, ce sont ceux qui me parlent des sélecteurs et des Media Queries CSS 3 car c’est là que se cache la vraie puissance actuelle de CSS 3 (et pour le future les transformations 2D et 3D, les différents systèmes de positionnements et de mise en page, la génération de contenu, etc. autant dire que ça va être la fête du slip le jour où on aura tout ça dans nos boites à outils). Si vous voulez vous la péter avec le module “Border & Background”, c’est possible. Mais dans ce cas, c’est du coté de border-image qu’il faut aller fouiner et surtout, surtout, arrêtez de vous extasier sur border-radius et box-shadow qui ne sont que de la poudre au yeux.

Voilà pour l’échauffement, passons à la mise à mort. Je vais vous détailler pourquoi border-radius et box-shadow ne sont que des résidus de cagoinces (si, si).

Le cas border-radius

Combien de fois ai-je entendu “Oui, mais tu comprends, pour les bords arrondis, border-radius, c’est mieux”. Mieux ? Mieux que quoi exactement ? Non parce que sans déconner, moi, intégrer des bords arrondis, ça fait plus de 10 ans que je le fait. Ok, ne soyons pas de mauvaise foi, border-radius permet de faire des bords arrondis “sans image” ni “sur-balisage HTML” ni “Javascript”. C’est donc bien une autre méthode, parfois plus légère, pour réaliser des bords arrondis simples. Mais je ne vois pas en quoi c’est “mieux” :

Pas d’image : Donc ça c’est un non-argument absolue. Que dites-vous ? Économiser des requêtes HTTP pour les performances ? Vous ne connaissez pas les DATA URL ? Qui sont implémentées par tous les navigateurs qui supportent border-radius et avec des équivalents pour les vieux IE ! Mmmh ? Réduire le poids des pages Web ? Non sans rire, vous en êtes à optimiser 500 octets d’image (le poids maximum d’une image correctement compressée pour faire l’équivalent de ce que permet border-radius) ! Vous êtes sur que vous n’avez pas autre chose à optimiser avant, comme la durée de vie du cache de vos ressources statiques par exemple ? Accessoirement, l’utilisation d’images pour gérer les bordures offre d’énormes avantages graphiques car elles permettent de créer des formes bien plus subtiles et complexes donc, allez plutôt trifouiller border-image et apprenez à faire des sprites CSS, hein.
Pas de sur-balisage HTML : Ceci est un argument presque recevable sauf que… Sauf que dans la vraie vie, ce n’est vraie que si vous cherchez à intégrer des boites qui s’élargissent à la fois en hauteur et en largeur et qui doivent s’afficher avec des coins transparents. Une fois sortie de ce cas de figure, somme toute assez rare, il y a 9 chances sur 10 (voir 9,9 si vous vous intéressez aux sélecteurs CSS 3) que votre code source soit suffisamment balisé pour vous permettre de rajouter des bords arrondis sans avoir à vous casser la tête sur le HTML (et je ne vous parle même pas d’utiliser des techniques un peu délicates comme les pseudo-éléments CSS).
Pas besoin de Javascript : Donc, là, vous ne le voyez pas, mais je suis sous mon bureau, ravagé par une crise de fou rire. Si vous avez tout lu jusque là, vous aurez sans doute deviné que je n’ai jamais utilisé une once de Javascript pour produire des bords arrondis. Mais même si c’était le cas… en toute honnêteté, c’était quand la dernière fois que vous avez créer un site qui n’embarque pas une bibliothèque Javascript à tout faire (jQuery, Prototype, YUI, etc.) ? Accessoirement, si vous avez pris de bonnes habitudes en terme de Javascript non-intrusif, ça ne devrait pas vous poser l’ombre d’un cas de conscience.

Alors, oui, border-radius, ça peut être plus simple et plus rapide… mais c’est aussi très limité dès que vous voulez essayer de produire des bordures un peu chiadées graphiquement parlant (genre avec un petit reflet de lumière ou avec un petit déséquilibre dans les formes… bref, si vous voulez un truc un peu moins raide). Et dans ce cas-là… mmmh… je crois qu’il y a un truc en CSS 3 qui s’appelle border-image.

box-shadow, ni fait, ni à faire

Ayant donc d’autorité décrété que border-radius c’était plutôt “bof”, je vais maintenant faire de même avec box-shadow.

Box-shadow est cette propriété qui, comme son nom l’indique, permet de créer des ombres portés et, comme son nom ne l’indique pas, des effets de halo, de lumière et même… de bordures ! Et oui ! En soit, c’est une propriété intéressante (en tout cas beaucoup plus que border-radius), dès qu’on cherche à la tordre pour en faire autre choses que ce qu’elle suggère. Malheureusement, elle souffres de quelques défauts que je qualifie assez volontiers de majeur :

Les ombres (ou lumières) générées sont carrées ou plus exactement, elles ont la forme exacte de la boite sur laquelle la propriété est appliquée (ce qui inclue l’usage de border-radius heureusement, mais pas la transparence des images, j’y reviens plus loin). Certes, elles peuvent être distendues ou contractées homothétiquement, mais pas déformées à l’envie. Donc, si vous souhaitez créer des effets graphiques un peu travaillés, du genre feuille-de-papier-qui-se-décolle-sur-un-coin, vous repassez par la case image (et vous ne touchez pas 20 000 Francs, votre client n’en ayant rien à foutre que vous galériez à produire l’effet qu’il attend… il fallait y penser avant).
Si vous ne mettez pas une couleur d’arrière plan à la boite qui génère l’ombre, celle-ci sera… troué ! Et oui, c’est la spec qui le dit : The shadow is drawn outside the border edge only: it is clipped inside the border-box of the element.. En clair, la partie de l’ombre qui est sous la boite correspondante n’est pas rendue et puis voilà, c’est tout… iiirk ! Vous pourriez m’objecter que ça peut être utile. Oui, c’est vrai, mais pas toujours et comme ce n’est pas paramétrable, c’est chiant.

Donc, de deux choses l’une : Soit vous atteigniez le niveau zéro du web design (et franchement, une boite à bord arrondi et/ou avec une ombre porté, oui, c’est le niveau zéro du web design ; le truc que tous les apprentis intégrateurs font le premier jour où ils découvrent les joies de CSS) et avez besoin de produire de simples ombres portées ou des effets de lueur interne sur une boite, dans ce cas, c’est ok, cette propriété est faite pour vous ; soit vous voulez réalisez des effets un peu plus complexes et vous allez vite vous rendre compte que ce n’est pas plus simple ou pire, que c’est carrément limité et vous allez alors soit vous rabattre vers l’utilisation d’images (là encore, border-image peut bien vous aider… oui, je sais, je suis un peu lourd là, mais il faut vraiment voir toute la souplesse graphique qu’offre cette propriété) soit, si vous êtes un peu plus aventureux, vous allez regarder du coté des filtres SVG (aventureux car pour l’instant, l’application de filtres SVG sur des éléments HTML ne fonctionne qu’avec Firefox 4… qui n’est pas encore sorti au moment ou je publie ce coup de gueule).

Je ne suis pas le seul à penser que box-shadow est une propriété mal finie. En effet, les développeurs de webkit ont implémenté une autre propriété d’ombre : -webkit-svg-shadow. Cette propriété ne fait actuellement l’objet d’aucune normalisation, mais elle est une tentative pour porter la souplesse des ombres SVG vers CSS sans avoir à subir toute la lourdeur des primitives de filtres SVG. L’idée étant d’avoir une propriété qui gère pleinement la transparence des boites HTML et des images pour créer des ombres qui ont des formes complexes. En effet, essayez d’appliquer box-shadow à une image transparente… l’ombre sera carré : fail ! (Ceci étant dit, les développeurs de Webkit ferait mieux de travailler sur l’implémentation de box-shadow. Essayez de créer une ombre interne sur une boite avec border-radius et vous comprendrez de quoi je parle).

Conclusion

Aaaah, je me sens mieux !

Vous l’aurez compris, en ce qui me concerne ces deux propriétés ne méritent pas l’attention qu’on leur porte. Certes, elles apportent des solutions élégantes à certains problèmes communs d’intégration mais sans non plus porter à elles seules la révolution qu’est CSS3. De fait, je ne les renie pas car elles ont leur utilité (et il m’arrive même de les utiliser, si, si !). Cependant, il existe moult autres propriétés CSS3 en cour d’implémentation qui sont infiniment plus utiles (mais aussi infiniment moins sexy). En particulier, je vous invite à regarder de près ce qui ce fait au sein du module CSS Basic UI avec en particulier les propriétés box-sizing et pointer-events qui sont assez discrètes mais super utiles au quotidien (non mais vraiment !) ainsi que toutes les pseudo-classes de ce module et du module CSS selecteur Level 3. Ah ! Et au fait, est-ce que je vous ai parlé de border-image ?

:before et :after, des pseudo-éléments qui ont du style

Jeremie — Mon, 22 Nov 2010 09:00:00 +0100

En ces temps de buzz autour de CSS3, on en oublie les supers outils qui existent dans CSS2 et qui sont largement exploitables. Parmi ceux-ci, on trouve les pseudo-éléments :before et :after. Ces pseudo-éléments ont longtemps été négligés par les designers et intégrateurs Web pour deux raisons essentiellement : Premièrement, IE6 et IE7 ne les comprennent pas, donc à l’époque ou ces deux navigateur était dominant c’était inutilisable ; Deuxièmement, les ayatollahs de l’accessibilité stigmatisent assez volontiers ces deux pseudo-éléments (parfois à raison) ce qui a tendance à effrayer les designers et intégrateurs qui finalement s’y intéressent peu.

Pourtant, ces deux paravent masquent la puissance de ces outils. Le premier point est facilement contournable avec un peu de Javascript et le deuxième point est totalement injustifié dès lors qu’on utilise ces pseudo-éléments pour ce qu’ils sont : des aides à la mise en forme. Je vais donc vous montrer comment fonctionnent ces pseudo-éléments, vous allez voir, c’est génial

Des pseudo quoi ?

CSS2 définie donc deux pseudo-éléments sobrement accessible via les sélecteurs :before et :after. Hop, hop, hop… pseudo quoi ? Comme son nom l’indique, un pseudo-élément est un truc qui ressemble à un élément, qui a le gout d’un élément, qui se comporte comme un élément… mais qui n’en est pas un. Et oui, les pseudo-élément CSS sont à HTML ce que la bière sans alcool est… euh… à la bière.

Diantre, un élément qui n’en ait pas un ! Aurais-je donc trop bu de l’alcool sus-nommé ? Que nenni. La principal différence technique entre un pseudo-éléments et un élément “normal” se résume assez simplement : Les pseudo-éléments n’apparaissent jamais dans l’arbre DOM des documents mais influencent sur le rendu visuel de celui-ci comme si c’était le cas.

Cet état de fait à deux conséquences :

Toutes les aides à l’accessibilité qui reposent sur l’exploitation du DOM ne “verront” jamais les pseudo-éléments.
Manipuler les pseudo-éléments via Javascript ne peut pas se faire via l’API DOM, mais uniquement via des modifications de style (et encore, difficilement).

Emplacement et comportement

Maintenant que vous avez compris ce que sont ces pseudo-éléments, comment ceux-ci s’intègrent dans le rendu visuel des éléments traditionnels ?

Un pseudo-éléments est toujours défini relativement à un élément réel (c’est à dire qui existe dans l’arbre DOM). Cela signifie, qu’il est visuellement rendu comme un enfant de cet élément réel (et pas comme un élément frère placé avant ou après l’élément de référence contrairement à ce qu’on pourrait croire). :before désignera donc le pseudo-élément qui sera visuellement placé avant le premier enfant de l’élément de référence et :after désignera le pseudo-élément qui sera visuellement placé après le dernier enfant de l’élément de référence. Notez que si vous utilisez ces deux sélecteurs tout seul, cela reviens à faire une utilisation implicite du sélecteur universel *. Ainsi, la règle :before{...} seule est équivalente à la règle *:before{...}.

En outre, un pseudo-élément va se comporter visuellement de la même façon qu’un élément HTML span. Arrêtons-nous ici un petit moment car c’est sans doute le point le plus important à comprendre pour arriver à devenir créatif avec les pseudo-élément. Je le redis : un pseudo-élément va se comporter visuellement de la même façon qu’un élément HTML span.

Un bon schéma valant mieux qu’une longue explication voila ce que ça implique.

Dans le premier cas, l’élément référent ne contient que du texte, les pseudo-éléments vont donc s’inclure dans le flux du texte. Dans le deuxième cas, l’élément référent contient un enfant de type bloc, les pseudo-éléments vont donc se placer avant et après ce bloc.

Génération de contenu

Voila, les pseudo-éléments ont trouvé leur place et on peut leur appliquer tous les styles disponibles pour les mettre en forme, c’est génial… sauf que… Sauf que ce ne sont que des boites vides. Certes, les perspectives ouvertes sont déjà assez immenses quand on a un peu d’imagination (et Dieu sait qu’il faut en avoir pour faire de l’intégration Web !). Mais là ou ça devient vraiment fun, c’est quand on commence à remplir ces pseudo-éléments avec du contenu.

Normalement, c’est quand on en arrive à ce point qu’on assiste à une levée de boucliers des intégristes de l’accessibilité… les sots ! En général, leur argument principal est que les contenus générés n’étant pas présent dans le DOM, tout les outils d’accessibilité ne peuvent pas exploiter ces contenus (sans parler des navigateurs qui ne comprennent tout simplement pas les pseudo-éléments). C’est vrai, et il est important de s’en souvenir. Ceci étant dit, il est bon de rappeler que tout les contenus n’ont pas à êtres accessibles, surtout s’ils servent un objectif décoratif. Donc, OUI, c’est possible de générer du contenu en CSS si celui-ci n’a qu’une vocation décorative. Pire ! J’irai plus loin, je vous le recommande. En effet, générer des contenus décoratifs en CSS réduit le bruit autour des contenus devant être accessible. Et donc, bien utilisés, :before et :after peuvent vous aider à améliorer l’accessibilité de vos sites.

La génération de contenu dans un pseudo-éléments passe par l’utilisation de la propriété CSS content. Cette propriété peut accepter plusieurs valeurs différentes selon ce que vous voudrez générer. Notez que même si vous ne voulez qu’une boite vide, vous devrez utiliser la propriété content avec une chaine vide. En effet, la valeur par défaut de cette propriété (normal) fait que les pseudo-éléments ne sont pas affichés.

Du texte

Le plus simple à faire c’est de générer du texte. Cela ce fait très simplement de la manière suivante :

div.alert:before{
   content : "WARNING: "; 
/* Ici, vous préfixez tous vos messages d'alerte avec un texte qui n'a pas besoin d'être accessible. C'est un choix de design acceptable s'il existe dans la page HTML un autre moyen d'identifier ces messages comme étant des alertes. Si ce n'est pas le cas, vous commettez une grave erreur d'accessibilité.. En effet, si vous générez beaucoup d'alertes, il peut être fastidieux d'entendre une revue d'écran vous dire "WARNING-DEUX-POINTS" en permanence. Ici, ce ne sera pas le cas ;-) */ 
}

MAJ du 24/11 : Suite au échanges dans les commentaires avec Stéphane “Roudoudou d’amour” Deschamps, il est nécessaire de comprendre que toute insertion de texte via CSS doit être soupesé avec attention car les conséquences en terme d’accessibilité peuvent être importante.

Notez que vous pouvez mettre n’importe quel caractère Unicode dans une chaine générée. La syntaxe pour insérer un code Unicode est \00XXXX ou la chaine XXXX représente le code Unicode hexadécimal de votre caractère. Petite exception à cela¹, les retours à la ligne disposent d’un raccourcis : \A. Par exemple, si vous voulez rajouter une espace insécable avant un deux-points, ça donnera :

label:after{
   content : "\00202F:"; 
/* Là aussi, vous n'avez peut-être pas forcément envie que votre revue d'écran vous dise "DEUX-POINT" tout le temps hein ? */ 
}

Des images

Il est également possible d’inclure des images grâce à la fonction url(). Ce qui donnera :

div.alert:before{
   content : url(exclamation.png);
}

Des compteurs

Très utile si on veut numéroter des éléments (que ceux-ci soient ou non des listes ordonnées n’a aucune importance) comme des titres par exemples. Pour cela, il faut utiliser les fonctions counter() ou counters() en conjonction avec les propriétés counter-reset et counter-increment. Je ne vais pas vous détailler l’usage des compteurs qui mériterai un article à lui seul, mais cela fait également partis de ces outils sous-estimés de CSS2. Voici un petit exemple simple :

body{
   counter-reset: alert; /* On défini le compteur avec un nom arbitraire */
}

div.alert:before{
   counter-increment : alert;
   content : counter(alert, decimal);
/* avant la virgule, c'est le nom du compteur, après la virgule, c'est son style. La valeur du style est la même que pour la propriété list-style-type */
}

Des valeurs d’attribut

Enfin, il est possible de récupérer et donc d’afficher les valeurs des attributs de l’élément référent qui contiendra les pseudo-éléments. Je ne vous met pas d’exemple, mais je vous invite à relire l’article que j’ai écris sur ce sujet : Améliorez vos liens avec la génération de contenu CSS.

Grand Schelem, Belote et Quinte Flush Royal

Et le plus beau dans tout ça, c’est que vous pouvez mixer tout ça ensemble :

body{
   counter-reset: alert;
}

div.alert:before{
   counter-increment : alert;
   content : url(exclamation.png) "\00202FWARNING\00202F" counter(alert) "\00202F: ";
/* Notez que je n'ai pas remis le style du compteur. Son style par défaut est "decimal" */
}

Ceci dit, soyez raisonnable, ce n’est pas parce qu’on peut le faire qu’on doit le faire Pensez aussi et surtout à vos utilisateurs.

Cas d’usage

La théorie c’est bien, la pratique c’est mieux. Voici quelques cas d’usage, mais je suis sur que vous saurez en trouver d’autres

puces et numérotation

Les conteurs vous permettent d’une part de reprendre le contrôle des puces et numéros sur les listes, mais vous permettent également de numéroter d’autre choses, des titres par exemple :

article{
   counter-reset : c1 c2 c3;
}

article h1{
   counter-increment : c1;
}

article h2{
   counter-increment : c2;
}
 
article h3{
   counter-increment : c3;
}

article h1:before{
   content: counter(c1) ". ";
}

article h2:before{
   content: counter(c1) "." counter(c2) ". ";
}

article h3:before{
   content: counter(c1) "." counter(c2) "." counter(c3, lower-alpha) ". ";
}

> Voir l’exemple des conteurs sur les titres

Bords arrondis

Voici une utilisation avancé des pseudo-éléments. Habituellement, lorsque vous voulez réaliser des bords arrondis avec CSS2, vous êtes obligé de rajouter du balisage HTML (ou SVG, ou VML) pour pouvoir avoir assez d’éléments à styler pour chacun des coins (peut importe que cet ajout de balises soit fait à priori dans la source HTML ou à posteriori via Javascript, le principe reste le même). Plutôt que de polluer le DOM du document (ce qui peut avoir des conséquences fâcheuses avec certains sélecteurs CSS2 et 3), vous pouvez avantageusement exploiter les pseudo-éléments pour afficher vos coins.

En effet, en positionnant votre élément de référence de manière relative et en positionnant vos pseudo-éléments de manière absolute (et en exploitant correctement la propriété z-index), vous vous retrouvez avec un élément qui potentiellement dispose de 3 couches d’arrière-plan et de deux emplacement pour des images supplémentaires. En claire, vous pouvez empiler jusqu’à 5 images pour créer des effets graphiques de malade.

Schématiquement, cela donnera un empilement des éléments de ce genre :

Le code CSS associé à ce schémas est le suivant :

div{
   position : relative;
   z-index : 0;
}

div:before,
div:after{
   content : "";
   position : absolute;
   z-index : -1; /* Oui, z-index accepte les valeurs négatives */
   top : 0;
   left : 0;

   width : 100%;
   height : 100%;
}

div:after{
   z-index : -2;
}

Cette technique souffre tout de même de quelques limites (sinon, ce ne serait pas drôle) :

Les contenus des pseudo-éléments étant considérés comme du texte en ligne, ils peuvent être délicat à positionner ailleurs que en haut et à gauche du pseudo-éléments (c’est possible, mais ça donne lieu à des contorsions techniques un peu disgracieuses à mon gout)
Si vous voulez avoir des coins arrondis sur une boite extensible en largeur ET en hauteur, les coins ne pourront pas être tous transparent (par contre, pour une extension sur un seul axe, c’est possible).
La gestion des margin et padding de l’élément de référence demande un peu d’attention pour être sur que les pseudo-éléments se comportent correctement (une petite révision du modèle de boite et du positionnement CSS n’est pas inutiles ).

> Voir l’exemple des bords arrondis

Décoration de contenu

De manière général, les pseudo-éléments vous permettent de sortir du cadre (littéral) imposé par le modèle de boite CSS pour décorer les éléments.Voici quelques exemples simples.

La création de guillemets graphiques autour des éléments blockquote

Un exemple simple pour habiller les éléments blockquote consiste à créer des guillemets avec :before et :after et à les “faire sortir” pour leur donner une valeur graphique.

Notez que pour faire de “vrai” guillemet via CSS, il existe aussi la propriété quote qui est mieux adaptée (surtout pour gérer la localisation des règles typographiques)

> Voir l’exemple des blockquote

Réaliser des icônes sous forme de fontes

Avec la démocratisation de @font-face, on voit arriver certains usages un peu surprenant. C’est le cas des icônes sous forme de fontes. Plutôt que d’utiliser des images, on peut utiliser des polices typographiques qui contiennent des images vectorielles plutôt que des lettres. Ça permet d’avoir des icônes qui vont bien supporter l’agrandissement et la réduction. Au delà du fait que je trouve ça techniquement idiot (SVG est bien plus adapté à ce cas d’usage), cela pose de sérieux problèmes d’accessibilité. En effet, un caractère, même s’il ne ressemble pas à une lettre sera compris comme tel par les navigateurs (et donc lu comme tel par les revus d’écran !).

C’est là que :before et :after peuvent aider à l’accessibilité ! En positionnant vos icônes dans des pseudo-éléments, les aides à l’accessibilité n’y auront plus accès et ces icônes pourront donc être plus efficacement utilisées pour ce qu’elles sont : des artifices de décoration.

> Voir l’exemple des icônes typographique

La tentation du remplacement de texte

Ce cas d’usage est hyper limite, mais il faut que vous le connaissiez pour pouvoir lutter contre les abus et les dérives qui peuvent en découler.

Imaginez le cas suivant :

<div>
   <span>Ici, mon texte d'origine</span>
</div>

Avec le code CSS suivant :

span{
   position : absolute;
   width : 0;
   height : 0;
   overflow : hidden;
}

div:before{
   content : "mon nouveau texte";
}

Le texte d’origine n’est plus visible mais continue de vivre dans le DOM par contre, le texte du pseudo-éléments est visible mais littéralement inaccessible (il n’existe pas dans le DOM et il n’est pas sélectionnable).

Réaliser un tel remplacement de texte est dangereux car c’est la porte ouverte au SPAM ou pire au hijacking. Mais il peut y avoir quelques cas légitimes (bien que très certainement discutables), comme par exemple la création de liens “lire la suite” qui disposent de libellés plus complets et accessibles dans le DOM. Dans tout les cas, faites bien attention à ce que vous faites et pensez toujours à vos utilisateurs (tous vos utilisateurs).

Régler les problèmes de flottaison

Un des problèmes récurant lorsqu’on utilise la propriété float, c’est que l’élément qui flotte, s’il est plus grand que son conteneur, peut en “sortir”. Pour éviter cet effet parfois disgracieux, nous sommes nombreux à avoir appris à agrémenter notre code HTML de <span style="clear:both"></span> et autre joyeuseté du même genre. Pour éviter de polluer nos sources HTML et nos arbres DOM, il y a peu de solution. En fait, il y en deux avec CSS.

La première consiste à utiliser la propriété overflow avec la valeur hidden. C’est une technique très efficace, mais qui a un gros défaut : absolument rien ne peut sortir de l’élément, ce sera forcément tronqué. Cela peut donc être une contrainte forte, en particulier si vous utilisez des positionnements relatifs ou des marges négatives pour décaler des éléments vers l’extérieur.
La deuxième consiste à utiliser un pseudo-élément :after et tout simplement de lui appliquer la propriété clear. Et là, c’est le bonheur, vous avez tous les avantages de la balise span sans avoir empoisonné votre source HTML et vous évitez tous les problèmes liés à l’usage de la propriété overflow.

> Voir les différentes gestion de float

Le cas Internet Explorer

Tous les exemples précédent sont relativement simple et fonctionnent dans tous les navigateur de dernière génération mais malgré cela il y a toujours un petit problème : Internet Explorer et plus particulièrement ses versions 6 et 7 (mais achevez les, vous voyez bien qu’ils souffrent !)

Mais d’abord, un petit mot sur Internet Explorer 8 qui est un excellent navigateur en terme de support de CSS2 et qui est donc capable de faire tout ce qui a été dis ci-avant. Enfin… presque. Il existe un petit bug dans l’implémentation des pseudo-éléments qui rend impossible la possibilité d’afficher un pseudo-élément au dessus du contenu de l’élément de référence. Cela peut parfois être un peu gênant lorsque vous positionnez les pseudo-éléments de manière absolue, mais rien d’insurmontable graphiquement parlant, il faut juste le savoir.

Par contre, IE6 et 7 ne supportent pas du tout les pseudo-éléments. Alors que faire ?

Hélas, il n’y a pas 36 solutions, et, à moins que vous ne soyez très à l’aise avec les questions de dégradation harmonieuse, vous allez devoir vous tourner vers Javascript. En effet, la meilleur façon de simuler les pseudo-éléments avec ces navigateurs consiste à inclure de vrai élément dans l’arborescence du DOM et à leur appliquer les même style qu’a vos pseudo-éléments.

Si vous utilisez jQuery, ça peut donner ça :

$('div.alert')
.prepend('<span class="before"></span>')
.append('<span class="after"></span>');

Cette solution marche plutôt bien mais souffre de quelques inconvénient qu’il faut connaitre :

IE6 et 7 ne connaissent pas non-plus la propriété content, il vous faudra donc aussi générer votre contenu via Javascript.
Les éléments étant véritablement dans le DOM, ils seront visibles par les différentes aides à l’accessibilité ce qui peut avoir des conséquences déplaisantes pour l’utilisateur.
Les déclarations de style pour les classes .before et .after devront être dupliquées. En effet, IE6 et 7 ignoreront tous les blocs de styles avec au moins une déclaration de sélecteur contenant :before et :after, même si les différents sélecteurs sont séparés par une virgule.

Conclusion

Voila pour ce tour d’horizon des pseudo-éléments. Comme vous avez pu vous en rendre compte, ce sont des outils très puissant qui offrent un potentiel créatif énorme (mais qui requièrent aussi une certaine dose de responsabilité pour ne pas faire n’importe quoi).

Bien comprendre les possibilités de CSS2 à son plein potentiel est une étape importante pour aller vers CSS3. En effet, le module dédié à la génération de contenu en CSS3 fait littéralement exploser les limites du possible en la matière avec des fonctionnalités démentes comme le fait de pouvoir créer des pseudo-éléments dans des pseudo-élément et de pouvoir même carrément recréer un arbre DOM fantôme. Bon, pas de panique, d’ici à ce que les fabricants de navigateurs se soient mis d’accord sur la norme et commence à l’implémenter, il va couler de l’eau sous les ponts (d’autant que c’est un module non-prioritaire au W3C). Mais si déjà vous maitrisez ce qu’offre CSS2, vous vous ouvrer de grandes portes… amusez-vous bien

Notes :

En fait ce n’est pas une exception, mais la gestion des échappements de caractères avec CSS n’est pas forcément très simple, donc, je vous encourage à vous familiariser avec la notation \00XXXX et à considérer \A comme une exception.

Faire peau neuve

Jeremie — Wed, 15 Sep 2010 20:31:00 +0200

Depuis maintenant 2 ans que je tiens ce blog, il était grand temps de faire peau neuve. Je profite donc du CSS Summer refresh organisé par Alsacreations pour dire au revoir au gabarit par défaut de Dotclear et mettre en place un vraie gabarit utilisant HTML5 et CSS3.

Partis pris graphiques

L'idée maitresse de ce design consiste à mettre l'accent sur la lisibilité. Ce site étant un blog, tout tourne autour des articles qui y sont écris, tout le reste n'est qu'accessoire. L'entête et le pied de page sont donc réduit au minimum, la zone de lecture principal prend l'essentielle de la surface visible, et la colonne de gauche ne sert quasiment que d'aide à la navigation sauf sur la page d'accueil ou je m'étale un peu.

L'idée secondaire de ce design consiste à simplifier au maximum la navigation. Pour cela, étant donné la place que prend le contenu principal, j'ai choisi de rendre l'en-tête et le pied de page fixe. La colonne de gauche est partiellement fixe. En fait, cela dépend de son contenu, si elle est trop grande, elle se déplacera avec le contenu de la page, si elle est assez petite, elle restera fixe.

Couleurs

Les dominantes de couleur sont le noir est blanc, là encore pour rendre la lecture plus confortable. Néanmoins, je nuance le site à l'aide de rouge et de vert, des couleurs très naturelles, alliance de chaleur et de fraicheur. Le rouge est utilisé pour toutes les zones d'action (essentiellement les liens). Il est assombris ou affadis selon les cas afin de ne pas trop interférer avec le contenu et donc la lisibilité. Le vert est utilisé pour les zones de repos (Affichage de code source), et les actions à retardement (bouton de validation des formulaires)

Typographie

Afin de gagner en expressivité, j'utilise deux polices typographiques : Georgia pour la titraille des articles et Molengo pour tout le reste. Molengo est une police de caractère sans empattement, ronde et équilibré. Même si elle souffre de quelques défaut de hinting (regardez la largeur des futs des i et f par rapport à celle des m et n), elle supporte remarquablement bien la réduction et est très adaptée aux usages web. Elle permet de donner de la douceur au texte et de rendre la lecture plus fluide. C'est important dans la mesure ou j'ai tendance à écrire des articles long. Ce choix typographique me permet de limiter la fatigue visuel et de mieux "faire passer la pilule". Dans le même ordre d'idée, au rayon des subtilités, vous n'aurez peut être pas remarqué, mais les bandeaux noir en en-tête et pied de page sont en fait gris très foncé. Cela permet de rééquilibrer le contraste avec le gris typographique naturel et d'éviter qu'ils n'écrasent (trop) le texte.

Partis pris techniques

L'idée sous-jacente de ce re-design, c'est bien sur d'exploiter au mieux les capacités des navigateurs en terme de support de CSS2/3 et de HTML5. Pour HTML5, cela se résume à l'utilisation de certaines nouvelles balises (section, article, aside, header, footer). Pour ce qui est de CSS, J'essaye au maximum d'utiliser les capacité de CSS2 (max-width, position : fixed, sélecteur d'attribut) et un peu de CSS3 pour rajouter quelques effets, ce qui me permet d'obtenir un design fluide qui s'adapte assez bien à tous les types de navigateurs et d'écrans.

media queries

L'utilisation du module "Media Queries" de CSS3 me permet de contrôler la façon dont mon design va se dégrader selon les capacités du terminal qui affiche ma page. Ainsi, les écrans haute résolution afficherons les polices typographiques dans un corps de texte plus important afin que le texte reste toujours aussi confortable à lire. D'un autre coté, pour les écrans de très petite dimension (smartphone et écran à faible résolution), le design est simplifié et linéarisé... encore et toujours pour améliorer la lisibilité.

Couleurs transparente

Une des nouveauté de CSS3 les plus facile à utiliser, ce sont les couleurs transparentes. Elles permettent de créer des effets assez subtile de superposition sans avoir à multiplier les images. Ainsi, mes images d'arrière plan sont toujours visibles mais affadies lorsque du texte est affiché par dessus. Pour cela, il suffit d'avoir un blanc ou un gris légèrement transparent en arrière plan des textes qui viendront se superposer aux images.

transitions

Les transitions me permettent ici de rajouter un peu de douceur au design en créant des transitions de couleur un peu moins abrupte que ce que permet CSS seul d'ordinaire.

Arrière-plans multiples

La possibilité de définir des valeurs multiples pour les propriétés CSS est sans doute une des plus remarquable avancée de CSS3. Je l'utilise ici pour définir des images multiples d'arrière-plan. Cela permet dans le cadre d'un design fluide de pouvoir placer mes deux fleurs à chaque extrémité de l'écran, sans avoir à me soucier de la taille de l'écran et sans avoir à recourir à un sur-balisage HTML inutile.

Enrichissement progressif et dégradation harmonieuse

Globalement, ce design se dégrade très bien dans un navigateur qui supporte correctement CSS2 (et donc, il se dégrade très bien dans IE8, qui ne bénéficie tout simplement pas des amélioration de CSS3)

Les seuls vrais problèmes interviennent avec le cauchemar du web designer : IE6 et 7. Pour ces deux navigateurs, j'ai rajouté quelques styles spécifiques pour s'assurer que la dégradation n'est pas trop déconnante.

Pour vous faire une idée, le navigateur de référence lorsque j'ai créer ce design fut Firefox 3.6. Tous les navigateurs plus récent bénéficieront de tout ou partie des avancés des CSS3 pour avoir un design un peu plus léché et/ou subtile. A l'inverse, la dégradation se fait très bien dans IE8 (le design est un peu plus grossier mais conforme à la logique global) et IE6 et 7 sont clairement moins jolis mais toujours aussi utilisable et les prérequis du design (lisibilité et navigation simplifié) sont respectés.

Améliorez vos liens avec la génération de contenu CSS

Jeremie — Wed, 23 Jun 2010 14:19:00 +0200

Les liens hypertextes sont la colonne vertébrale du Web. La plus part du temps, ils se résument à un texte graphiquement mis en évidence (historiquement, bleu et souligné). Néanmoins, techniquement et sémantiquement parlant, les liens peuvent bénéficier de méta-données qui offrent un certain nombre d'informations qui pourraient être utile à l'utilisateur mais ne sont pas mises en évidence par les navigateurs. Par exemple, l'attribut target permet de définir dans quel fenêtre ou cadre va s'ouvrir le lien, ou l'attribut hreflang qui permet de connaitre la langue de la page où mène le lien et je ne vous parle même pas de l'attribut rel. Dans cet article je vais vous montrer comment utiliser la génération de contenu CSS pour afficher certaines de ces informations à l'utilisateur.

Le résultat attendu

L'idée est d'afficher au survol d'un lien le contenu de son attribut hreflang et target dans un badge en surimpression. Une image valant mieux qu'un long discourt, voila le résultat attendu :

L'arrière plan des liens

Afin de facilité la lecture du badge et surtout son association visuelle avec le lien, on va attribuer aux liens un arrière plan coloré qui va légèrement déborder de la zone de lecture "normal".

On commence par leurs donner une couleur d'arrière plan au survol :

a:hover{
    background : #CCD;
}

L'effet de débord est réalisé en jouant sur les propriétés padding et margin. L'utilisation de padding va permettre d'élargir la zone visuelle. Malheureusement, cela agrandi aussi réellement la zone occupée par le lien qui va repousser ce qui l'entoure. Pour éviter cet effet, on va attribuer une valeur négative de margin équivalente à chacune des valeurs de padding. Cet artifice permet de donner assez facilement l'illusion d'un élément qui "déborde" tout en étant à sa place naturel dans le flux HTML.

a{
    display : inline-block;

    padding :  0.1em  0.6em;
    margin  : -0.1em -0.6em;
}

Notez que la balise a est une balise de type inline. Cela veux dire que certains navigateurs ne vont pas appliquer (ou seulement partiellement) le padding et le margin à l'élément. Pour corriger cela, vous devez ajouter la propriété display: inline-block. Si vos intitulés de liens sont longs, il faut se poser la question de savoir si on veut réellement réaliser un tel effet graphique. En effet, en cas de retour à la ligne avec une balise inline-block, c'est l'intégralité du contenu de la balise qui passe à la ligne (ce qui peut casser la continuité et la lisibilité de votre texte) et si le contenu continue d'être trop grand pour tenir sur une seule ligne, le retour à la ligne se fera à l'intérieur de la balise inline-block. C'est donc à vous de voir ce que vous voulez faire selon le contexte sachant que l'utilisation de la valeur inline-block est obligatoire avec Internet Explorer 8 lorsque vous voulez créer un contenu généré, positionné de manière absolue (ce qu'on va faire ci-après). Si vous n'utilisez pas cette valeur, le badge s'affichera sous le lien !

Avec le truc du débord que je viens de vous montrer, vous allez constater un effet assez déplaisant. Au survol de votre lien le texte qui précède le lien sera masqué par l'arrière plan alors que le texte qui suit restera visible par dessus l'arrière plan. Vous pouvez régler l'empilement des éléments en jouant avec la propriété z-index. Vous pouvez soit lui donner la valeur -1, mais dans ce cas, les liens vont se retrouver sous les paragraphes et ils ne seront jamais survolés par la souris (vous les voyez, mais en fait ils sont "masqués" par l'élément contenant le texte), soit vous lui donnez la valeur 1 et dans ce cas le lien passera entièrement au dessus du texte qui l'entoure. C'est assez intéressant graphiquement, mais pas forcément très satisfaisant en terme de lisibilité je vous montrerai un peu plus loin comment s'en sortir avec CSS 3.

a{
    position : relative; /* nécessaire pour la bonne application de z-index */
    z-index  : 1;
}

La génération de contenu

Le badge qui contiendra les informations supplémentaires va être créer à la volé au survol d'un lien directement en utilisant CSS. Pour cela, nous allons utiliser le pseudo-élément :after en conjonction avec la propriété content.

Le pseudo élément :after va simuler la présence d'un éléments après le contenu du lien. On appel cela un pseudo élément car ce sélecteur va créer une zone qui va avoir le même comportement qu'un élément HTML traditionnel, exactement comme si vous agissiez sur une balise span. La seul différence, c'est que ce pseudo-élément n'apparait pas dans l'arbre DOM du document. Je vous reparlerai un peu plus loin de ce sujet quand on abordera les questions d'accessibilité. Ce qu'il faut retenir ici c'est que vous allez pouvoir ajouter des styles à un élément sans que vous ayez besoin de rajouter quoi que ce soit dans le balisage HTML de vos liens.

La propriété content, elle, va permettre de rajouter du texte et des images au sein de votre pseudo-éléments. Là encore, rien n'apparait dans l'arbre DOM de votre document HTML.

Nous allons gérer ici quatre cas de figure pour notre badge :

Si l'attribut hreflang est présent, on affichera sont contenu dans notre badge : l'objectif est de dire visuellement à l'internaute quelle est la langue du lien qu'il va ouvrir.
Si l'attribut target est présent et à la valeur _blank, on affichera une icône qui montre l'ouverture d'une nouvelle fenêtre dans notre badge.
Si les deux attributs sont présents, on affichera et la langue et l'icône.
Si aucun des deux attributs n'est présents, on n'affichera pas le badge du tout.

La gestion de ces quatre cas va passer par une utilisation judicieuse du sélecteur d'attribut et de la cascade

a:after{
 /* On masque le badge, mais on utilisera le sélecteur générique pour définir le style global du badge */

    display : none;
}

a[hreflang]:hover:after{
 /* On affiche le contenu de l'attribut hreflang */

    content : attr(hreflang);
    display : block;
}

a[target="_blank"]:hover:after{
 /* Si l'attribut hreflang est définie, on affichera son contenu. S'il n'existe pas, il ne s'affichera pas. Dans tous les cas, on affichera une icône qui matérialise le changement de fenêtre */

    content : attr(hreflang) " " url("external.png");
    display : block;
}

Assez simplement, la fonction attr permet d'extraire le contenu de l'attribut et la fonction url permet d'inclure une image. Notez que dans la déclaration ci-avant, dans le cas ou les deux attributs hreflang et target sont tous les deux définis, c'est la dernière règle CSS qui sera appliquée car elle a, selon les règles de la cascade, le même poids que la règle précédente, mais elle la surcharge du fait de son positionnement dans le code source.

Le positionnement et le design du badge

Maintenant que le contenu du badge est générer il faut lui donner un peu de style (oui, je sais, elle un peu facile celle là :-p )

On va commencer par le sortir du flux en le positionnant de manière absolu et on le fera légèrement déborder en haut et à droite. En suite, on va détailler le minimum syndical graphique : Couleur d'arrière plan, bordures, styles typographiques, marges pour aérer un peu tout ça.

a{
 /* nécessaire pour que le positionnement du badge soit relatif à son lien*/

    position : relative;
}

a:after{
    position : absolute;
    top   : -1.3em;
    right : -1.3em;

 /* L'arrière plan est rouge foncé et le texte blanc */
    background : #009;
    color : #FFF;

 /* On ajoute une bordure blanche de 2 pixels de larges */
    border : 2px solid #FFF;

 /* Le texte est graissé et 1/3 plus petit que le texte du lien. Il est également mis systématiquement en majuscule */
    font : bold 0.6em Verdana, Helvetica, Arial, sans-serif;

    text-transform : uppercase;

 /* L'ajout de marge permet de laisser le texte respirer */
    padding : 0.4em 0.5em;
}

CSS 3 is sexy !

Voila ! Avec ce que vous venez de voir, vous avez fait tous ce qu'il est possible de faire simplement avec CSS 2. Cependant, on n'est pas encore au résultat attendu. On va donc rajouter une petite touche de CSS 3 pour rendre ça plus fin, plus youpi-tralala, plus waow !

Couleur transparentes

Actuellement, l'arrière plan de nos liens est opaque au survol, ce qui fait qu'on masque une partie du texte à cause de l'effet de "débord" de l'arrière plan. En utilisant une couleur semi-transparente on peut atténuer ce problème. pour cela, il suffit d'utiliser la notation rgba définie dans le module "Border & Background" de CSS 3.

a:hover{
    background : #CCD;
    background : rgba(128, 128, 160, .4);
}

Notez dans l'exemple ci-avant que la propriété background est déclarée deux fois. C'est normal. En effet, de cette manière si un navigateur ne comprend pas la notation rgba (IE8 par exemple), il ignorera la déclaration inconnu et se rabattra sur la déclaration précédente qui respecte la norme CSS 2. Le mécanisme qui consiste à ignorer une déclaration de style inconnue ou mal formée est un comportement standard. C'est une façon simple de gérer les capacités des navigateurs sans avoir à recourir à des artifices comme Modernizr.

Une autre solution pour régler ce problème de sur-impression consisterai à appliquer un z-index négatif au lien et à utiliser la propriété css pointer-events définie par SVG. Néanmoins, cette solution est plus lourde à mettre en œuvre (il faut appliquer au conteneur de chaque lien la valeur none et réapliquer la valeur auto à tous les liens). A noter que seul Firefox, Chrome et Safari supportent la propriété pointer-events sur les éléments HTML (je n'ai pas eu l'occasion de tester avec IE9, mais IE8 et Opera 10.53 ne la supportent pas).

Bords arrondis

Pour adoucir un peu l'effet on va rajouter des bords arrondis aux liens et aux badges

a:hover{
    -moz-border-radius : 1.3em;
 -webkit-border-radius : 1.3em;
         border-radius : 1.3em;
}

a:after{
    -moz-border-radius : 50%;
 -webkit-border-radius : 1.3em;
         border-radius : 1.3em;
}

Comme souvent avec les propriété issu de CSS3, vous aller devoir faire plusieurs déclarations. En effet, peu de modules ont atteint le statut de Candidate Recommendation au W3C, or, c'est seulement à partir de ce statut que les constructeurs peuvent retirer leur préfixe spécifique aux propriétés qu'ils ont implémenté. le module Border & Background a atteint ce statut et tous les constructeurs sont d'accord pour dire qu'en ce qui concerne la propriété border-radius, il est plus que temps de retirer ce préfixe. Opera 10.53 supporte déjà cette propriété sans préfixe et les futures IE9 et Firefox 4 (en cour de discussion) devraient aussi la supporter sans préfixe.

Notez que pour le badge, avec Firefox, j'ai utilisé la valeur 50%. Cette valeur permet de créer des demi-cercles parfaits aux extrémités gauche et droite. Néanmoins, c'est un comportement spécifique à Firefox et mes tests ont montrés que certaines implémentations de Webkit (Chrome 5 par exemple) ainsi qu'Opera ne supporte par les pourcentages avec cette propriété. En outre, de ce que je comprend de la spécification, cette déclaration devrait produire une boite ovale plutôt que deux demi cercle réparti de part et d'autre de la boite, donc, pour la propriété standard, j'ai préféré mettre également une valeur absolue.

Ombres et lumières

Notre badge commence à être pas mal, on va le finaliser en lui donnant un peu de relief avec des effets d'ombres et de lumières.

a:after{
    background : #900;
    background : -moz-radial-gradient(35% 35% 0deg, ellipse cover, #E00 0%, #800, 90%);
    background :      radial-gradient(35% 35% 0deg, ellipse cover, #E00 0%, #800, 90%);

 -webkit-box-shadow : rgba(0, 0, 0, .8) 0 2px 5px;

    -moz-box-shadow : rgba(0, 0, 0, .8) 0 2px 5px,
                      rgba(255, 247, 0, .9) 0 0 3px inset;

         box-shadow : rgba(0, 0, 0, .8) 0 2px 5px,
                      rgba(255, 247, 0, .9) 0 0 3px inset;

}

On commence par ajouter un dégradé radial en arrière plan pour donner l'illusion d'un éclairage venant du haut et de la gauche (positionnement du centre du dégradé à 35% du haut de la boite et à 35% du bord gauche de la boite). Ce dégradé aura la forme d'une ellipse horizontal (0 degrés de rotation) qui couvrira toute la boite. Le dégradé va d'un rouge vif au centre à un rouge sombre prés des bords). La syntaxe des dégradés sous Webkit est très différentes de celle de Gecko et honnêtement je n'y comprend rien donc, tant pis pour Safari et Chrome (faite vous plaisir dans les commentaires si vous avez la solution qui va bien). La syntaxe de Gecko étant celle qui est en cour de standardisation, je reproduit la déclaration sans le préfixe -moz-, mais c'est un parie sur l'avenir. En effet, les dégradés CSS font partie du module "Image Values" qui en est à son tout premier draft. Autant dire que ça peut (va ?) sérieusement bouger.

Ensuite on ajoute une ombre porté qui va permettre de "détacher" le badge de la surface de la page. Cette ombre est décalé de 2 pixels vers le bas et sont rayon de flou est de 5 pixels. Dans la mesure ou tout les navigateurs majeurs du marché qui supportent la propriété box-shadow supportent également les couleurs rgba, on ne va pas s'amuser à gérer une alternative sans couleur transparente (mais on pourrait :-p ).

Comme box-shadow supporte les déclarations multiples séparées par un virgule, on va en profiter pour rajouter une ombre intérieur (mot clé inset). C'est une ombre de couleur jaune pour créer un effet de lumière spéculaire (on aurait pu le faire via le dégradé radial, mais personnellement je trouve ça plus simple via box-shadow). Vous noterez que je n'ai pas appliqué cette deuxième ombre à Webkit. Cela tiens au fait que l'implémentation des ombres internes couplé à l'utilisation de border-radius est une catastrophe sous Chrome 5 et Safari 4 (je n'ai pas eu l'occasion de tester avec Safari 5). En effet, l'ombre reste carré la où la boite est arrondie... horrible !

Attention à l'accessibilité

Voilà, on a créer un jolie badge qui illumine la vie de notre internaute. Mais le loup se cache au coin du bois !

Au royaume des aveugles les borgnes sont rois.

Comme je vous le disait ci-avant, le problème majeur de la génération de contenu via CSS, c'est que ce contenu n'est pas inclus dans le DOM du document HTML. Ainsi, toute les outils d'aide à l'accessibilité qui repose sur le DOM ne pourront pas exploiter ce contenu généré. C'est par exemple le cas des revus d'écran qui vocalisent les pages Web. A ma connaissance, aucune ne prend en charge les contenus généré via CSS. Pour cette raison, il est vivement déconseillé de générer un contenu signifiant à l'aide de CSS. Dans le cas qui nous occupe ici, cette question n'est pas un problème. En effet, il s'agit uniquement d'enrichir l'expérience utilisateur, donc, tant pis pour les aveugles et les personnes utilisant de vieux navigateur (vous voyez de quoi je parle là, n'est-ce pas), ils pourront toujours utiliser les liens tel qu'ils ont l'habitude de les pratiquer, pour les autres, c'est cadeau, c'est bonheur

Les souris, ce fléau de l'humanité !

Vous aurez noté que l'apparition et la disparition du badge sont conditionnées par l'application de la pseudo-classe :hover. Cette pseudo-classe correspond au survol de la souris sur le lien. Pas de bol, certains excentriques utilisent leur clavier, d'autres utilisent des interfaces tactiles (et même si Safari sous iPhone sait s'accommoder de cette pseudo-classe, ce n'est pas le cas de tous le monde) ... pire, votre souris pourrait tomber en panne ! Vous pourriez avoir la même attitude que précédemment et décréter que "tant pis pour ces êtres étranges qui sont mal équipé" et en rester là. C'est toujours possible mais ce serait dommage car il est assez facile de leur offrir la même expérience en étendant légèrement nos sélecteurs CSS en incluant les pseudo-classes :active et :focus.

a[hreflang]:hover:after,
a[hreflang]:active:after,
a[hreflang]:focus:after{
    ...
}

a[target="_blank"]:hover:after,
a[target="_blank"]:active:after,
a[target="_blank"]:focus:after{
    ...
}

Mon royaume pour un cheval.

Certains navigateurs sont comparables à des piétons et d'autres à des calèches grand luxe tractées par au moins 4 chevaux (ce qui sous entend également que même les navigateurs actuels les plus en pointe ont encore un long chemin à parcourir pour pouvoir être comparé à des coupés sport à injection directe !). Vous pouvez bien sur tester ce badge avec votre propre navigateur, et si vous n'avez pas tout un panel de navigateurs à votre disposition, voila quelques exemples de rendus :

Tableau comparatif de quelques rendus navigateurs
Navigateur	OS	Résultat du rendu
IE 6	Windows XP
IE 7	Windows XP
IE 8	Windows XP
IE 9 (Test Drive)	Windows 7
Firefox 3.5	Mac OS Leopard
Firefox 3.6	Windows XP
Firefox 3.7a5	Ubuntu 10.04
Chrome 5	Windows XP
Safari 4	Windows XP
Safari 5	Mac OSX Leopard
Opera 10.53	Windows XP
Opera 10.60 beta	Ubuntu 10.04

Vous noterez que, au delà des dégradations prévisibles (Dégradés, ombre, coins arrondis), c'est le rendu typographique qui diffère le plus d'un OS à l'autre (d'où l'importance d'utiliser des em pour définir la taille des arrondis plutôt que des pixels). Vous noterez également un bug (?) avec IE8 (non, ne levez pas les yeux au ciel !), où le badge est positionné au dessus de l'arrière plan du lien, mais au dessous du texte (!!). Il semblerai que pour l'instant, l'équipe de IE9 ne se soit pas encore penchée sur la gestion des pseudo éléments qui se comportent exactement comme avec IE8.

Conclusion

Comme vous pouvez le voir, il n'est pas très difficile d'enrichir l'expérience des utilisateurs. On est dans un cas typique d'enrichissement progressif. Avec un navigateur ancien, l'utilisateur ne gagne rien, mais il ne perd rien non plus. Avec un navigateur moderne, il gagne en confort. Personne n'est lésé, tout le monde est gagnant.

Certes, cela est intéressant pour l'utilisateur, mais cela peut également être intéressant pour vous à titre personnel. En effet, rien ne vous empêche d'utiliser cette technique dans la feuille de style utilisateur de votre navigateur préféré pour enrichir votre propre expérience de navigation sur tous les sites sur lesquels vous surfez

Enfin, c'est grâce à ce genre de test qu'on peut remarquer que Webkit n'est pas aussi bon que l'affirme Apple et Google en terme de support de CSS3 (quand il ne font pas un honteux amalgame avec HTML5). Je ne parle pas des dégradés radiaux (là, c'est moi qui fait volontairement l'impasse) mais plutôt du support de box-shadow couplé à border-radius qui est loin de ce que propose les dernières versions de Gecko. Bon soyons claire, il ne sert à rien de se lancer dans un pinaillage du genre "Ah oui mais Webkit supporte mieux tel truc que Gecko". Ce que je veux vous dire, c'est qu'il ne faut pas prendre pour argent comptant ce que racontent les constructeurs de navigateurs. Testez, testez et testez encore ! Il n'y a que ça pour vous permettre de savoir ce qui marche dans les cas qui vous intéressent.

@media London 2010 : Day 1

Jeremie — Tue, 08 Jun 2010 22:17:00 +0200

Cette année j'ai pu me rendre à @media (c'est comme Paris Web, mais à Londres et en plus chère ). Ce cycle de conférences comprend 2 jours d'ateliers (1 atelier = 1 journée... autant dire qu'on rentre sérieusement dans le détail) et 2 jours de conférences. Choisir entre les différents ateliers fut une vraie torture, mais finalement, pour le premier jours, j'ai opté pour l'atelier de Andy Clark sur le thème « Advanced CSS styling ».

Les ateliers se tiennent au Goodenough College. Le lieu est superbe et « so british »... une quasi collection de clichés sur ce qu'est une école d'enseignement supérieur anglaise (quelques photo sur Flickr). Un écrin parfait pour un atelier de haut niveau.

En guise d'introduction, Andy commence par nous présenter le processus de standardisation et le jeu permanent qu'il existe entre le W3C et les fabricants de navigateurs. Il en profite pour démystifier le sujet en insistant sur un point clé : la normalisation est faite pour les constructeurs par les constructeurs. Le point de vue des designer est très peu représenté (il n'y a que 2 experts invités dans le groupe de travail CSS) et chaque constructeur suie ses propres contraintes liées à son business model. Pour conclure ce premier round d'échauffement, on a eu droit a un excellent mini débat sur le thème « Un site doit-il être exactement semblable d'un navigateur à l'autre ? »... Je parle d'échauffement car la réponse est évidente et les objections toujours les mêmes. Andy en profite ici pour mettre un coup de griffe aux graphistes qui persistent à présenter des maquettes de sites sous forme d'images figées et encourage tout le monde à présenter des maquettes HTML, même si ce ne sont que de simple « point d'étape » tout en démontrant les bénéfices à travailler dans une logique de dégradation harmonieuse. Il estime que les maquettes fixes sont un problème car elles ne permettent pas d'anticiper certaines contraintes propre au média (par exemple, que ce passe-t-il quand un titre prévus sur une ligne est trop long et passe sur deux ligne ?) et le client étant incapable de faire cette gymnastique mental, il ne comprendra pas pourquoi le design peut évoluer d'un navigateur à l'autre.

Suite à cela, on entre dans le vif du sujet avec une présentation en règles des nouveautés qu'apporte CSS3 en termes de Webdesign. Les principaux points abordés sont :

La gestion de la couleur avec en particulier la syntaxe rgba ;
La gestion des arrières plans avec en particulier les images d'arrière plan multiples (et plus généralement l'utilisation de valeurs multiples sur un certains nombre de propriétés) et la possibilité de gérer finement le positionnement et la taille de ces images ;
Les bordures avec une revue de détail des bords arrondis ;
Les ombres sur le texte et sur les boites de contenu (qui permettent de faire bien plus que de simples ombres portées);
La gestion de la mise en page avec un focus sur le colonage ;
Les transformations 2D et 3D ;
Les transitions.

Toutes ces nouveautés ne sont bien sur pas disponibles avec IE (on en reparlera lorsque IE9 sera là) mais Andy à une position très claire sur la question : Il design pour le navigateur le plus avancé en termes de support de CSS3 (Safari ?) et ensuite il s'assure que la dégradation se fait correctement, quitte à prévoir un design alternatif pour certains navigateurs quand la dégradation est trop importante. Ce qui est important, ce n'est pas le design, mais l'expérience utilisateur. C'est cette expérience qui doit être préservée, pas le design. Et pour Andy, qui est un excellent designer, le design n'est clairement pas l'alpha et l'oméga de l'expérience utilisateur. En particulier, il insiste sur le fait qu'un site peut être vue sur différents navigateurs dans des situations très différentes (un macbook, un iPad et un iPhone n'offrent pas les même conditions d'utilisation... oui, c'est un fan d'Apple ).

Après nous avoir bien alléché avec toute ses possibilités, se pose la question de les mettre en œuvre. Comme on a pris un peu de retard sur le programme, il se contentera d'évoquer quelques scripts permettant de contourner quelques limitation clé de certains navigateurs (par exemple ie-css3.js de Keith Clark) et surtout « Modernizr ». A titre personnel, je suis assez réticent à utiliser ce petit bout de Javascript mais Andy le vend très bien. Ceci-dit, il l'intègre dans une logique de travail incluant un savoir-faire de haut niveau qui en fait un vrai plus à utiliser et de fait, je reste persuadé que c'est un outil qu'il ne faut pas mettre dans les mains d'un débutant. En effet, Andy maitrise à la perfection les questions de dégradation harmonieuse et d'enrichissement progressif, en conséquence il sait parfaitement quand utiliser un facilitateur comme « Modernizr » et quand ne pas l'utiliser, ce qui n'est pas nécessairement le cas du webdesigner moyen (en admettant que la notion de webdesigner moyen ait un sens)

En guise de dessert, nous terminons l'après-midi avec la gestion des polices typographiques \o/. La quasi totalité des navigateurs actuels supporte la gestion des polices typographiques. Néanmoins, chacun utilise des formats différents (eot, ttf, woff...). On commence donc par débroussailler ce sujet en ayant droit à une petite visite des utilitaires du site fontsquirrel.com. Néanmoins, actuellement la question des droits d'utilisation des polices sur le web est un problème délicat. Andy nous présente alors typekit.com en détail (Disclaimer : typekit sponsorise Andy Clark pour son intervention, mais ça n'enlève rien à la qualité de l'outil). Ce site propose un système qui permet de résoudre efficacement la question des droits d'utilisation et un ensemble d'outil permettant de se customiser ses polices aux petits oignons. Enfin, on fait un petit coucou aux Google Font API qui présente une alternative gratuite à typekit mais dont le catalogue est encore assez pauvre. Objectivement, il n'y a aujourd'hui aucun frein technique à l'utilisation des polices typographiques embarquées dans les page HTML (sauf pour des questions de performances, mais c'est un autre débat).

Voila pour cette première journée. Ce fut un plaisir de rencontrer Andy. C'est un webdesigner extrêmement talentueux à la fois enthousiaste et réaliste. Son prochain livre sort en Septembre, autant dire que je l'attend impatiemment :D

La propriété CSS display: inline-block

Jeremie — Thu, 28 Jan 2010 14:00:00 +0100

La propriété CSS display reste sous-employée par les intégrateurs web. Ce n'est pas entièrement leur faute, les implémentations dans les navigateurs n'étant pas entièrement à la hauteur de la norme. Je reviens ici sur la valeur inline-block de cette propriété qui est désormais implémenté dans tous les navigateurs du marché et qui peut facilement nous aider à sortir de la sur-utilisation de la propriété float.

La propriété display permet d'indiquer explicitement le mode de rendu d'un élément HTML. Les valeurs les plus connues sont none, block et inline. Pourtant il y en a beaucoup d'autres et en particulier la valeur inline-block

`Block` et `inline`, les basiques

Chacune de ces valeurs va avoir une incidence sur la façon de rendre les éléments HTML ciblés. Malheureusement, les normes HTML 4.01 et CSS 2.1 sont assez floues sur ce que sont des éléments de type block ou inline et les futures normes HTML 5 et CSS 3 sont à peines plus loquaces sur le sujet. Pour mieux comprendre ce que sont ces types de rendu, je vous propose une caractérisation de ceux-ci selon mon expérience (c'est totalement empirique, et si vous pensez que j'ai omis des choses, n'hésitez pas à le signaler).

Les caractéristiques d'un élément de type `block` :

Les éléments de type block peuvent contenir à la fois d'autres éléments de type block, des éléments de type inline ou du texte¹.
Il est possible de fixer une largeur et une hauteur à ces éléments
Par défaut, la largeur d'un élément de type block est aussi grande que celle de son conteneur
Ils s'empilent naturellement les uns au-dessus des autres, dans l'ordre du flux HTML (Dans un flux de texte, ils passent à la ligne et forcent le retour à la ligne des éléments qui les suivent, les caractères invisibles présents avant et après sont ignorés)

Les caractéristiques d'un élément de type `inline` :

Les éléments de type inline ne peuvent contenir que d'autres éléments de type inline ou du texte
Il n'est pas possible de définir une largeur et une hauteur explicite pour ces éléments
Par défaut, leur largeur et leur hauteur dépendent du contenue de l'élément
Ils s'écoulent selon le flux du texte HTML

inline-block, un mélange des deux !

Avec cette valeur de la propriété display, vous allez avoir des éléments qui vont se comporter à la fois comme s'ils étaient de type block et de type inline. Concrètement, ça va donner les caractéristiques suivantes :

Les éléments de type inline-block peuvent contenir à la fois d'autres éléments de type block, des éléments de type inline ou du texte.
Il est possible de fixer une largeur est une hauteur à ces éléments
Par défaut, leurs largeurs et leurs hauteurs dépendent du contenu de l'élément
Ils s'écoulent selon le flux du texte HTML

Cela va avoir quelques conséquences :

La hauteur d'un élément de type inline-block va contrarier la hauteur des lignes de texte (même si vous l'avez fixée avec la propriété line-height) et donc potentiellement compromettre le rythme vertical de votre design.
Vous pouvez influer sur le positionnement de l'élément sur la ligne de base typographique en utilisant la propriété vertical-align.
Si une partie du contenu de l'élément doit passer à la ligne, c'est tout l'élément qui passera à la ligne

Implémentation de cette valeur dans les navigateurs

Le plus important à retenir, c'est que tous les navigateurs du marché implémentent la valeur inline-block pour la propriété display.

Attention tout de même à sont utilisation dans IE6 et IE7. En effet, l'implémentation de cette valeur est buggée sur ces deux navigateurs et ils ne supportent celle-ci que pour les éléments HTML qui sont nativement considérés de type inline par ces navigateurs. Cela à peu d'incidence pour peu qu'on y prenne garde. De toute façon, IE6 va bien finir par disparaitre et IE7 va rapidement être remplacé par IE8. D'ailleurs, IE8 est déjà le navigateur dominant de la gamme IE sur le marché des particuliers, il est donc plus que temps d'utiliser cette valeur de la propriété display.

Cas d'utilisations

Menu de navigation

L'usage de la propriété display:inline-block peut résoudre bon nombre des difficultés liées à l'usage de la propriété float. Néanmoins, il faut rester prudent.

Ce premier exemple reprend un balisage classique de menu sur une base de liste non-ordonnée. Cela fonctionne bien mais à deux conditions qui disqualifient presque l'usage de la valeur inline-block ici. Premièrement, dans la mesure où la balise LI est considérée nativement comme étant de type block, IE6 et IE7 ne géreront pas correctement l'usage de display. En outre, si vous voulez pouvoir contrôler l'espacement entre les onglets, vous devez accoler les balises LI dans le code HTML. En effet, les balises étant déclarées comme inline-block, elles vont suivre le flux de texte HTML ce qui veux dire que les espaces entre les balises sont affichés.

Ce deuxième exemple utilise un balisage plus simple (une succession de balises A) et utilise les spécificités qu'offre inline-block : centrage horizontal et vertical et utilisation des espaces typographiques. De fait, cette approche fonctionne parfaitement dans IE6 et IE7.

Nuage de tags

L'utilisation de inline-block sur un nuage de tags offre un monde de possibilités. Le fait de pouvoir donner explicitement une hauteur et une largeur ou de pouvoir spécifier des marges explicites aux éléments ouvre d'énormes portes aux graphistes. L'avantage le plus immédiat est d'éviter que des tags en plusieurs mots soient coupés par un retour à la ligne impromptu.

Titraille dépendante du contenu

Ce dernier exemple montre comment cette valeur permet de gagner en subtilité sur la gestion graphique des titres en permettant de créer simplement des effets liés à la taille du contenu plutôt qu'à la taille du contenant.

Aller plus loin

La propriété display a bien d'autres valeurs : certaines sont peu ou pas implémentées (la valeur compact), certaines sont partiellement implémentées et particulièrement difficiles à comprendre (la valeur run-in) et certaines sont largement implémentées mais peu ou pas utilisées (les valeurs table-* qui mériteraient un article à elles-seules... peut-être un jour si j'ai le temps ).

Pour en savoir plus sur le sujet, je vous renvoie vers ma bible du support des propriétés CSS : le site quirksmode.org et plus spécifiquement, sa section dédié à la propriété display.
Pour savoir comment contourner les limites des vieux navigateurs, je vous recommande l'excellent article de Florent Verschelde : Inline-block dans tous les navigateurs modernes ?
Pour une vue d'ensemble de la propriété display, il y a cette excellent tutoriel chez Alsacréations : Mise en page CSS avancée grace à la propriété display
En anglais : Robert Nyman, CSS display: inline-block: why it rocks, and why it sucks

Attention, il s'agit de la définition générale (selon la norme CSS) de ce qu'est un élément de type block. Cela ne remet pas en cause les spécificités propres à HTML comme par exemple la balise P qui selon la norme HTML 4.01/ XHTML 1.0 est bien de type block mais ne peut pas contenir d'autres éléments de type block.

Chez Jérémie - Mot-clé - CSS

Des kiwis sans pépins

Lier CSS à Javascript : une mauvaise idée

Performance

Maintenabilité

Et l’utilisateur dans tout ça ?

Des effets pour le Web

Le status quo actuel

SVG à la rescousse

Les filtres SVG sur du contenu HTML via CSS

Paris-Web 2010 : CSS3 Aujourd'hui

Arrétez de me casser les gonades avec border-radius

Le cas border-radius

box-shadow, ni fait, ni à faire

Conclusion

:before et :after, des pseudo-éléments qui ont du style

Des pseudo quoi ?

Emplacement et comportement

Génération de contenu

Du texte

Des images

Des compteurs

Des valeurs d’attribut

Grand Schelem, Belote et Quinte Flush Royal

Cas d’usage

puces et numérotation

Bords arrondis

Décoration de contenu

La création de guillemets graphiques autour des éléments blockquote

Réaliser des icônes sous forme de fontes

La tentation du remplacement de texte

Régler les problèmes de flottaison

Le cas Internet Explorer

Conclusion

Faire peau neuve

Partis pris graphiques

Couleurs

Typographie

Partis pris techniques

media queries

Couleurs transparente

transitions

Arrière-plans multiples

Enrichissement progressif et dégradation harmonieuse

Améliorez vos liens avec la génération de contenu CSS

Le résultat attendu

L'arrière plan des liens

La génération de contenu

Le positionnement et le design du badge

CSS 3 is sexy !

Couleur transparentes

Bords arrondis

Ombres et lumières

Attention à l'accessibilité

Au royaume des aveugles les borgnes sont rois.

Les souris, ce fléau de l'humanité !

Mon royaume pour un cheval.

Conclusion

@media London 2010 : Day 1

La propriété CSS display: inline-block

Block et inline, les basiques

Les caractéristiques d'un élément de type block :

Les caractéristiques d'un élément de type inline :

inline-block, un mélange des deux !

Implémentation de cette valeur dans les navigateurs

Cas d'utilisations

Menu de navigation

Nuage de tags

Titraille dépendante du contenu

Aller plus loin

`Block` et `inline`, les basiques

Les caractéristiques d'un élément de type `block` :

Les caractéristiques d'un élément de type `inline` :