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)
> >>
> >>
> >
>
>