Re: Overloading pseudo-elements seems bad, was: Need a better way to reach into the shadow DOM subtree

You can already make ugly things in CSS. Or make things break horribly. What we need is a way to provide fine styling of components. There’s no reason why an author would like to make his document ugly, and if he will, he will be able to do it anyway. 
If an author uses some tricks to style an element, he knows he may need to update his code when the control is updated. An since a control is updated locally on the website, the website author can stick with an old version as long as he can’t fix the problems caused by the new version of the control. 

That doesn’t mean there’s no need for a debate, though. I like your ideas of ‘params’ that are forwarded to the component CSS style sheet, but it may fit better in the more global discussion about CSS Variables... and we all know this subject is not progressing as fast as authors would like.

BTW, chaining pseudo-elements is something I (and some others, too) requested for a while because it solve real-world problem.

From: Roland Steiner 
Sent: Friday, August 12, 2011 3:06 PM
To: Dimitri Glazkov 
Cc: David Hyatt ; Boris Zbarsky ; www-style@w3.org ; Tab Atkins 
Subject: Re: Overloading pseudo-elements seems bad, was: Need a better way to reach into the shadow DOM subtree
I feel that pseudo-elements for components are a bad idea anyway. They will tempt authors to use, e.g. 

    x-video::timeline > div { /* ... */ }

Such tricks, discovered by trial and error or by reading the component source, will seem to authors to allow a more fine-grained control over styling. Later, when the component is updated, sites break. IOW, if we allow this, component authors will know the fear of breaking the web.

Chaining pseudo-elements can also lead to 

    x-video::timeline::before { /* inject content here */ }

which may break the component horribly.

Fixing all that is by no means easy, and I'm not sure I have a good solution. Therefore please consider the following brainstorming rather than a well-thought-out proposal:

It seems to me that pseudo-elements for components only use a very limited subset of what makes CSS anyway - little or no inheritance, and only very few attributes. So how about using "pseudo-CSS-attributes" instead? E.g.:

    video { 
        ::timeline-color: blue;
        ::timeline-thumb-color: blue;
    }

and within the component:

    x-timeline { apply: timeline-color background-color, timeline-thumb-color ::thumb-color }

This applies the value set to ::timeline-color to the background-color attribute, and forwards the value set for the ::timeline-thumb-color attribute to the pseudo-CSS-attribute ::thumb color, to be udsed by a nested component.  

AFAICT, such an approach would have several benefits:

-) the pseudo-CSS-attribute is not bound to a single, specific element: several elements can share the same style, attributes can be split onto different elements. This also makes it easier for the component author to change the component implementation later on (e.g., not using a <input type=range> after all)

-) easy to create a component-of-components by just forwarding styles and changing names as appropriate

-) avoids the issues initially described

WDY'allT?


Cheers,

- Roland



On Thu, Aug 11, 2011 at 4:30 AM, Dimitri Glazkov <dglazkov@google.com> wrote:

  Dave, Boris,

  Tab just pointed out to me that another issue with using
  pseudo-elements is if we let developers just create their own, CSS3
  won't be able to add new pseudo-elements, paralyzed by fear of
  breaking the Web. The solutions are:

  1) Only allow developers to use a strict set of names (which seems
  deficient, because we can't really invent all names for all purposes
  here)
  2) Use some sort of a prefix
  3) Invent a different method of conveying this information, like
  part(foo) that I suggested before.
  4) <insert idea>

  :DG<

  On Wed, Apr 27, 2011 at 1:33 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
  > As of http://trac.webkit.org/changeset/85077, the restrictions on
  > pseudo-elements are relaxed and allow chaining pseudo-elements and
  > pseudo-classes at will.
  >
  > :DG<
  >
  > On Mon, Apr 11, 2011 at 12:59 PM, David Hyatt <hyatt@apple.com> wrote:
  >> On Apr 11, 2011, at 2:50 PM, Dimitri Glazkov wrote:
  >>
  >>> video::-webkit-timeline:disabled { /* ... */ }
  >>>
  >>> How do we fix this? Tab suggests a new combinator selector like:
  >>
  >> Just keep using pseudo-elements, but lift all the silly restrictions placed on them, e.g., that they have to be the rightmost selector.  The issue isn't with pseudo-elements.  The issue is with the restrictions placed on pseudo-element usage that don't need to be there.
  >>
  >> Note that WebKit already has its own pseudo-element extensions that deliberately violate this rule, e.g., all of the scrollbar parts, which support states like hover/active/disabled using rules just like what you've described above.
  >>
  >> dave
  >> (hyatt@apple.com)
  >>
  >>
  >