W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-87: Selectors API

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 22 Mar 2006 11:16:37 -0800
Message-Id: <32EEA4CD-C628-43F6-865C-85AA3B766067@apple.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
To: Jim Ley <jim@jibbering.com>


On Mar 22, 2006, at 5:43 AM, Jim Ley wrote:

>
> "Anne van Kesteren" <annevk@opera.com>
>> On Sat, 25 Feb 2006 19:19:16 +0100, Daniel Schierbeck  
>> <daniel.schierbeck@gmail.com> wrote:
>>> This seems like a really good idea. I'm not sure about the method  
>>> name.
>>
>> There is now:
>>
>>  .match()
>>  .matchAll()
>>
>> ... per some discussion on #webapi. Thanks for your feedback.
>
> as per later discussion on #webapi, please change these  
> names, .match is too similar to match in ES, and I would expect it  
> to take a regular expression (perfectly reasonable to run a regular  
> expression over a DOM).

1) I think it's really useful to have these names be short. The fact  
that one of the most common operations you do by the dom is called  
document.getElementById is a huge disaster. We can afford some  
imprecision in the name in exchange for brevity if this is to be a  
common idiom.

2) I don't think trying to match a regular expression against the DOM  
is very sensible. But if you did want to do it, you could convert the  
DOM to a string. It's not unprecedented for operations with the same  
name to do different things based on the type. Consider the  
difference between 2 + 2 and "a" + "a" in ECMAScript. Or consider  
Array.indexOf vs. String.indexOf. Therefore I am not convinced by  
your argument that this similarity is problematic.

> Also it's very odd to have .match() return only the first of  
> something, it should return all of them, like everywhere else the  
> name is used to avoid confusion (I'm not sure of the use case of  
> just matching one anyway, please provide - if it's scripting  
> performance, let's have a limit on the general case, because I  
> often only what the first 4 things as much as only 1, gEBI covers  
> the 1 case...)

Use case for matching one is to be able to easily operate on the  
first item when you know you have a unique match:

document.match("#header").addEventListener("click", headerClick, false);

Also, it is likely this can be done more efficiently than computing  
the whole static list and then getting the first item. I am sure  
there are other cases where a unique match is expected, such as  
looking for a specific attribute value:

document.match("iframe[name='ad-banner']").addEventListener("click",  
bannerClick, false);

I don't think the case of "first n for some arbitrary value of n" is  
common enough to be worth adding API for.

> Mainly these names say nothing about their inescapable link to  
> Selectors, they should.

Unfortunately the name document.selectNodes is taken by XPath, and  
select() would be easily confused with document.selection.

Regards,
Maciej
Received on Wednesday, 22 March 2006 19:16:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT