Re: ITS 2.0, Selectors 4 and Selectors API 2

On Mon, Jul 1, 2013 at 11:53 PM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> On 02/07/13 04:46, Tab Atkins Jr. wrote:
>> That's already the case - the subject indicator has to precede the
>> compound selector.
>
> Tab, I know, *I* designed the subject indicator *exactly* the way it
> is in the spec back in *1997* in a language called STTS and an
> application implementing it...
>
> I meant !foo![attr] is forbidden.

Yes, I was just saying that that is already forbidden.

>> 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.
>
> Unacceptable to you. And pseudo-elements can be selected by CSS without
> having any existence as Nodes in the document tree...

Pseudo-elements do exist in the document tree as far as layout is
concerned.  Selectors can indeed augment the tree.

> ![foo] refers to an element *for the time being* in a Draft. "A
> Standard is not a Standard before it's published as a Standard". And
> Selectors are a selecting mechanism, the CSS case being one particular
> case only. ITS proves Selectors are used outside of the CSS world.

No, "[foo]" refers to an element, period, in Selectors all the way
back to 2.1 or earlier, and "[foo]" and "*[foo]" match exactly the
same elements.  The subject indicator doesn't change the meaning of
anything, just which element is finally selected.  Thus, "![foo]"
matches the same thing as "!*[foo]".  (And "*![foo]" is illegal, but
even if we allowed it for some reason, it would still be the same as
"!*[foo]".)

> The question is the following one: do we want Selectors to become a more
> generic mechanism approaching, and possibly eventually replacing, the
> power of XPath? If I look at all the additions to Selectors lev4, the
> answer is obviously yes. And if you ask me, yes, we should make CSS
> a selecting mechanism widely usable in full replacement of XPath.
> FWIW, please see the section on STTS in Håkon's thesis and its ACK
> section.

I'm not saying we shouldn't.  Just that you shouldn't do it by
smuggling in the functionality via two unrelated things.  You should
introduce something that actually selects an attribute.

(Though, some of the things that XPath does don't agree well with
Selector's data model, and vice versa.  Achieving a full superset
would be rather difficult.)

>> I am strongly against Selectors returning different results when used
>> in CSS versus qSA/find.
>
> I never said that. I said a p![foo] would select an attribute in both
> querySelectorAll() and CSS, but it would not trigger any style in CSS.
> We already have similar mechanisms in CSS, with restricted sets of
> properties applicable to pseudo-elements.

I'm not necessarily against the concept of selecting attributes; I'm
arguing against your attempted abuse of syntax.  ^_^

~TJ

Received on Tuesday, 2 July 2013 07:17:08 UTC