Par pitié, Saint W3C, donnez-nous des sélecteurs de parents en CSS !
Cette question a été soulevée de nombreuses fois, mais pour de supposés problèmes de performances, aucune solution n’a encore vu le jour.
Shaun Inman avait proposé en 2008 les « qualified selectors », qui permettent de changer le « sujet » d’un sélecteur CSS, par exemple :
a< img { background: none; }
Merveilleux, n’est-il pas ?
Malheureusement, dans l’un des commentaires, Dave Hyatt (responsable du développement de Webkit, éditeur de la spécification HTML5) avait immédiatement pointé les problèmes de performances que cette solution pouvait poser. Il en profite d’ailleurs pour signaler que la majorité des sélecteurs CSS3 ne devraient pas être utilisés du tout, si l’on se préoccupe réellement des performances de nos pages. Ahem.
Aujourd’hui, Remy Sharp vient de proposer une nouvelle solution, en essayant de prendre en compte les différents problèmes de performances pointés par les implémenteurs. En partant du principe que les sélecteurs sont évalués de la droite vers la gauche, il s’agit d’utiliser un pseudo sélecteur :parent sur un élément, pour indiquer qu’il faut remonter sur l’élément parent.
Ce qui donnerait :
a img:parent { background: none; }
Évidemment, cette solution est plus limitée que la précédente, et peut-être un peu moins claire. Mais on s’en contenterait, non ?
Pour ma part, je pense qu’avec les progrès fantastiques effectués ces dernières années en termes de performances par l’ensemble des navigateurs, nous devrions pouvoir implémenter ce genre de solutions sans pour autant plomber complètement la vitesse d’affichage d’une page. N’oublions pas que l’auteur d’une page est également responsable de la bonne utilisation des technologies qu’il utilise : il est très simple de bloquer un navigateur en JavaScript par exemple. Finalement, le problème vient peut-être du fait que CSS n’étant pas un langage de développement, le W3C à tendance à partir du principe qu’un utilisateur de CSS n’a pas à se préoccuper des performances des sélecteurs qu’il va utiliser, ce qui est complètement illusoire.
Allez, je retourne mettre ma petite classe « img-link » en attendant CSS4.
6 commentaires
Poster un commentaire
Flux RSS des commentaires de cet article
un bon vieux débat : faut il donner beaucoup de puissance potentiellement destructrice en échange d’un peu plus de confort (honnêtement, :parent, ça fait rêver)
Ca marche aussi pour le nucléaire en fait, sauf que ça ne fait pas pousser des bras en plus.
Le problème c’est qu’il est extrêmement difficile de débusquer des problèmes de performances CSS sur une page.
D’un autre côté, il suffit qu’un outil facilitant l’accès à cette info sorte, puis qu’il soit évident pour la majorité des codeurs CSS que certaines choses sont à éviter pour que le W3 change finalement d’avis
Et quoi qu’en dise des développeurs web comme remy sharp, le W3 est composé de ceux qui implémentent dans les navigateurs ce genre d’amusement, donc si ils parlent de problèmes de perfs, ils savent ce qu’ils disent :)
Perso je suis quand même pour sortir ce genre de spec dans CSS3 : elle ne sera de toute manière pas vraiment utilisée puisqu’il n’y a aucune rétro-compatibilité, et d’ici à ce que … IE9 disparaisse, les machines et les navigateurs seront tellement surpuissants que cette question de perfs ne se posera probablement plus
Le 11 Oct. 2010 à 15h05 par jpvincent
Je ne peux que cautionner cette demande. Ce sélecteur semble comme naturel. Un sélecteur permet de sélectionner une balise en fonction de son contexte. Pourquoi alors se limiter au contexte parent ?
Je pense qu’il n’est pas bon que les personnes qui remplissent la liste de noël soient aussi celles qui vont sortir l’argent pour acheter les cadeaux. En d’autres mots, la technique ne doit pas être un frein ni aux idées ni aux usages !
Bonne continuation,
Thomas.
Le 11 Oct. 2010 à 15h20 par Thomas
C’est une proposition intéréssante ;
jQuery nous a effectivement habitué a manipuler le DOM avec une facilité déconcertante, (bien que ce ne soit pas a l’aide des sélecteurs que jQuery nous permette de sélectionner les éléments parents) qu’on se retrouve presque frustré devant la feuille de style !
Peut être que des scripts type http://selectivizr.com/ , tant qu’a faire dans le « moins de performance » pourraient subvenir aux plus pressés d’entre nous pour l’implémentation de cette possibilité !?
Le 11 Oct. 2010 à 15h38 par korvus
Comment peut-on parler de problème de performances sur des technos comme CSS, xml, HTML etc. ?
Alors que le net actuel est bourré de flash, et bibliothèque Javascript et d’effets parfois simple mais tout de même très lourd…pouvant faire ramer nos bécanes survitaminées.
L’excuse du surf par téléphone mobile (très en vogue en ce moment) ne tient pas : ces petites bécanes supportent Flash (Android notamment, mais pas l’iPhone ), les mobiles sont de plus en plus puissant et comme l’a dit Thomas un peu plus haut, les limitations techniques ne peuvent pas être un frein à la créativité : surtout avec l’importance du net aujourd’hui, arguer de limitations techniques ce n’est pas acceptable.
Bref, un sélecteur supplémentaire pour se « promener » dans le DOM, ne devrait pas poser problème, sinon ça voudrait dire que la techno est mal faite, non ?
Le 12 Oct. 2010 à 10h56 par mrjay42
Oui la techno du DOM est contre-performante
pour la faire courte : on fait des applications avec des technos qui sont faites à la base pour afficher du texte et le rendre un peu joli, donc les navigateurs se battent pour essayer de suivre, et ça se joue même en CSS.
mais on n’a rien d’autre à se mettre sous la dent pour faire tourner des applis sur un navigateur, à moins que tu ne veuilles faire du flash, du silverlight, ou adopter le modèle des applications façon Apple Store ?
Le 12 Oct. 2010 à 11h12 par jpvincent
Apparement, c’était prévu pour le CSS3 avec cette syntaxe-là « a:contains(img) ».
Mais ça a finalement été laissé de côté.
Source : http://www.w3.org/TR/css3-selectors/#content-selectors
On y était presque !
Thomas.
Le 21 Oct. 2010 à 16h33 par Thomas