WebKit Support for the Selector API

[Richard York]

If you haven't already heard...

Seems WebKit has gone and added support for querySelector() and
querySelectorAll().

http://webkit.org/blog/156/queryselector-and-queryselectorall/

[Dean Edwards]

That's good. I don't have to change anything in base2, it'll pick it up
automatically. ;-)

-dean

[Mathieu Pillard]

A friend of mine tested it and it didn't work that well. For some
reason doing forEach() or any other method from
base2.DOM.StaticNodeList on the result of querySelectorAll() fails
with webkit. Calling item() works and binds the corresponding element
correctly though. Any thoughts?

[Dean Edwards]

Can you provide an example that fails? I haven't had any problems with
querySelectorAll() on Safari - I even tested on version 1.2!

-dean

[Dean Edwards]

Sorry, I missed the context of your comment. I assume you are using a
webkit nightly?

I guess I need to amend base2's StaticNodeList to accommodate a *real*
StaticNodeList!

base2 was not quite so future-proof as I thought. :-(

I'll look into this...

-dean

[Mathieu Pillard]

On 11 fév, 17:15, Dean Edwards <d...@edwards.name> wrote:
> Mathieu Pillard wrote:
> > A friend of mine tested it and it didn't work that well. For some
> > reason doing forEach() or any other method from
> > base2.DOM.StaticNodeList on the result of querySelectorAll() fails
> > with webkit. Calling item() works and binds the corresponding element
> > correctly though. Any thoughts?
>
> Sorry, I missed the context of your comment. I assume you are using a
> webkit nightly?

Yes; querySelectorAll() was returning correct results, but I couldn't
use them fully since it returned a native StaticNodeList. Not 100%
sure since it wasn't my machine and I can't test myself atm, though.

[Dean Edwards]

I'd like to check this out myself but I can't get the webkit nightly to
run on Windows and my Mac is too ancient. :-(

-dean

[Alex Robinson]

>> Yes; querySelectorAll() was returning correct results, but I couldn't
>> use them fully since it returned a native StaticNodeList. Not 100%
>> sure since it wasn't my machine and I can't test myself atm, though.
>
>I'd like to check this out myself but I can't get the webkit nightly to
>run on Windows and my Mac is too ancient. :-(

http://www.fu2k.org/alex/javascript/javascriptjunk/base2-staticnodelist-foreach

Works fine in everyhting other than the latest version of WebKit :(

>>>
line 12
Value undefined (result of expression
document.querySelectorAll("p").forEach) is not object.
<<<

At 16:15 +0000 11/2/08, Dean Edwards wrote:
>I guess I need to amend base2's StaticNodeList to accommodate a *real*
>StaticNodeList!

Presumably this means that anything else that gets patched and
amended (like your addClass sugar) will also fail.

Might it be an idea to extend the HTMLElement prototype directly if
the native querySelect is detected?

[Dean Edwards]

Alex Robinson wrote:
>>> Yes; querySelectorAll() was returning correct results, but I couldn't
>>> use them fully since it returned a native StaticNodeList. Not 100%
>>> sure since it wasn't my machine and I can't test myself atm, though.
>> I'd like to check this out myself but I can't get the webkit nightly to
>> run on Windows and my Mac is too ancient. :-(
>
>
> http://www.fu2k.org/alex/javascript/javascriptjunk/base2-staticnodelist-foreach
>
>
> Works fine in everyhting other than the latest version of WebKit :(
>
> line 12
> Value undefined (result of expression
> document.querySelectorAll("p").forEach) is not object.

Bah! It's pretty easy to fix. base2's StaticNodeList object can wrap
anything that contains nodes. I just need a way to test it. :-(

Anyone got a clue how to get WebKit nightly to run on Windows? I've
tried and failed several times.

-dean

[Alex Robinson]

>Bah! It's pretty easy to fix. base2's StaticNodeList object can wrap
>anything that contains nodes. I just need a way to test it. :-(
>
>Anyone got a clue how to get WebKit nightly to run on Windows? I've
>tried and failed several times.

No. But send the updated code to me and I'll give it a go. ;)

[Richard York]

That's because static node lists don't work with the new enumeration
methods.

I thought this was a bug too, but the devs are saying this is
intended.

http://bugs.webkit.org/show_bug.cgi?id=17296

But they might be persuaded to add those methods. I hope that they
do, because I think that's really useful.

[Mathieu Pillard]

On 11 fév, 19:34, Richard York <richy...@gmail.com> wrote:
> That's because static node lists don't work with the new enumeration
> methods.
>
> I thought this was a bug too, but the devs are saying this is
> intended.
>
> http://bugs.webkit.org/show_bug.cgi?id=17296
>
> But they might be persuaded to add those methods. I hope that they
> do, because I think that's really useful.

Even if Webkit supported the enumeration methods, it would still fail
in some cases wouldn't it? The elements wouldn't be binded...

[Richard York]

Webkit does natively support the enumeration methods.

[powrsurg]

On Feb 11, 11:54 am, Dean Edwards <d...@edwards.name> wrote:
> Alex Robinson wrote:
> >>> Yes; querySelectorAll() was returning correct results, but I couldn't
> >>> use them fully since it returned a native StaticNodeList. Not 100%
> >>> sure since it wasn't my machine and I can't test myself atm, though.
> >> I'd like to check this out myself but I can't get the webkit nightly to
> >> run on Windows and my Mac is too ancient. :-(
>

> >http://www.fu2k.org/alex/javascript/javascriptjunk/base2-staticnodeli...

>
> > Works fine in everyhting other than the latest version of WebKit :(
>
> > line 12
> > Value undefined (result of expression
> > document.querySelectorAll("p").forEach) is not object.
>
> Bah! It's pretty easy to fix. base2's StaticNodeList object can wrap
> anything that contains nodes. I just need a way to test it. :-(
>
> Anyone got a clue how to get WebKit nightly to run on Windows? I've
> tried and failed several times.
>
> -dean

Just extract download the latest nightly from http://nightly.webkit.org/
and extract the files to a directory. From there click on run-nightly-
webkit.cmd.

You might need a copy of the latest non-nightly installed before you
do. Also, you may see it mention something about copying files over. I
believe the copy is only done once. You used to not be able to close
the command window it opens else it will close Safari, but the latest
nightly still worked after I closed it so this may no longer be an
issue.

[Mathieu Pillard]

On 11 fév, 19:59, Richard York <richy...@gmail.com> wrote:
> Webkit does natively support the enumeration methods.

Yes. But that's not what I meant: any element returned by
querySelector() with base2 is "binded" and can use the methods base2
adds to HTML elements. Even if webkit supported the enumeration
methods on staticnodelists, that wouldn't change the heart of the
problem: the elements in the staticnodelist wouldn't be binded, would
they? (It's difficult to test for me at the moment)

[Alex Robinson]

At 11:25 -0800 11/2/08, Mathieu Pillard wrote:
>On 11 fév, 19:59, Richard York <richy...@gmail.com> wrote:
>> Webkit does natively support the enumeration methods.

Yes. On Arrays. Not on StaticNodeLists. I presume
that this is their considered judgement as to
what the new specs call for.

I don't think you'll be able to persuade WebKit
to add the enumeration stuff to StaticNodeList
unless you've persuaded the relevant javascript
WG first ;)

>Yes. But that's not what I meant: any element returned by
>querySelector() with base2 is "binded" and can use the methods base2
>adds to HTML elements. Even if webkit supported the enumeration
>methods on staticnodelists, that wouldn't change the heart of the
>problem: the elements in the staticnodelist wouldn't be binded, would
>they? (It's difficult to test for me at the moment)

That's what I was getting at when I wrote:

<<<
Presumably this means that anything else that gets patched and
amended (like your addClass sugar) will also fail.

Might it be an idea to extend the HTMLElement prototype directly if
the native querySelect is detected?
<<<

Now, if WebKit is correct and the specs don't
call for enumeration methods on StaticNodeLists,
then the correct solution is probably to remove
the support in Base2.DOM.

After all, the primary concern of Base2.DOM is to
get all browsers in line and behaving according
to the standards. (Dean?)

But yes, I hope to god, that these methods are added....

[Richard York]

I understand what you were saying with binding.

I was just saying that webkit does support those methods natively,
though albeit not on the quoteSelector/All methods. At least not yet.

[Dean Edwards]

Alex Robinson wrote:
> Now, if WebKit is correct and the specs don't
> call for enumeration methods on StaticNodeLists,
> then the correct solution is probably to remove
> the support in Base2.DOM.
>
> After all, the primary concern of Base2.DOM is to
> get all browsers in line and behaving according
> to the standards. (Dean?)
>
> But yes, I hope to god, that these methods are added....

I think the enumeration methods are too nice to leave out, also, we need
a mechanism to apply bindings as Mathieu pointed out.

This shouldn't be too difficult to fix. base2's StaticNodeList is just a
wrapper for an array of nodes or an XPath result. It can easily wrap a
*real* StaticNodeList.

I just need to be able to test it. :-)

Are people in a hurry for this change or is it just academic interest?

Whilst we are on the subject:

http://www.whatwg.org/specs/web-apps/current-work/#domtokenlist

I plan to replace the addClass/removeClass/etc methods with the HTML5
classList object. Anybody against this idea?

-dean

[Richard York]

> I don't think you'll be able to persuade WebKit
> to add the enumeration stuff to StaticNodeList
> unless you've persuaded the relevant javascript
> WG first ;)

Standards are good and all, but sometimes the standards committees
seem to have their heads stuck up their asses too. This current way
of accessing elements with static node lists makes no sense. What's
the point of these useful enumeration methods if they don't work with
this nifty API?? Isn't that why JavaScript libraries came about, to
make development easier? That's what I use those enumeration methods
for 99% of the time, traversing of element nodes returned by
querySelector/All.

Also, I think the webkit devs are willing to listen, I got that
impression at the very least. Their recent work makes me think that
they value and listen to web developers. But I also think they need
to hear compelling use cases. Sometimes implementations change the
standards. We saw that with CSS 2, and are seeing it now with HTML
5. The Selectors API is a pretty green standard, and Webkit being the
first to implement it will be in the position of providing feedback to
the editors on what they think works and doesn't work in that
implementation, and that standard as a result, will improve.

It won't change if no one complains or asks for new features, and
everyone accepts what they give us verbatim.

> Now, if WebKit is correct and the specs don't
> call for enumeration methods on StaticNodeLists,
> then the correct solution is probably to remove
> the support in Base2.DOM.

No, don't do that. The enumeration methods aren't in any standard.
They are an extension dreamed up by Mozilla, and now also implemented
in Webkit. Again, standards more often than not come from
implementations and feedback, rather than by committee.

[Dean Edwards]

Richard York wrote:
> The Selectors API is a pretty green standard, and Webkit being the

> first to implement it...

Ahem. base2 was the first to implement. ;-)

-dean

[Alex Robinson]

>I think the enumeration methods are too nice to leave out, also, we need
>a mechanism to apply bindings as Mathieu pointed out.

Gah! /aol me too!

>Are people in a hurry for this change or is it just academic interest?

I think it's academic until this version of WebKit hits the streets.
Given all the recent additions I think we can safely assume that this
is not super imminent.

>Whilst we are on the subject:
>
>http://www.whatwg.org/specs/web-apps/current-work/#domtokenlist
>
>I plan to replace the addClass/removeClass/etc methods with the HTML5
>classList object. Anybody against this idea?

One of the things that I like about the removeClass and hasClass
implementations in Base2 is that (whether they're meant to or not) is
that they allow for regexes to be used. Does the DOM token list allow
for this? My head just starts to spin reading through stuff about
tokenisation...

[Richard York]

My apologies to you sir... yes, certainly, you are right, and what a
fine implementation it is. :-)

[Dean Edwards]

Alex Robinson wrote:
>> http://www.whatwg.org/specs/web-apps/current-work/#domtokenlist
>>
>> I plan to replace the addClass/removeClass/etc methods with the HTML5
>> classList object. Anybody against this idea?
>
>
> One of the things that I like about the removeClass and hasClass
> implementations in Base2 is that (whether they're meant to or not) is
> that they allow for regexes to be used. Does the DOM token list allow
> for this? My head just starts to spin reading through stuff about
> tokenisation...

The classList functions will work in exactly the same way.

I'm keen to add support for this. That only leaves the previously
discussed matchesSelector() method as being non-standard. Everything
else in base2.DOM has been specified by the W3C or WHATWG.

-dean

[Richard York]

I'm not opposed to the update. I think it's just collateral damage
for trying to be forward-compatible with emerging standards.

But I do have a lot of code written already that relies on that old
API, so just speaking for myself, I'd just want to have an idea of
when it will land so I can make updates.

When do you think the update will land in SVN?

[Dean Edwards]

powrsurg wrote:
> Just extract download the latest nightly from
> http://nightly.webkit.org/ and extract the files to a directory. From
> there click on run-nightly- webkit.cmd.

I always get an error when I run that:

> The syntax of the command is incorrect. '"C:\Documents and
> Settings\DEAN~1.93F\LOCALS~1\Temp\run-webkit-nightly2.cmd"' is not
> recognized as an internal or external command, operable program or
> batch file.

Any ideas?

> You might need a copy of the latest non-nightly installed before you
> do.

I have the latest beta is that good enough?

-dean

[Dean Edwards]

Richard York wrote:
> I'm not opposed to the update. I think it's just collateral damage
> for trying to be forward-compatible with emerging standards.
>
> But I do have a lot of code written already that relies on that old
> API, so just speaking for myself, I'd just want to have an idea of
> when it will land so I can make updates.

Don't worry, I've already written a little function that will add the
old methods back if needs be. Untested, but looks something like this:

with (base2) with (JavaScript.Function2) with (DOM) {
ClassList.forEach(function(method, name) {
HTMLElement[name + "Class"] = bind(method, ClassList);
});
}

I will always try to provide an upgrade path if I make changes to the
API. The trouble is that a lot of the specs I'm implementing are in a
state of flux themselves. Witness the Selectors API naming debacle. I
have a JSON library that I'm holding back because the ES4 editors can't
make up their minds.

> When do you think the update will land in SVN?

Not for at least two weeks.

-dean

[Alex Robinson]

>The classList functions will work in exactly the same way.

Phew. Most excellent.

>I'm keen to add support for this. That only leaves the previously
>discussed matchesSelector() method as being non-standard. Everything
>else in base2.DOM has been specified by the W3C or WHATWG.

I totally support this move Dean. Anyone who is using base2 should be
linking to one of the beta versions (if not local code) rather than
the working copy and so addClass etc will stay supported for them
(ok, me ;) until they choose to upgrade.

[timothytoe]

I have nothing but trouble when I try to run webkit nightly on the PC.
Usually crashes the first time I run the script, then runs the old
Safari instead of the new Webkit hotness.

When I run the included debugger, I get nothing, or it freezes the
browser.

Tried on Vista and XP.

Seems like a hackful of crap to me. Allegedly, the JavaScript is
really fast. I may eventually try it on the Mac. Is Tiger enough, or
do I need Leopard?

On Feb 11, 2:12 pm, Dean Edwards <d...@edwards.name> wrote:
> powrsurg wrote:
> > Just extract download the latest nightly from

> >http://nightly.webkit.org/and extract the files to a directory. From

[Bruce Walker]

On Feb 11, 2:49 pm, Dean Edwards <d...@edwards.name> wrote:
>
> This shouldn't be too difficult to fix. base2's StaticNodeList is just a
> wrapper for an array of nodes or an XPath result. It can easily wrap a
> *real* StaticNodeList.
>
> I just need to be able to test it. :-)
>
> Are people in a hurry for this change or is it just academic interest?

Well, I'm in a bit of a hurry myself: I'm trying to deploy a contest-
voting page using your code this weekend. :-)

So far, base2 is the only solution to fixing my cross-browser woes.
I'm trying to marry the Yahoo Media Player with some AJAX code and
have it work under the usual browser suspects (IE, Firefox, etc.).

I'd be happy to test your fixes in my environment. I have the Apple
Developer WebKit seed installed in Mac OS X Leopard (Intel).

Thanks!

[Mathieu Pillard]

On 11 fév, 16:10, Mathieu Pillard <diox...@gmail.com> wrote:
> A friend of mine tested it and it didn't work that well. For some
> reason doing forEach() or any other method from
> base2.DOM.StaticNodeList on the result of querySelectorAll() fails
> with webkit. Calling item() works and binds the corresponding element
> correctly though. Any thoughts?

Replying to myself: IE8 Beta1 is out. It implents querySelectorAll()
too. And it seems to fail the same way :-)

--
mat

[Dean Edwards]

I've fixed this in the trunk. Will update the libs soon.

-dean

[Mathieu Pillard]

> I've fixed this in the trunk. Will update the libs soon.

Cool, thanks. Now for the trickier part: IE8 implements
querySelector(), but not all CSS3 selectors. So if you add code to use
the native querySelector implemented in IE, that will probably break
some code relying on those CSS3 selectors IE8 doesn't implement
(like :not())....

[Dean Edwards]

That's fixed too.

-dean

[Anthony Ricaud]

Now that Safari 3.1 is available, there's one browser supporting the
Selector API so there's a real need for a fix. Any update soon ?

Thanks.

[Dean Edwards]

Anthony Ricaud wrote:
> Now that Safari 3.1 is available, there's one browser supporting the
> Selector API so there's a real need for a fix. Any update soon ?
>

OK. I will release a new version as soon as possible.

-dean