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: Sun, 28 Apr 2013 15:24:50 +0200
Message-ID: <DUB120-W15BFCBF8FE620715CCCEF1A5B10@phx.gbl>
To: Tom Wardrop <tom@tomwardrop.com>, "www-style@w3.org" <www-style@w3.org>
Hi Tom,

I understand the uses cases but I'm still thinking multiple after/before pseudo-elements isn't the solution we are looking for. Using genereated content for styling is a hack we shouldn't support too much.

<pro>

Did you check the Web Components 'decorator' property? According to me, it does a way better job of capturing the relationship between the generated elements, of enabling a much more sensible styling of the generated elements and a easier-to-understand structure: you can use local IDs, classes, nested tags... As a bonus point, using decorators is equally transparent to the DOM tree as pseudo-elements are.

Just to give you an idea, using decorators looks like this:

   p::before { content: open-quote }
   p::after  { content: close-quote }
   p {
     decorator: 
        url('decorators.html#LeftSpeechBubble'), 
        url('decorators.html#SomeOtherDecorator'), 
        ...;
   }

   each decorator can define new elements:
   - before the real content
   - after the real content
   - outside the real content
   - anywhere as an inner sibling of the real content (by using insertion points)

</pro>

<cons>

Now, we enter the complex issue of what to do if multiple sources of decorators have to cooperate (ie: the same problem that you have if multiple sources should coordinate to set the 'transform' property on some element) but this issue could easily be solved via list-valued properties and, in the mean time, CSS Custom Properties.

Tab Atkins & myself did some research on list-valued properties and initially found a blocking issue with them (namely: how to order the property values) but I now have sensible ways to solve this issue. I'm not exposing that now because I don't feel it's the good time to work on this, the WG already has a lot of things under the radar at the moment.

</cons>

Thank you for bringing seeds to the mill,
François


________________________________
> Date: Sun, 28 Apr 2013 21:06:31 +1000 
> From: tom@tomwardrop.com 
> To: www-style@w3.org 
> Subject: [css4-pseudo] The need for more powerful pseudo elements 
> 
> What I wish to propose is to further extend the concept that ::before 
> and ::after pseudo elements introduced. I'd like to see these extended 
> into a simple but comprehensive suite of tools for amending the visual 
> markup of a document. I believe CSS should allow developers to generate 
> arbitrarily complex trees of pseudo-elements to allow CSS to be able to 
> (as much as possible) fully negate the need for style-only markup 
> within the source HTML document. As others have suggested, adding a 
> <span> or <div> to your document for the sole purpose of using it as a 
> CSS hook is almost as bad as using <font>. 
> 
> I shouldn't have to point out the current limitations of ::before and 
> ::after, nor the obvious use cases (any example of style-only markup 
> that can't be replaced with pure CSS is a valid use case). The comments 
> associated with this article provide some good 
> examples: http://css-tricks.com/use-cases-for-multiple-pseudo-elements/ 
> 
> In a nutshell, here's what I propose: 
> 
> * Allow multiple ::before and ::after pseudo-elements per element. I 
> know [css4-pseudo] already covers this. The same is assumed to be 
> applied to the new elements suggested in the next few points. 
> * Introduce ::around (or ::outside) pseudo-element to wrap a 
> pseudo-element around another element (normal element, 
> or pseudo element). The content attribute would be ignored for this 
> element as it's ambiguous, and doesn't really make sense anyway. 
> * Introduce ::inside (or ::within) pseudo-element for generating new 
> pseudo-elements that wrap the children of another element, or to 
> otherwise just create a new empty child pseudo-element. Perhaps in this 
> case, the use of the content property could be conditional; ignore if 
> pseudo-element wraps existing children, or respect if the new 
> pseudo-element will otherwise be empty. 
> 
> The implementation should allow for arbitrarily complex trees of visual 
> markup, e.g. 
> 
> #container::inside { 
> content: 'world'; 
> } 
> #container::inside(1)::before { 
> content: 'hello'; 
> } 
> #container::inside(1)::after { 
> content: '!'; 
> } 
> #container::inside(1)::after(1)::inside { 
> content: '?'; /* Ignored */ 
> background: red; 
> } 
> 
> The above would generate this tree of pseudo-elements: 
> 
> <div id="container"> 
> <pseudo>hello</pseudo> 
> <pseudo>world</pseudo> 
> <pseudo> 
> <pseudo style="color: red;">!</pseudo> 
> </pseudo> 
> </div> 
> 
> I hope that at least gives clear indication of the desired outcome. The 
> actual implementation and syntax is obviously up for change. I strongly 
> believe there needs to be more comprehensive support for 
> pseudo-elements in CSS, to allow markup to become entirely semantic as 
> it should be, leaving span and div only to logically group related text 
> and elements that cannot otherwise be grouped by some more semantic 
> element, hopefully eliminating the use of span and div purely as CSS 
> hooks. 
> 
> I'm eagerly awaiting feedback. If there's some consensus that this is a 
> good idea, then we can hopefully fine tune some of the implementation 
> specifics. 
> 
> Tom 
> 
> 		 	   		  
Received on Sunday, 28 April 2013 13:25:17 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 28 April 2013 13:25:17 UTC