W3C home > Mailing lists > Public > www-style@w3.org > April 2013

RE: [css4-pseudo] The need for more powerful pseudo elements

From: François REMY <francois.remy.dev@outlook.com>
Date: Tue, 30 Apr 2013 15:42:09 +0200
Message-ID: <DUB120-W44662DF825CE27356202A4A5B30@phx.gbl>
To: Tom Wardrop <tom@tomwardrop.com>, "www-style@w3.org" <www-style@w3.org>, Sam L'ecuyer <sam@cateches.is>
> Decorators, shadow DOM and all of that is all very interesting, and 
> opens up many possibilities, but they're quite complicated proposals 
> and verbose in syntax. 

I agree with you on this. They could be made more seamless for the more general cases. I don't think the CSSWG discussed this either, so that may still come at some point.

> I think CSS zen garden serves as a good example where decorators 
> would probably be useless. Decorators use HTML, therefore, if you have 
> a situation where you cannot modify or add HTML, decorators are going 
> to be of little use. 

Decorators do not have to be in the same file as your primary HTML. The same way you can link to an image or a font from your CSS file, you can link to your favorite decorator libraries. I'm also not against declaring decorators using CSS directly for the cases where HTML features are not needed. Something like

   @decorator video {
      content: contents slot(icon) slot(text);
      @slot(icon) { content: ' V'; font-family: ...; }
      @slot(text) { content: ' video'; }

or, for the spec sample:

   @decorator fog {
      content: slot(wrapper);
      @slot(wrapper) {
         content: contents slot(overlay);
         position: relative;
      @slot(overlay) {
         position: absolute; top...;
         background: rgba(...);

or, with insertion points, why not:

   @decorator only-first-image {
      content: contents(img:first-of-type);

This gives you the same expression power as the ::inside/::outside pseudo-elements because you can unwrap slots at any time, but this seems more elegant to my eyes. The downside of CSS slots over HTML ones is that you can't define events on them (at least, there's no way to do this currently).

> Also, if ordinals are such a pain in the ass (I don't really like them 
> myself), is there any particular reason why ::before and ::after can't 
> be named, e.g. span::after(shadow) { } or span::after("my shadow") { }? 

The solution I've found to bring sane order of named values to list-valued properties would not work on pseudo-elements. That does not mean there's no way to find a solution that works in that case, however. 

Anyway, as I said, it's likely multiple before/after pseudo-elements will be introduced at some point; people like Alan Stearns have pushed for that and I didn't hear many people saying we might want to delay the feature a bit to introduce it (the way I think is) the right way.

Received on Tuesday, 30 April 2013 13:42:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:10 UTC