Support des selecteurs CSS3 amélioré dans Firefox 3.0
Par Laurentj le mardi, février 19 2008, 11:09 - Technologies Web - Lien permanent
David Baron vient d'intégrer dans les sources de Firefox 3 des corrections sur les sélecteurs de pseudo classes (genre :empty, :only-child, :last-child etc..). Avant, par exemple, il y avait un bug avec :empty : la sélection se faisait bien au chargement du document, mais si un élément non vide devenait vide ou l'inverse, la sélection ne se faisait plus. Et je vous parle de :empty parce que ce bug m'empêchait d'utiliser ce sélecteur dans Etna, mon éditeur XML wysiwyg, et m'obligeait du coup à des petites acrobaties dans le code qui me déplaisaient.
Ainsi, grâce à cette correction, le support des sélecteurs CSS3 dans Firefox 3.0b4 sera largement amélioré, la suite des tests de css3.info en atteste. Voici un comparatif :
| Firefox 2 | Firefox 3.0b3 | Firefox3.0b4 | |
|---|---|---|---|
| Sélecteurs OK | 26 | 32 | 36 | Sélecteurs buggés | 10 | 4 | 0 | Sélecteurs non supportés | 7 | 7 | 7 | Total des tests ok | 357/578 | 369/578 | 374/579 |
En fait, il ne reste plus que 7 sélecteurs à implémenter correctement : :nth-child(), :nth-last-child(), :first-of-type,
:last-of-type, :only-of-type, :nth-of-type(), :nth-last-of-type(). Peut-être y'aura-t-il encore des améliorations sur ceux-là d'ici Firefox 3 final mais ce n'est pas encore sûr.
À noter que webkit (safari et Konqueror) ainsi qu'opera je crois, passent la suite de test complètement avec succés.
PS : une autre conséquence de cette correction est que trois tests supplémentaires passent avec succés [au test acid3|http://acid3.acidtests.org/], avec un score de 64/100.
Commentaires
C'est dommage, les sélecteurs pout obtenir le premier ou le dernier élément d'un type sont monstrueusement utiles. les nième élément aussi. A la limite le :empty d'un pur côté webdev, j'en vois moins l'utilité.
FF3 se bonifie au fil des betas, c'est très bien :) Vivement le support d'
nth-child!Ouaouh... L'adoption des standards se fait à grande vitesse. J'espère que MS va mettre les bouchées doubles sur IE8 pour rattrapper son retard sinon il va encore y avoir un webdesign à 2 vitesses. :)
Pour safari ce n'est que la nightly build, safari Version 3.0.4 (523.12.2) donne 25 bon, 9 buggés et 9 non supportés
Pour Opera 9.25 (osX) 25 bon, 3 buggés et 15 non supportés
@goetsu: ok. Pour Konqueror 3.5.8 par contre, ça passe.
Ce qui est dommage c'est que ff 2 et 3 aient le même nombre de sélecteur non supporté.
Ben oui, vu qu'ils n'ont pas exactement le même rendu, comment les différencier via des "hack" css ? J'ai passé un moment à chercher, mais pas moyen de mettre la main sur un sélecteur ou une tournure permettant de différencier ff3 du 2 dans un css...
(sinon c'est bien pour firefox quand même ;-) )
@crEv: je ne comprend pas ta remarque. ff2 et ff3 ont le même nombre de sélecteurs non supportés, mais il s'agit des mêmes sélecteurs. Donc je ne comprend pas que tu veuilles différencier dans FF2 et FF3, des sélecteurs qui n'existent dans aucun des deux. Et puis, je ne sais pas si tu as bien lu quels sélecteurs il s'agit : on ne peut pas dire que ce soit des sélecteurs vraiment à utiliser, vu qu'ils sont peu implémentés dans les navigateurs les plus utilisés.
Conçernant ceux dont les bugs ont été corrigés, pareil, ce sont des sélecteurs qui jusqu'à présent étaient peu utilisés, donc tes hacks css, tu va pouvoir les oublier.
Bon et puis les hacks CSS, c'est mal. :-p
Désolé de ne pas avoir été plus clair. Les hacks CSS sont peut-être mal, mais tant que les navigateurs n'auront pas le même rendu (et ff2 et ff3 ont justement des rendus différents) ils seront bien utile (ou alors jusqu'à ce qu'il y ait une autre solution utilisable...)
Et donc je cherchais justement des sélecteur qui par hasard marcheraient sous ff3 et pas sous ff2 pour pouvoir avoir des règles css différentes selon les navigateurs (comme on utilise > pour que ce ne soit pas lu sous ie < 7, ou :not(:root:root) encapsulé dans un peu de css pour safari, ...)
Le fait qu'ils soient peu utiliser importe pu du moment qu'on peut les utiliser suffisament pour les différencier ;-)
Ouai enfin, vouloir un rendu identique sur tout les navigateurs est illusoire. Pire, je dirais, c'est ne pas comprendre le web.
Utiliser des hacks CSS, c'est retomber dans les travers de la programmation cross-browser. C'est moche, ça consomme du temps et des ressources trop importantes en regard du résultat.
Franchement, l'internaute, il en a rien à cirer que le site soit différent d'un navigateur à un autre. Ce qu'il l'intérresse, lui, c'est que le site soit lisible et présentable dans son navigateur. Tu crois qu'il va tester ton site dans tout les navigateurs pour après râler parce que la sidebar sur IE est plus large de 10px que dans FF ?
Personnellement, je n'utilise plus de hacks CSS depuis longtemps, je m'en porte beaucoup mieux, et finalement il n'y a aucun souci.
Le seul "hack" politiquement acceptable à la limite, c'est l'ajout de feuille de style spécifique à IE par le biais de commentaire conditionnels HTML, IE ayant des comportements trop différent au niveau du rendu. Pour le reste, les autres navigateurs ont des comportements et rendus proches des standards, cela ne vaut pas le coup de mettre des hacks CSS dans tout les sens.
heu... oui mais non Si je suis d'accord avec ceci concernant les _sites_ web, le fait est que je bosse sur des _applications_ web, qui elles ont besoin d'être calés au pixel près... (et en outre ce n'est pas dans mon cas un problème de pixel, mais d'interprétation de padding, de taille d'image css)
Pour les sites, je n'utilise que très très peu de hacks css. Mais pour des applis, il n'est pas possible de faire sans. Bon en réalité, j'utilise peu (le moins possible) de hack css, uniquement de quoi corriger le box model de ie, et quelques interprétations différentes sous safari.
Si ça ne tenais qu'à moi, la solution serait simple, je placerait en prérequis d'avoir un firefox / safari récent ... mais les clients n'en veulent pas des prérequis...
(par contre, merci pour le lien, je ne connaissais pas)
Et coment avance l'implentation de CSS Media Queries qui ouvre des possibilité intéressantes ?
MDR, j'adore le "calés au pixel près..." (CrEV)
J'aimerai voir ce que ça donne sur le portable de ma copine (1280x800 !), l'écran plat de mon desktop 1400x1260) et un pda lambda.
C'est vraiment une obsession d'infographiste du temps du papier ! Faut apprendre à lâcher prise et à concevoir des css qui coulent bien dans le moule de la fenètre disponible.
+1 Nicolas Krebs, ça m'intéresse aussi ça !
« Et coment avance l'implentation de CSS Media Queries qui ouvre des possibilité intéressantes ? »