Chez Jérémie

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.

Documenter le Web ouvert, pourquoi et comment

Jeremie — Mon, 02 Jan 2012 09:00:00 +0100

Cela fait quelques temps que je m’implique dans plusieurs projets visant à documenter ou à fournir du matériel pédagogique concernant les technologies du web dit ouvert (standards et technologies sous licences open-source). De mon point de vue, cet effort de documentation est nécessaire pour plusieurs raison que je vais vous détailler ici et j’espère bien convaincre quelques-uns d’entre vous de me suivre sur ce long chemin… un peu aride, il faut bien l’admettre :-P

Pourquoi ?

En temps que « vieux » du Web (je créer des sites à titre personnel depuis 1997 et à titre professionnel depuis 2000), j’ai appris le Web « à la dure » en lisant quelques livres de qualité inégale, en utilisant outrancièrement la fonction « afficher la source » de mes navigateurs et en fréquentant divers forums de discussion. J’ai fait beaucoup d’erreurs (et je continue à en faire) mais en rencontrant les bonnes personnes et en apprenant de ces erreurs j’ai réussie à progresser pour arriver ou j’en suis aujourd’hui. Certes, je ne regrette rien, mais franchement ce n’était pas simple tout les jours et s’il est possible de se simplifier la vie, autant ne pas s’en priver.

Au delà de mes considérations personnelles et de mes propre besoins et envies, il y a tout de même quelques points notables qui militent en faveur d’une documentation plus importante et plus « normé » des différentes technologies Web.

Place aux jeunes

Je vois actuellement arriver une nouvelle génération de développeurs et d’intégrateurs Web. A mon grand désarrois, peu d’entre eux sont vraiment doués. C’est quelque chose d’assez normal, tout le monde ne peut pas être un génie. Mais le problème ne se situe pas là. Le problème est souvent bien en amont au niveau de leur formation. Malheureusement, il existe encore peu de cycles d’études qui forment vraiment aux technologies et problématiques propres au Web (en France, on est encore trop dans la dichotomie : écoles d’informatique d’un coté qui ne font que survoler les technologies Web sans en voir les aspects fonctionnels ; écoles d’art et de design de l’autre coté qui survolent vaguement les aspects fonctionnels en faisant totalement l’impasse sur les aspects techniques). Ainsi, la qualité de la formation dispensée dépend donc encore trop souvent de la qualité des professeurs et formateurs. La difficulté, c’est qu’eux même ont du mal à trouver des sources d’informations leur permettant de rester à jour. L’effort de veille à faire pour qu’un formateur reste au niveau est énorme et parfois difficile si l’on cherche du matériel pédagogique dans une langue autre que l’anglais. Pire ! De trop nombreuses sources d’informations sont parfois médiocres pour ne pas dire complètement fausse et le plus souvent peu ou pas mises à jour (le cas W3School, par exemple, a donné lieu à de vives réactions).

Avec tout ça, on voit bien qu’il est finalement, aujourd’hui encore, assez difficile de se former correctement aux technologies et techniques de mise en œuvre des sites Web.

La complexification des technologies

Les standards du Web sont quelque chose qui évolue en permanence. Depuis plus de 20 ans, ces technologies gagnent en maturité, changent, s’enrichissent et s’affinent. Depuis environs 3 ans maintenant, les choses vont même en s’accélérant. HTML5 change profondément la nature du langage HTML, CSS3 enrichie considérablement le nombre de propriétés disponibles, ECMAScript vient de passer en version 5 et la 6 est en préparation, etc. Le retour d’un univers concurrentiel sur le marché des navigateurs, l’émergence du Web mobile, tout cela contribue à rendre les technologies toujours plus complexes et à rendre leur implémentation parfois très hétérogène d’un navigateur à l’autre.

Quelques chiffres bruts pour se rendre compte :

HTML4 : 91 balises et 119 attributs -> HTML5 : environ 107 balises et plus de 143 attributs
CSS2.1 : 115 propriété -> CSS3 : près de 250 propriétés (C’est une estimation car les travaux de spécification ont à peine commencé)
SVG 1.1 : 80 balises et 267 attributs
Plusieurs centaines d’interfaces DOM (je n’ai pas eu le courage de compter)

Et encore, là, il ne s’agit que du sommet de l’iceberg des différentes technologies Web. Et puis, quid des implémentations ? Quel navigateur supporte quoi ? Et avec quel degré de précision/bugs ? Ou et comment trouver des informations pertinentes et à jour sur toutes ces technologies, leur fonctionnement et leurs interactions ?

Et puis tant qu’on en est à complexifier les choses, allons jusqu’au bout. La fonctionnalité suprême des navigateurs, le fameux « afficher la sources » et en train d’en prendre un petit coup dans l’aile. En effet, les techniques d’optimisation des performances (pour ne citer qu’elles) ont un petit effets de bords, elles ont tendance à rendre les codes sources illisibles par les êtres humains. Mais même sans ça, examiner le code source d’une bibliothèque Javascript de 200Ko est très loin d’être une partie de plaisir. Aujourd’hui, n’espérez donc pas apprendre sérieusement Javascript simplement en lisant du code (ce que j’ai pourtant fait il y a plus de 10 ans).

Contrairement à une idée reçu, le Web ce n’est pas simple. Je ne sais pas pour vous, mais s’il existe des sources d’informations fiables me permettant de m’y retrouver, ce sera avec plaisir que je les accueillerai.

Comment ?

J’en arrive donc à un constat simple : ressources de qualité douteuse + complexification des technologies = il faut rentrer dans une logique de documentation un peu plus sérieuse que ce qui a été fait jusqu’à présent.

L’initiative individuel

Jusqu’à une date très récente, l’effort de documentation des technologies du Web ouvert passait par des initiatives individuelles. Chaque développeur web ayant son propre site ou blog sur lequel il note et documente ce qui l’intéresse ou lui manque (c’est typiquement ce que je fais sur ce site ). Les plus fameux à ma connaissance sont sans doute :

Position is everything qui documente tous les bugs de Internet Explorer 6 (et 7) en matière de CSS (je ne compte plus les fois ou ce site m’a sauvé la vie)
Quirks mode de Peter-Paul Koch qui détail la compatibilité des propriétés CSS d’un navigateur à l’autre (on notera en ce moment le boulot que fait PPK sur le support des navigateurs mobiles)
A list apart et ce que l’on peut considérer comme son équivalent Français : OpenWeb qui produisent des articles à la fois précis et accessible à tous.

Il en existe évidement bien d’autre et il est impossible de les citer tous. Ceci étant, pour intéressant qu’il soit, cet effort de documentation reste encore très dispersé, peu structuré et nécessite de prendre le temps de chercher ce dont on a besoin tout en requérant une bonne dose d’esprits critique pour trier le bon grain de l’ivraie.

W3C et consort.

Deuxième source historique de documentation : le W3C et autre organisme de standardisation. C’est bête à dire, mais lire les spécifications des technologies peut être une mine d’or si l’on cherche des informations techniques précises. Malheureusement, il faut bien se le dire, les spécifications ne sont pas écrite pour le commun des mortels… en tout cas pas pour les développeurs Web. En effet, les spécifications sont de la matière brute. Elles sont écrite avant tout pour les fabriquant de logiciel (navigateurs, éditeur de code, etc.) et surtout, elles ne permettent pas de savoir quelles sont les différences d’implémentation d’un logiciel à l’autre. Leur lecture est donc rarement suffisante (et parfois même inutile… par exemple, essayer de lire la spécification d’ECMAScript pour apprendre le Javascript, c’est un peu comme regarder la formule chimique du beurre pour apprendre à faire un gâteau).

Saluons tout de même l’initiative du HTML Working Group qui, dans le cadre de HTML5, produit deux documents à destination des développeurs Web :

http://www.w3.org/TR/html5-author/ Version expurgé des spécificités purement techniques liées à l’implémentation de HTML et qui se concentre sur ce qui est vraiment utile pour les créateurs de sites Web.
http://dev.w3.org/html5/markup/ La liste détaillé de toutes les balises HTML5

Les fabricants de navigateurs

Une autre source de documentation parfois méconnus mais très riche existe : la documentation officiel des fabricants de navigateur. C’est vraiment dommage qu’elles ne soient pas plus connus car on y trouve parfois des perles :

MSDN : http://msdn.microsoft.com/
Documentation officiel de Microsoft, vous y trouverez absolument tout concernant les technologies implémentées dans Internet Explorer (et tout les autres produits Microsoft). Son seul vraie problème est d’être extrêmement mal structuré quand on l’aborde de l’extérieur (comprendre, via un autre moyen que les pages d’aide des produits Microsoft). Pour la petite histoire, les technologies Web, c’est là : http://msdn.microsoft.com/en-us/library/aa155073.aspx
MDN : https://developer.mozilla.org/
Site de documentation de Mozilla. Originellement fait pour documenter les technologies propres à Firefox, il est actuellement en train d’évoluer pour proposer une documentation agnostique sur tous les standards Web. En particulier, on y trouve la documentation de référence pour Javascript. Sa principale caractéristique est d’être un wiki éditable par tout le monde, c’est donc le lieu idéal pour y trouver (et y créer) la documentation dont vous avez besoin
Dev Opera : http://dev.opera.com/
On y trouve à la fois la documentation officiel des produits Opera, des articles des équipes d’Opera (chaque employé y a un blog pro.) mais également des articles écrits par des développeurs web indépendants. En effet, n’importe qui peut ouvrir un compte utilisateur et y écrire des articles.

La seul ombre au tableau, c’est le projet Webkit qui ne dispose pas d’une documentation officielle (en tout cas, je ne l’ai pas encore trouvée). On notera tout de même que depuis un peu plus de 1 an, les équipes de Google collabore avec Mozilla au sein de MDN pour que la documentation de référence soit la plus générique possible.

Le temps de l’action

Le fait est qu’on est encore loin d’avoir des documentations dignes de ce nom et, soyons claire, on n’est finalement jamais aussi bien servi que par soit même.

Aussi, je vous invite à écrire ce que vous savez. Il n’est pas nécessaire de faire de très long articles détaillés, mais simplement, mettre le résultat de vos expérimentations (à titre d’exemple, regardez ce que font Raphael Goetter avec IE7 no more ou la Web Agency Tympanus sur son blog). Quoi que vous en pensiez, ce sera toujours utile à quelqu’un (ne serais-ce que pour vous). Ok, ce que vous découvrez à peut-être déjà été écris ailleurs… mais ça n’a pas d’importance car plus il y a d’articles sur le même sujet, plus l’information est facile à trouver. Ne soyez pas timide, écrivez

Mais ce n’est qu’un début. Pour aller plus loin, je vous invite à regarder de près l’initiative Move the web forward qui détaille tout ce qu’il est possible de faire pour contribuer (au delà de la documentation) à améliorer le Web.

Enfin, et c’est là que les choses commence à se structurer, plusieurs organisations travaillent sur la documentation du Web ouvert. On notera en particulier deux acteurs majeurs de ce travail de documentation :

Mozilla

Depuis 2 ans environ, Mozilla a entamé un travail de fond visant à transformer MDN pour en faire une source de documentation neutre. Ainsi, pour tout ce qui concerne les standards du Web, vous y trouverez une documentation de référence pour les principaux langages (HTML, CSS, SVG, MathML, Javascript, etc.). L’objectif est, pour chaque balise, propriété, API, attribut, … de fournir une explication de comment ils s’utilisent avec des exemples, des cas d’usage, tout en documentant les spécificités liées aux implémentations de chaque navigateur.

Réaliser une telle documentation prend du temps et toute les bonnes volontés sont appréciées. Si vous voulez participer, vous n’avez rien d’autre à faire que de vous créer un compte utilisateur sur MDN et à écrire (c’est un Wiki rappelons-le). Si vous ne savez pas par quel bout commencer ou si vous pensez que vous n’êtes pas à la auteur pour participer, j’organise tous les mercredi une soirée de découverte de MDN dans les bureaux de Mozilla à Paris. N’hésitez pas à venir, même si c’est juste par curiosité, il y a à boire et à manger . Plus d’information sur la soirée de mercredi prochain : https://mercredidoc.etherpad.mozilla.org/4

W3C

L’été dernier, le W3C à lancé les Community Groups et un des premiers à avoir été créé fut le Web Education Community Group. Ce groupe a été créé à l’initiative de Chris Mills de chez Opera. Chris a proposé de partager le Web Standards Curriculum d’Opera sous licence libre. Il a donc été mis sur un Wiki dédié au W3C et désormais, tout le monde peu participer à son enrichissement. De manière plus général, ce Community Group à pour vocation de créer et promouvoir du matériel pédagogique à destination des professeurs et formateurs qui enseignent la création de sites Web.

Si vous êtes formateur ou enseignant vous devriez sérieusement envisager de participer à ce groupe. Contrairement aux groupes de travail sur les spécifications, la participation aux Community Groups est gratuite. En ce qui me concerne, je prévois de participer à la traduction Française du Web Standards Curriculum. Si vous voulez aider à faire cette traduction, laisser un message sur la mailing-list du groupe, je vous recontacterai alors pour qu’on se coordonne

Conclusion

La documentation du Web ouvert est un espace à défricher. Si vous voulez bénéficier d’une documentation de qualité, pour vous ou pour les autres, c’est à vous d’agir. Soyons claire, documenter est un travail long et ingrat dont on ne retire les fruits que plusieurs mois ou année plus tard. Ceci étant, il n’y a pas de secret, les projets qui marchent ce sont les projets qui bénéficient d’une documentation de qualité. C’est également vraie du Web et de la création de site. Retenez cependant 2 choses : Quelque soit votre contribution, aussi petite soit-elle, il y aura toujours quelqu’un pour vous en remercier un jour ; Si vous devez documenter quelque chose, documentez ce dont vous avez besoin pour vous-même, d’autre auront un jour ou l’autre le même problème que vous… la documentation est sans doute le seul domaine d’activité ou une action purement égoïste est également totalement altruiste

Paris Web 2011 : SVG et Typographie

Jeremie — Tue, 18 Oct 2011 16:58:00 +0200

Paris Web 2011 s’est tenu les 13, 14 et 15 octobre dernier. Cette année encore j’y étais et force et de reconnaitre qu’une fois de plus, l’équipe a sué sang et eau pour en faire un évènement de qualité inégalé. Bravos à tous, vous avez assuré grave

Le programme était vraiment d’excellente facture, et je retiendrai en particulier deux conférences : D’une part, celle d’Antony Ricaud qui a pris le temps d’expliquer et de détailler comment fonctionne un navigateur (chose que peu de web designer connaissent mais qui explique beaucoup de choses, comme par exemple “pourquoi les sélecteurs CSS sont lus de droite à gauche”) ; D’autre part, celle de celinecelines qui a fait la démonstration d’une énergie incroyable et d’un enthousiasme peu commun, mais ô combien communicatif et stimulant. Merci Céline.

De mon coté, ça a été un peu le grand schelem. En effet, l’équipe d’organisation à accepter toutes mes propositions (‘^_^) je me suis donc retrouvé à présenter un lightning talk, une conférence et un atelier… argle !

Lightning talk

Le challenge consistait à parler d’un sujet pendant seulement 4 minutes. Ça demande d’aller droit à l’essentiel et d’être percutant. Vu que je traitai déjà de sujet assez sérieux pour ma conférence et mon atelier, j’ai proposé un “truc rigolo”. J’ai donc fait une animation SVG pour illustrer la lutte permanente des standards du Web pour un Internet meilleur. J’ai demandé l’aide de ma collègue Corinne Massacry pour réaliser tout le “Character Design” et j’ai réalisé toute les animations à la main (il n’y a pas d’éditeur d’animation SVG connu à ce jour, donc, tout à la mimine… ce qui prend un temps infinie, j’ai terminé l’animation la veille de la conf en y passant la nuit :-/)

Voila le résultat :

Vous pouvez télécharger le fichier SVG ici : http://jeremie.patonnier.net/experiences/parisweb2011/animation.svg

Pour la petite histoire, l’ensemble des éléments graphiques ont été réalisés avec Adobe Illustrator. Pour ce qui est de la réalisation de l’animation, dans le mesure où, lorsqu’on code à la main, c’est très difficile de se déplacer d’un point à l’autre de l’animation, je l’ai animée à l’envers. Concrètement, j’ai animé la dernière scène, puis l’avant dernière scène, etc. De cette manière, à chaque fois que je rafraichissais l’animation, je voyais immédiatement ce que je venais d’animer sans avoir à attendre que le début de l’animation soit joué (plusieurs minutes) pour pouvoir vérifier ce que je venais de faire (parfois moins d’une seconde d’animation)

Conférence : “La typographie, mon navigateur et moi”

Lors de cette conférence, j’ai eu l’occasion d’expliquer comment les polices typographiques sont miraculeusement affichées par les navigateurs Le coté sympa, c’est qu’à l’origine, cette conférence devait durée 30 minutes et que suite au désistement de dernière minute d’un orateur, elle a finalement pu durée 1 heure avec plein de questions et réponses. Je vous met les slides ici, mais la vidéo sera sans doute beaucoup plus intéressante. Je vous tiens au courant dès qu’elle est disponible.

Atelier : “SVG et le web design moderne”

1h30 à la découverte de SVG. Je ne cache pas que pendant l’atelier j’ai un peu angoissé en voyant les nombreux visages extrêmement sérieux et concentré en face de moi. Heureusement, il semblerai que l’atelier ait bien plus à tout le monde. Je vous met ici les slides, les exemples et les différents liens que j’ai eu l’occasion d’évoquer.

Les slides : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/presentation.odp
Les exemples :
- Exemple d’un fichier SVG basic : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/basic.svg
- Les différentes manière d’inclure du SVG dans du HTML : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/inclusion.html
- Comparaison entre SVG, RaphaelJS et Canvas : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/svg-raphael-canvas.htm
- Exemple d’usage avancé avec CSS3 : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/monsieur-ou-madame-1.htm
Les liens à voir (en vrac) :
- http://raphaeljs.com
- https://github.com/wout/raphael-svg-import
- http://mbostock.github.com/d3/
- http://jvectormap.owl-hollow.net
- http://rickardsund.com
- http://discover.store.sony.com//piiq/
- http://evolutionofweb.appspot.com
- http://vlog.it
- http://type.method.ac
- http://www.goodreads.com (l’icone de “rating” est en SVG et reprend les données réelles de vote sur chaque livre)
- http://www.drawastickman.com
- http://www.nissanusa.com/leaf-electric-car/index
- https://developer.mozilla.org/en/SVG

Là aussi, la vidéo sera bien plus parlante, je vous la mettrai dès qu’elle sera là

Voila, comme d’habitude, c’était bien chouette, encore un gros merci aux organisateurs et vivement l’année prochaine (mais je proposerai moins de choses parce que là, c’était vraiment trop dur de préparer tout ça).

SudWeb 2011 : Coup d'essai, coup de maitre

Jeremie — Tue, 21 Jun 2011 09:54:00 +0200

Note for English speaker, there is an English version down below

Le 27 mai dernier, j’ai eu la chance de participer à la toute première édition de SudWeb à Nîmes. Partie sur une boutade lors du dernier Paris Web, les organisateurs se sont juste arrachés pour arriver à monter le truc en à peine 6 mois. Bravo à tous, ce fût beau ! Car on peut le dire, pour un coup d’essai, ce fût un coup de maitre. Au delà de la logistique impeccable, l’ensemble du programme des conférences était tout simplement parfait. Mixant à la fois les aspects fonctionnels, techniques et prospectifs, l’équilibre du déroulé m’a complètement estomaqué (ainsi que le respect des horaires, tenus d’une main de fer, couplé à des moments de pause ô combien conviviaux).

Vous n’y étiez pas ? Ce n’est pas grave. D’une part toutes les conférences ont été filmées et devraient être disponibles prochainement et d’autre part, il y aura une autre édition l’année prochaine, viendez-y

En ce qui concerne mon nombril, j’ai eu l’occasion d’y donner une conférence sur un sujet qui me tient à cœur depuis un peu plus d’un an : SVG. Au cours de cette conférence, j’ai montré ce qu’il était possible de faire aujourd’hui avec SVG (qui, rappelons le, est disponible dans tous les navigateurs moderne). Plutôt que de m’attacher aux questions techniques qui tourne autour de cette technologie, j’ai préféré mettre l’accent sur des outils et des résultats concrets. L’idée étant de montrer comment des designers et les développeurs on déjà utilisé SVG et ce qu’il apporte au web design moderne.

Évidemment, même si j’ai oublié de le préciser pendant la conférence, je n’ai pas pu m’empêcher de réaliser mes slides en SVG, les voici (cliquez sur l’image pour lui donner le focus et utilisez les flèches de direction pour passer d’un slide à l’autre) :

Vous pouvez accéder à ma présentation SVG à cette adresse : http://jeremie.patonnier.net/experiences/sudweb2011/presentation.svg

A noter que je cite tous les sites suivant :

Outils

http://code.google.com/p/svgweb
http://raphaeljs.com : Vous devriez tous avoir cette bibliothèque dans votre trousse à outils si vous voulez réaliser du SVG tout en étant compatible avec les vieux IE.
http://www.highcharts.com : LA bibliothèque pour faire des graphiques de données sans vous casser la tête.
http://mbostock.github.com/d3/ : D3.js est une bibliothèque qui vous permet de mapper des données au seins de graphiques vectoriels en SVG. C’est un pont technique idéal entre les développeurs qui doivent manipuler ces données et les designers qui doivent les mettre en scène.

Références

http://www.thenounproject.com : Projet mettant à disposition des icones libres de droit au format SVG. Indispensable pour réaliser de la signalétique. A noter que toutes les icones proposées sont composées d’un seul est unique chemin SVG ce qui en fait une base travail extrêmement propre et malléable pour les Web designers.
http://www.bifter.co.uk : Web comics humoristique intégralement réalisé en SVG.
http://opendata.zeit.de/pisa-wohlstands-vergleich/visualisierung.php : Le journal allemand Zeit propose une visualisation de données démographiques intégralement réalisée en SVG
http://www.nissanusa.com/leaf-electric-car/index : Dans la série “Non, ce n’est pas du Flash” Nissan USA fait une magnifique utilisation de SVG pour proposer une navigation non linéaire des caractéristiques de sa nouvelle voiture électrique. A noter que RaphaelJS est utilisé pour assurer la compatibilité avec IE6, 7 et 8 (et oui).
http://rickardsund.com : Je n’ai pas de mot assez fort pour exprimer l’adoration que j’ai pour ce site. Pour moi, Il représente la quintessence du Web design moderne. D’un coté un design épuré à l’extrême qui sert parfaitement son propos. Il est l’œuvre de Hugo Ahlberg qui a un lourd passif de designer Flash, ce qui lui a permis de s’extraire des contraintes (artificielles) du design web traditionnel. D’un autre coté, il est intégré à la perfection en utilisant exclusivement des standards Web : HTML5 (à noter en particulier la magnifique utilisation de l’API History), CSS3, JS (Du “mouse gesture” de toute beauté) et bien sur du SVG (par petites touches mais indispensables). Ce travail formidable a été réalisé par Daniel Mahal et Daniel Connor qui font là une démonstration d’excellence de ce que devrais toujours être une intégration aux standards, en particulier la maitrise de la dégradation élégante qui est quasi parfaite : Ce site fonctionne dans IE6 ! Vous DEVEZ regarder la source de ce site et vous en inspirer.

Pour conclure, je n’ai plus qu’une chose à dire : Longue vie à SudWeb, vivement l’année prochaine

On May 27th, I got the chance to attend the very first SudWeb event in Nîmes, France. Starting on a joke during the last Paris Web event, the people behind SudWeb make it possible in just 6 months. Thanks dudes that was awesome! We can say it, for a first run that was a master piece. Beyond the perfect logistic, the program was just great. Talks were amazingly well balanced between functional, technical and prospective subjects (and the schedule was perfectly mastered with good time to talk and network with people).

You wasn’t their ? Don’t worry. First, all the talks were camcorded and should be available soon. Second, there will be another edition next year, attend it

On my own, I had the opportunity to give a talk about one of my favorite subject for a year now : SVG. During this talk, I show off what is it possible to make with SVG today (which, as a reminder, is available in all modern browsers). Instead of talking about technical stuffs, I focused on tools and practical results. The idea was to demonstrate how designers and developers had used SVG and what that technology brings to modern Web design.

Of course, even if I forgot to mention it during my talk, I felt oblige to made my slides with SVG. Here there are (see above, click on the image to give it the focus then use the arrow keys to switch between the slides).

Note that I use all the following web sites as examples:

Tools

http://code.google.com/p/svgweb
http://raphaeljs.com : You should all have that library in your toolbox if you want to use SVG with IE compatibility in mind.
http://www.highcharts.com : THE library to build charts without headache.
http://mbostock.github.com/d3/ : D3.js is a library that allow you to connect data with graphics. This is an awesome bridge between developers that deal with data and designer that deal with graphics.

References

http://www.thenounproject.com : That project collect visual symbol and make them available in SVG. Note that all the symbols are made of one single SVG path. That make them highly usable as a work basis for Web designers.
http://www.bifter.co.uk : A humorous Web comics build with SVG.
http://opendata.zeit.de/pisa-wohlstands-vergleich/visualisierung.php : The dutch newspaper Zeit had a demographic data representation driven by SVG.
http://www.nissanusa.com/leaf-electric-car/index : Ok, so “This is NOT Flash”. This is a great SVG work made by Nissan USA to build a non-linear navigation system. Take care about the library behind the scene, it’s RaphaelJS. This means that it works properly even with IE6, 7 and 8 (crazy!).
http://rickardsund.com : I do not have strong enough words to express my love for this web site. To me, it’s the best of modern Web design. On the one hand, the simplistic design suits its subject perfectly. It has been made by Hugo Ahlberg who has extensive skills in Flash design. Those skills give him the ability to overcome the classic HTML web design. On the other hand, This Web site is perfectly develop with Web standards only : HTML5 (with a noticeable use of the History API), CSS3, JS (awesome mouse gesture) and, of course, some small (but essential) touches of SVG. This amazing work has been done by Daniel Mahal and Daniel Connor who demonstrate what a Web standards front-end development should always be. They especially mastered the graceful degradation: This site works perfectly with IE6 ! You SHOULD look at the source and use it as an inspiration.

To conclude, there is one thing left : Live long SudWeb, I strongly hope for the next edition

Alors s'en vient le temps du changement.

Jeremie — Wed, 13 Apr 2011 11:59:00 +0200

Je sais que je blogue assez peu en ce moment. Ne m’en veuillez pas, c’est qu’il se passe pas mal de choses actuellement pour moi avec peux de temps pour venir écrire ici.

D’abord, si vraiment vous voulez lire des trucs que j’ai écrit moi-même comme un grand, allez faire un tour sur typographisme.net, mon dernier billet en date parlant des ligatures dans les navigateurs.

En suite, je suis en train de préparer ma présentation pour SudWeb 2011. Comme je vais y parler de SVG, je ne peux bien sur pas faire autrement que de préparer un support de présentation lui aussi en SVG (il sera en ligne après la conf). Ça se passe le 27 mai à Nîmes, le programme est alléchant et le prix raisonnable, n’hésitez pas à venir y faire un tour.

Enfin, je change de travail Après 5 ans passé au sein de Cetelem (organisme de crédit pour les particulier du groupe BNP Paribas) en temps que responsable d’équipe de développement web, je vais rejoindre CleverAge où je serais consultant web (ou chef de projet ça dépendra des clients et des missions ). C’est prévu pour le 2 mai et en attendant, c’est un peu “je cours dans tous les sens pour plier les questions administratives”.

Sur ce… qu’un millier de colombes constipées illuminent votre journée.
A bientôt

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é) :

Why are SVG Fonts so different?

Jeremie — Mon, 07 Feb 2011 09:30:00 +0100

Une version française de cet article est disponible sur typographisme.net : Pourquoi les fontes SVG sont-elles différentes des autres ?

I’m sad to see that there are many misconception about SVG fonts. I’ve read a lot of articles and complains about the SVG font format and the last (but not the least) was an article from Alexander Limi explaining why Firefox will not pass the Acid3 test mainly due to a lack of SVG font support. All those complain are misplaced in many way because SVG fonts are misunderstood. Really? But in this case, what are SVG fonts made for? Let’s see that.

Forget it for regular text

One of the biggest misconceptions about SVG fonts is thinking that this format is suitable for regular HTML text. Unfortunately, it is not! In my opinion, this misconception is mainly due to Apple. Until iOS 4.2, SVG was the only format available to use custom fonts on iPhone and iPad. And because this support was (is?) somewhat buggy, SVG fonts’ reputation was badly injured.

Anyway, beyond iOS SVG font support, it’s a fact that SVG font format does not support font hinting. To understand that so called “lack” it’s important to think back about the specificity of the SVG image format. SVG shapes are placed in an absolute coordinate system and SVG documents do not have text flow ability such as HTML documents. Also, SVG documents do not necessarily have pixel perfect dimensions and the shapes can be subjected to mathematical transformations (rotation, scaling, skewing, etc.). So this means that a glyph can be placed anywhere in a document and its shape modified, but most of the time it won’t match a pixel perfect size nor even a pixel perfect grid. With all those constraints, hinting is not really helpful because it needs a pixel grid system to give its best.

If you simply try to use a WOFF font in an HTML document and apply a CSS3 2D transform, you’ll see that even with a hinting system, this does not really make a difference. But on the contrary, on regular HTML text that is pixel perfect positioned, SVG fonts are not so beautiful especially at small size. So yes, in an HTML document, SVG fonts are poor. But, as I said, it’s not their main purpose.

The power of drawing tools

In regards of other fonts formats, one of the biggest advantages of SVG fonts is the way shapes can be drawn.

Technically speaking, the shapes in SVG fonts can be made of any kind of curves (cubic or quadratic Bezier in different flavors or arc definitions) where shapes in TrueType fonts can only be made of quadratic Bezier curves. OpenType fonts are a bit smarter by supporting cubic Bezier curves, but for what I know no other font format supports arc definition. So, in theory the outlines produced for SVG fonts could be much more optimized than in other font formats. Ok, let’s be honest, it is not often the case in classical glyph design. But there is more. Because SVG fonts could use all the power of SVG it is possible to draw very complex shapes by mixing arbitrary paths and basic SVG shapes, which gives you a more control over your font design. So when you want to design an ornamental font, SVG gives you better tools to do so.

Practically speaking, it’s possible to use any software supporting SVG to draw fonts. This includes traditional font software such as FontForge but it’s also possible to take full advantage of drawing software such as Adobe Illustrator or Inkscape (this one provides powerful tools for drawing fonts). Of course such drawing software can be used to produce outlines for other font formats but you’ll always need to export them inside a specific font tool to convert those outlines to the right curves definition (which can have side effects on your design). With SVG, you don’t need to. You can directly use the output from your drawing software.

Animation, filters, video… \o/

Let’s go forward. SVG, beyond its drawing ability, has some amazing extension such as gradients, patterns, clipping, masking, animations, filters or even foreign object inclusion. It means that you can use all of this inside your SVG fonts. Yes it’s possible to produce native animated font with SVG. With filters, you can produce blurry or textured fonts. And with foreign object inclusion… Wow ! There’s no limit. Why not imagine a font with a sound background? Yes it’s possible, just include an HTML audio element and it’s done.

Of course it’s not necessarily wise to do such things. Especially if you want to use such a font for regular text. But think about it. The SVG font format unleashes your creativity to a brand new world. Say good-bye to the legacy “lead & paper” typography and jump out the final frontier with the upcoming of fonts made FOR the web (and not just backported to it).

Embedding and DOM Access

You think it’s amazing? Let’s go one step further in the twilight zone.

Historically speaking, ten years ago, SVG font was the only font format that could be embedded inside an SVG document. This feature was required to ensure that the rendering of a font inside an SVG document would remain consistent across different platforms and user-agents. Today, thanks to CSS @font-face and Data URI, it’s possible to embed any type of font format, but still, SVG fonts have always a huge advantage here.

As you know, SVG is an XML format so SVG font as well. This means that you can embed SVG fonts inside any XML document (for example in an SVG image or in an XHTML document and, in a near future, with HTML5, in any ordinary HTML document) and still have access to the glyphs through the DOM of the XML document. And this is huge because it means two crazy things:

You can easily access the font content through Javascript and change it as you wish for whatever reason. The SVG font format lets you in control of each individual glyph at runtime.
You can use CSS to style each individual glyph which gives you an amazing control on how the font will be rendered.

The other font formats do not provide such an easy and full access to their core design.

Security, accessibility, bla, bla, bla…

With such great power come amazing responsibilities. Security is one of the main concerns about SVG fonts. As Borris Zbarsky points out : Once you put an <iframe> in a glyph, all sorts of issues arise and is damn right. This point have to be discussed but is it a reason to drop everything? I don’t think so.

Another concern is about accessibility - so highly interactive fonts raise many issues, for example “how the user can control the animation on an animated font?”. But these questions are basically of the same type as those SVG brings on its own. So it’s possible to rely on the solutions available for SVG in a general purpose.

Of course it’s necessary for both browser constructors and web authors to take care about all those constrains. I’m sure some evil web authors will use SVG fonts badly, sure that browser vendors (all of them) do not presently do their best to support SVG fonts. So be it - but I think that SVG fonts are a real turning point in the history of typography and should be taken for what they really are: an amazing tool to bring fresh design ideas in typography and cool typography in web design. And it’s important to remember that SVG fonts do not play the same game as WOFF fonts on the web. Both formats have their strengths and weaknesses but there are not mutually exclusive.

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.

Mais qu'est-ce que c'est donc qu'il se passe ?

Jeremie — Tue, 26 Oct 2010 11:08:00 +0200

Certains auront peut être remarqué que je n'ai rien posté ici depuis un moment. Il faut bien avouer que les 3 derniers mois ont été un peu chargés.

Premièrement, J'ai été bien accaparé par la préparation de l'atelier que j'ai donnée à Paris-Web 2010 sur le thème "CSS 3 Aujourd'hui". Je vous en reparlerai prochainement, car cette année, quelques ateliers ont été filmés, dont celui-ci :D En attendant, pour ceux que ça intéresse, vous pouvez retrouver les slides et les exemples que j'ai utilisé. Mon seul regret, c'est que l'atelier durait 1h30 alors que j'avais de la matière pour faire un atelier de 3h. Promis, l'année prochaine j'essayerai de faire mieux (si le staff me laisse encore animer un atelier ).

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

Deuxièmement, Je travaillais sur un nouveau site qui vient tout juste d'être lancé. En collaboration avec Anne-Sophie et Virginie, nous sommes heureux de vous annoncer la sortie du site Typographisme.net. Je ne vais pas vous remettre ici le billet d'ouverture, mais pour faire simple, on aime le Web design, on aime la typographie... on trouvait dommage que personne ne parle pas plus des deux à la fois.

Ceci étant, je devrais vite retrouver une activité plus normal (pour ce que ça vaux) car j'ai pas mal de truc à raconter sur SVG et sur CSS (et un peu aussi sur HTML)