W3C home > Mailing lists > Public > www-style@w3.org > November 2013

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

From: Simon Sapin <simon.sapin@exyr.org>
Date: Mon, 11 Nov 2013 06:52:24 +0800
Message-ID: <52800E28.2060302@exyr.org>
To: Jirka Kosek <jirka@kosek.cz>
CC: Simon Pieters <simonp@opera.com>, www-style@w3.org, Daniel Glazman <daniel.glazman@disruptive-innovations.com>
On 10/11/2013 21:21, Jirka Kosek wrote:
>>>> 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.
> So if I understand you properly, you are proposing that ITS should
> define its own extension syntax for accessing attributes and
> implementations then should parse selector and if such syntax is used
> additional operations are made except just calling qSA()?

This was not my first suggestion. Let me go back a bit:

You’re proposing to add something to the Selectors spec to select 
attributes, with the intent to user Selector API in JavaScript 
implementations of ITS.

I’m pointing out that changing the Selectors spec is not enough, you 
would need to get the DOM spec changed as well to somehow get attributes 
(rather than just elements) out of Selector API.

I’m suggesting an alternative for JavaScript code that does not require 
changing Selector API: using it to get elements, then get attributes 
values out of these elements.

As to the ITS syntax that drives this JavaScript implementation, I 
suggested in an earlier email that the attribute name could be specified 
separately from the (element) selector.

If for some reason (?) the two must be specified in the same piece of 
string, then yes, additional syntax and parsers will be needed to 
separate them. Which is why I believe having them separately is preferable.

Simon Sapin
Received on Sunday, 10 November 2013 22:52:55 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:34 UTC