Re: [selectors4] Proposal for extending Selectors Level 4 with possibility to select attributes

On 10/11/2013 19:42, Jirka Kosek wrote:
> [...] So restricting selectors and related APIs only to return
> elements is shortsighted -- selectors operate on DOM and all reasonable
> types of DOM nodes should be supported.

Why?

(CSS) Selectors are fundamentally about elements, not arbitrary DOM 
nodes. In http://www.w3.org/TR/css3-selectors/#abstract :

     Selectors define the following function:

         expression ∗ element → boolean

     That is, given an element and a selector, this specification
     defines whether that element matches the selector.

You’re proposing to change this, but your argument here seems to be that 
we should because we should.


>> Additionally, Attr is not a Node anymore and therefore can not be part
>> of a NodeList. (Note in [1] the lack of interface inheritance compared
>> to [2].)
>>
>> [1] http://dom.spec.whatwg.org/#attr
>> [2] http://dom.spec.whatwg.org/#element
>
> Hmm, those living standards -- one can't track all of them during single
> life :-)

If you are so inclined, this also exists in the REC-track:

http://www.w3.org/TR/domcore/#attr


> DOM has many issues. I'm not sure that stopping inheriting Attr from
> Node will save us.
>
>> Today you can already use these API to select elements, then use
>> .getAttribute()
>
> You are not getting my point. What is needed is a simple high level
> declarative query language for selecting nodes from HTML document.
> Calling additional DOM method doesn't bring here anything else.

My point is that calling .getAttribute() can be an implementation detail 
of the in-browser ITS implementations that you were talking about, 
independently of what the ITS syntax looks like.


>> How would the APIs work with your proposal?
>
> They will return node or sequence of nodes -- I'm neither JS nor WebIDL
> expert so I will left this exercise to others. With the old status where
> Attr was inherited from Node already existing NodeList can be used.

This is not the direction that the DOM spec seems to be taking, and this 
working group is not the one you need to convince about reverting 
changes made to DOM.

-- 
Simon Sapin

Received on Sunday, 10 November 2013 13:02:35 UTC