W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [selectors-nonelement] First draft of a new spec for selecting non-element nodes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 17 Feb 2014 18:41:29 -0800
Message-ID: <CAAWBYDDFeHKGniSqnEeiQPsXO+B+i+CZVn=A+p67AvFb3Vr3pw@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style list <www-style@w3.org>
On Mon Feb 17 2014 at 10:56:57 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> On Mon, Feb 17, 2014 at 8:02 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> > On Sat, Feb 15, 2014 at 8:47 PM, Andrew Fedoniouk
> > <news@terrainformatica.com> wrote:
> >> Otherwise we need to mention cases like this:
> >>
> >>   input[type="number"]::attr(type) { content:"text" }
> >>
> >> etc.  Either we need to treat ::attr() as first-class pseudo-elements
> >> or left them shine in DOM methods or libraries like jquery.
> >
> > I did mention that, when I said that ::attr() pseudo-elements never
> > generate boxes.  Thus "content: 'text';" has no effect on them.
>
> I can read this
>
>   input[type="number"]::attr(type) { content:"text" }
>
> as: for any input element with type="number"
> change used value of 'type' attribute to 'text'.

I'm not sure how you'd read it like that.  The 'content' property has
never meant anything like that, at any point in its history.

> > They *are* first-class pseudo-elements.  Pseudo-elements don't need to
> > generate boxes to "exist".
> >
> > DOM methods that evaluate selectors don't currently allow
> > pseudo-elements.  When they do, they'll do so in a generic way that
> > reflects ::attr() pseudo-elements as well.
> >
>
> 1. Attribute/text/comment DOM nodes are not pseudo-elements, these
>     are physical objects.

You may want to rephrase that - they're certainly not "physical".

The point is that they're not *elements*.  The CSS data model, as it
currently exists, only knows about elements, and pseudo-elements.  We
could extend this, but for now it seems simpler and clearer to fit
attributes into the existing model.

> 2. Attribute/text/comment selectors, when used, can appear only at rightmost
>     position in "dom-selectors".
>
> 3. *CSS selectors* module should just declare some
> delimiter/combinator like '->'
>     and say that any selector that contains it is out of CSS selectors scope -
>     *it does not match anything for CSS purposes*.
>
> 4. That new DOM node selectors module should include reference to CSS selectors
>     module as element selection part and its own syntax for part on the right
>     of '->'.

I don't think we'll ever add new ASCII combinators at this point, now
that we are agreeing on a mechanism for named combinators.

When we handle text, we'll do it properly, as they *are* subject to
CSS - text certainly gets styled, though only by inheritance.  It'll
probably be done through pseudo-elements as well.

We'll handle comments/PIs/whatever when there's a use-case.

~TJ
Received on Tuesday, 18 February 2014 02:42:17 UTC

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