Re: Custom pseudo-elements collisions, was: Need a better way to reach into the shadow DOM subtree

On Oct 24, 2012 8:26 AM, "Brian Kardell" <bkardell@gmail.com> wrote:
>
>
> On Oct 23, 2012 4:01 PM, "Dimitri Glazkov" <dglazkov@google.com> wrote:
> >
> > Folks,
> >
> > I am re-visiting this -- time to add custom pseudo-elements to Shadow
> > DOM spec! -- and would like to solicit ideas/opinions on the topic of
> > collisions. Specifically, What I am trying to avoid here is collisions
> > between some widget author-invented pseudo-element name with something
> > the CSS WG invents in a future specification.
> >
> > Possible solutions:
> >
> > 1) Introduce a "::pseudo(name)" pseudo-element specifically for custom
> > pseudo-elements (Tab's idea)
> >
> > 2) Place a validity constraint on the pseudo-element value. For
> > example, it has to start with "x-".
> >
> > 3) your idea goes here.
> >
> > :DG<
> >
>

Hoorah.  Given that we have x- for custom tags and have proposed x- as the
prefix for css custom properties (formerly variables) on the list (and here
http://fremycompany.com/TR/2012/ED-css-custom/) I would definitely like to
propose "keep it simple" and make x- the standard prefix for author defined
anything in CSS (the relation to x for tags is just nice correlation for
teaching).

Brian Kardell :: @bkardell :: hitchjs.com

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