You can find me here.

There is one problem with the web at the moment and one problem only: the dysfunctional behaviour between browser vendors and standards writers (and the fact that most of the time they are one in the same).

We need to get the EU to thump Microsoft a lot harder. Compatibility through turning on a true standards mode by default is great, but what about getting up to speed with standards support? Where is border-radius? Where is support?

There is one problem with the web at the moment and one problem only: the dysfunctional behaviour between browser vendors and standards writers (and the fact that most of the time they are one in the same).

We need to get the EU to thump Microsoft a lot harder. Compatibility through turning on a true standards mode by default is great, but what about getting up to speed with standards support? Where is border-radius? Where is support?

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.