W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Proposed Specification for find/findAll/matches

From: Yehuda Katz <wycats@gmail.com>
Date: Tue, 13 Dec 2011 21:53:19 -0800
Message-ID: <CAMFeDTXcTgjb1X+W-YfGcX4q1KRdQh4=mjgGumRGuCPhoScfYg@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
This proposal looks really good and matches my expectations.

Yehuda Katz
(ph) 718.877.1325


On Tue, Dec 13, 2011 at 3:53 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au>wrote:

> On 2011-12-12 17:57, Boris Zbarsky wrote:
>
>> On 12/12/11 6:07 AM, Lachlan Hunt wrote:
>>
>>> Given a selector list as input to the method, trim whitespace and then
>>> for each complex selector, run the first step that applies:
>>>
>>> (Note: if the selector list is "", then there are 0 complex selectors in
>>> the list and the following doesn't run)
>>>
>>> | 1. Otherwise, if the complex selector begins with any combinator
>>>
>>
>> This needs to be defined better. "complex selector" can't begin with a
>> combinator, per its definition.
>>
>
> For the purposes of this API, I think the spec needs to define a modified
> syntax for a DOM Selector, which is similar to, but slightly different from
> a regular selector. The grammar production would be:
>
> dom_selectors_group
>  : dom_selector [ COMMA S* dom_selector ]*
>  ;
>
> dom_selector
>  : [ combinator ]? selector
>  ;
>
> Where the productions for "combinator" and "selector" are defined in
> Selectors.  The spec would then define that the parameter accepts a group
> of DOM selectors that matches that grammar.
>
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
>
Received on Wednesday, 14 December 2011 05:54:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT