IMO the libraries take make the best of both worlds. For extended css selectors javascript will be used for standard css selectors the new api can be used.

So either way it’s a win-win.

In jQuery you don’t even need the each, could just do
$('a[rel~=external]').click(function(e){ open(this.href); e.preventDefault(); });

:)

And about selectors: if JavaScript was emerged to browsers only for sake of doing what ony those particular browsers can do, there wouldn’t be so much hype about that. JavaScript extends browser capabilities, nothing less. Why should we care if IE supports CSS3 selectors API, if we use a selected cross-browser JS library. It was written to extend the possibilities, not to wrap them in yet another layer. So, I use what I use, take benefit of it’s powers and don’t care if it is standard in any part. It just works. It’s a job of library author to follow standards in his code, not mine, I follow standards only in my part. Separation that is. Good practice, I think.

What Alex was saying is that by only supporting valid selectors, it’s a lot easier to flip the switch from custom to native selector engines, without having to fork based on each selector, which helps keep code lean and concise. But complaining about Alex’s explanation for why Dojo chooses to do this, because of the way the author created this story is a bit unfair to Alex. He was simply explaining why Dojo took this route (to make it easier to support the coming native engines).

1) I don’t understand the promotion of using for/in for array enumeration.

You’re absolutely right, and I’ve amended the code to use for loops instead.

2) Redeclaring variables in each iteration is quite redundant.

This causes no overhead, and keeps the code tidy.

3) href != null is redundant as well.

Not so. In Internet Explorer, an <a name="…"> tag’s href property is undefined, while all other browsers return an empty string. A typeof check is therefore inadequate.

4) “[href]” selector matches empty attributes, so there’s no need to test for length > 0

I don’t know what you mean here. The test for href.length > 0 doesn’t appear in the same example as the [href] selector.

4) rel != null && /(^| )external( |$)/.test(rel) could be replaced with /external/.test(rel) as “test” works just fine with any falsy values.

The rel attribute is a space-separated list of values. Thus the need for the more complicated regular expression.

Wow, the worst post about JavaScript I saw in a long time. I use MooTools, I love JavaScript code, but what you wrote here is blasphemy. Its not only bad code but bad advices. Read better books about DOM Scripting.

I have to laugh at this comment. Harald you do actually realise that Kevin WROTE one of the books on that list? :-D

I was just pointing out how things are. for .. in does not work the way it’s been used in the post. Clearly the author didn’t even bother testing anything. I find it most unfortunate that SitePoint’s once top-quality blogs have become like this.

So I don’t understand what exactly Dojo’s Alex Russell mean to say! Did he mean that making a check in the javascript function to see if the browser by default supports selector query or not is impossible or too hard? Did he mean that its impossible to check if browser supports the functionality natively or not & then use browser’s call(if it supports) else use the library’s own engine! If he means that then I think that’s enough said & I will not consider Dojo at all if these kind of developers make that framework!

I think what he skipped over is that the reason why people like prototype & jQuery etc. is that these are quite lightweight & by default come as no-frills libraries! The developer working on them can then add on top of them whatever frills (s)he wants but Dojo is one beast that’s quite slow & comes with all the bells & whistles by default that not everyone might want!!

1) I don’t understand the promotion of using for/in for array enumeration.
2) Redeclaring variables in each iteration is quite redundant.
3) href != null is redundant as well.
4) “[href]” selector matches empty attributes, so there’s no need to test for length > 0
4) rel != null && /(^| )external( |$)/.test(rel) could be replaced with /external/.test(rel) as “test” works just fine with any falsy values.

I don’t mean to sound offensive, but giving such examples to novice javascripters doesn’t sound like a good idea.

Cheers,
kangax

It’s a similar situation as forgetting about browser sniffing when coding. That annoying question is hardcoded into the Javascript library. No problem.