On Mon, Jul 1, 2013 at 5:53 PM, Daniel Glazman <daniel.glaz...@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
