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.

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.

Did you include the libraries he’s referring to and wrap the code into a function to run on page load?

The only thing I would say is be careful when using for..in loops as they don’t work as you expect on arrays. I am sure Kevin knows this, but non-experts may not :)

Should these libraries limit themselves to standards compliance? No. Should they embrace and extend standards? Certainly.

I agree with Jon, how is this going too far? If you take a look back at the history of the internet its chock-full of people pushing the edge, going beyond the standards.

JavaScript originally was only a Netscape thing, now its grown to something that all major browsers, and quite a few non-major browsers, support.

10 yrs ago, Flash was virtually unheard of, look at it now.

I say, let them add extra selectors, let them help to make our jobs easier. Each browser has its own set of extras, IE supports ‘‘, Mozilla ignores it, Mozilla has a few extra CSS goodies as well ‘-moz-box-sizing’ for instance, while IE ignores it.

“Obviously, when browsers support the Selectors API (Safari and IE8 beta 1 already do!), their native implementations will run faster than anything a JavaScript library can do.”
Will they support it fully? They still haven’t caught up with CSS2 and CSS3 is in the works. Will they run those selectors faster? Maybe, but they are becoming so bloated that I’m surprised if they run anything faster.

Fully supporting standards is one thing, limiting yourself to them is another thing altogether.

Because that’s what jQ does for me… if what you’re saying is that IE8 and Safari are now totally and harmonically compatible between each other as regards javascript interpretation, then I guess soon I won’t need to use it any more.