Re: ACTION-87: Selectors API

"Maciej Stachowiak" <mjs@apple.com>
> On Mar 22, 2006, at 6:45 AM, Jim Ley wrote:
>> "Anne van Kesteren" <annevk@opera.com>
>>> Fair enough, here are the requirements for the name:
>>>
>>> * short
>>> * simple
>>
>> Why are these requirements for the name, no other DOM names are  short 
>> and simple, they're clear and unambiguous,
>
> And that's why so much code is done with DOM Level 0 instead,

No, almost everything is done with the lowest possible DOM level that meets 
the use case, and it will continue to do so, anything else is crazyness, not 
least because the only versioning capability the W3 has given scripters is 
the ludicrous hasFeature.

It's also the correct behaviour, stick with the oldest and most reliable.

> it's important for common operations to have simple names.

I think that's rubbish, I see scripters having no problems with the length 
of names, they're mostly confused about the what methods actually do - I 
think you're reading too much into the minority library blogging scripts, 
and spending little time with large scale scripting projects in commercial 
environments.

> It seems preferrable to have the single-item version be a shorter 
> expression than the multi-match. I do think the 1 case is  significantly 
> different from the N case, because in the single-item  case you won't 
> loop, you will just want to do your processing directly.

That's an optimisation for the User Agent to make, not the scripter, the 
limit 1 will specifically allow the script author not to loop, just like 
using match.

> Furthermore, the name  "selectNodes" for a function that matches against 
> an XPath expression  seems accepted, even though it says nothing about 
> XPath in the name.

Accepted where?  It's certainly not accepted by me, however the existing 
implementation carries weight - which is why I'd be somewhat willing to 
accept the getElementsBySelector as at least there is one implementation.

Cheers,

Jim.

Received on Thursday, 23 March 2006 02:25:46 UTC