Re: ITS 2.0, Selectors 4 and Selectors API 2

On Mon, Jul 1, 2013 at 5:53 PM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
>   1. only one subject indicator is allowed per compound selector

That's already the case - the subject indicator has to precede the
compound selector.

>   2. the subject indicator can precede a universal selector (potentially
>      omitted), a type element selector or an attribute selector. In the
>      case of an attribute selector, the selector represents then the
>      attribute node matching the condition expressed by the attribute
>      selector. Note: all @foo attributes of the document is not ![foo]
>      - that means !*[foo] - but *![foo]

This is unacceptable for Selectors applied against HTML in general.
Attributes are *not* nodes, either in HTML or XML, and "![foo]" refers
to an element.

Against an arbitrary document language where attributes are translated
into a tree in a different manner, it would work.

>   3. both Selectors and Selectors API should allow such attribute
>      matching, but CSS rules with such attribute matching would of
>      course not trigger any style resolution. querySelectorAll() and
>      friends should be extended to return attribute nodes. The case
>      of a group of selectors where one of the selectors uses a subject
>      indicator to match attributes has to be discussed but I think it's
>      doable.

I am strongly against Selectors returning different results when used
in CSS versus qSA/find.

If you want Selectors to be able to select attribute nodes, address it
directly with a new selector.  This should not be smuggled in via the
subject indicator.

~TJ

Received on Tuesday, 2 July 2013 02:47:29 UTC