mkmcdonald

Browser elitism benefits no one. The user is left insulted, and the developer strokes their own ego.

> [...] the onus is on us as web developers to encourage [him/her] (in positive ways) to upgrade - through better web applications that require new features, better communicating the reasons for upgrading, etc.

I disagree. The onus is on those peddling the product (i.e. marketers) to sell its worth to users.

> Believe me when I say that I understand the frustrations that come from having to support outdated browsers

I read about “frustration” when referring to older browsers a lot. That has led me to question just how much people learn about supporting those browsers. Shouldn't supporting browser X become trivial once a certain amount of experience is accrued? Or do we just hunt and peck until a page ostensibly works?

> There isn't enough information in the original post to determine if the last one (auto-update occurring despite being turned off) is what happened here - I'd like to learn more. It would be worrying (and I'd argue an insecure design) if the software were even capable of self-updating with that setting turned off.

As someone who tests every whole number version of Firefox (1-14), I have experience with the force-fed updates. Imagine my frustration when viewing the version information (via Help > About) led to the browser paving over my existing installation. I really don't want to have to tinker with the settings for fourteen separate programs.

Conversely, Opera 8+ will ask before updating. Though this happens every time I open the program, I can easily decline and continue with my business. This is how to respect users.

Chrome is far worse, as it forbids the existence of an older build, even after the newer build is uninstalled.

You've been misled into thinking that you need features X, Y and Z. Web pages can be functional without flashy new features.

Your browser is your choice, and we as developers need to respect that.

UserAgent sniffing and Graceful Degradation do not mesh.

This sniffing in particular will fail for Opera 6-8, therefore excluding perfectly capable browsers by a very shallow criterion.

The sniff serves no purpose, and is furthermore based upon a thoroughly disproved anti-pattern.

Oddly enough, I was working on a similar problem earlier today.

I've found that collecting the Text nodes and returning them in an Array is preferable. All it requires is some simple traversal. The developer (that should know what text goes where) can then map text to nodes.

> I find that naming things descriptively and an 80 character limit are at odds.

I don't. I use descriptive names for functions and short, concise words for variables (sometimes clear abbreviations).

> Another nit, Google Style guides disallow formatting for readability except for comments?!?!

> Allowed

> [regularly formatted variable declarations]

> Not allowed

> ["pretty" formatted variable declarations with indentation]

Code Complete 2 explicitly discourages the latter style, and I tend to agree. It's too difficult to maintain.

I'm pleased that someone else favours a sensible line limit.

I stick to 72 columns for width and 20 lines per function body. The result has been very concise code that's easy to follow. Only exceptional cases such as heavy recursion have eluded the line limit.

If popular JavaScript projects wrote code with cleanliness in mind, maybe more people would take the language seriously.

I much prefer "responsive" Web pages to "mobile" sites. Many "mobile" sites cram way too many flashy graphics and bloated scripts into the client; compound that with features that disable zooming, and you have a UI disaster. Finally, don't forget URL fragmentation because of the "m.inane.com" nomenclature. "mobile" users then link "desktop" users to the "mobile" site, which is unnecessary.

Nonetheless, we're probably both guilty of selection bias.

> Web technology is great for many things. Replicating a native app experience is not one of them.

Yep.

The client-side environment is far too unstable to build a "native app". There's a reason why monumental frameworks like ExtJS barely work in IE 9.

You do realize that IE 10 dropped conditional comments, right?

I'll play the cynic here and try to diagnose why this is even being considered.

jQuery is a very invasive API. Its goal is to steal all the work from the developer, and to "guarantee" what it deems to be "correct" input for a certain subset of browsers. This approach may ostensibly work, but inevitably falls apart, which leads to thousands of "bugs" being reported.

Because the API has grown to be so massive, goalposts "must" be moved in order to create a lighter API. Once again, this is because of a design flaw. Goalposts will continue to be moved in cyclical fashion unless an alternative design is used. Fellow developers may denigrate me for it, but I will explain how this problem can be avoided.

An API that tries to cater to everyone cannot and will not succeed. This is evidenced by the upcoming "fork". Conversely, an API that provides a set of tools to developers without catering can work in many environments. The burden is then placed upon the developer to choose which environments matter. As has been outlined by mobile developers, object inferences for IE 6 really are unnecessary for mobile Webkit environments. I have written here on this concept before, mostly on the topic of "graceful degradation". Browser specificity can and will kill a client-side API.

The browser versions here are never mentioned, which means this is "multi-browser", and not "cross-browser" (a large difference).

Furthermore, the following snippets are simply false:

> But Internet Explorer is the black sheep of the browser world. If your tests fail in just one browser, well, you get the picture.

Funny how older versions of browsers such as Opera are never mentioned. IE versions 6-8 seem to be the only "old" browsers that exist. Which of course is because they're still in use. Myopia reigns supreme.

I've often found that IE versions 4-9 will point out errors I've made in my code, as the IE platform is far more strict than browsers such as Firefox, which scramble to protect bad code.

> Accordingly, automating testing in Internet Explorer is much more involved than any other browser.

As someone that tests in 20+ browsers, I spend a lot more time on Firefox versions 1-13 than I do with IE versions 4-9, especially with scripting. Nevermind Google Chrome, which makes testing incremental versions nearly impossible (and no, auto-upgrades are no guarantee).

> Getting automatic cross-browser JavaScript testing working is a complex affair, and bound to involve some amount of trial and error.

Conclusion: test manually. There are no guarantees.

Please feel free to comment on the project or the Web site.

I'll try to field every response.