Recap of Add-on-Con

We’ve just returned from Add-on-Con, an annual conference for browser add-on developers held at the Computer History Museum in Mountain View California. The add-on development community is an entrepreneurial bunch of people and it’s exciting to hear about what they’re working on. Herman Ng, Christopher Griffin, and I were there to present and chat with people. Matt Crowley was also in town so he was able to stop by for part of the day.

Herman spoke about best practices to improve reliability and performance. This topic really resonated with the audience. It’s clear developers want to deliver a great experience to customers by building cool features, having great reliability and performance, and getting exposure in the IE Add-on gallery. Based on the amount of interest we saw, Herman will be reworking his presentation into a series of blog posts starting early next year. So you don’t have to wait, I’ll give you two of Herman’s quick tips for add-on developers now.

Post your add-on to the IE Add-on gallery. Developers click “join” and then click on your username to upload add-ons.

My presentation covered how to build Webslices (msdn), Accelerators (msdn), and Search Providers (msdn). These extensions are a great way to connect your customers with your services without the risk of introducing performance or reliability problems. You can also build and deliver them with a little bit of XML and markup so you can connect users with your site or service in hours rather than weeks.

Considering that there are well known published issues with IE performance going down the tubes – telling us that this is a great way to connect your customers without the risk of introducing performance or reliability problems is painting the kettle white.

slices, accelerators, search addons might not bring IE to its knees but many of the addons that load in every tab – even if there is no HTML content in the tab cause IE to grind.

Please consider a post telling developers how they can build addons that only load on demand, not per every tab etc. so that we can fix the IE performance issues that it suffers from today.

I wish Microsoft would simply re-engineer IE or better yet start from scratch and make a new broswer; but don’t call it IE. Too many people have negative associations with that name. Call it some nice simple name that is not too cute and doesn’t have any negative connotations nor negative acronyms. And make it support web standards like HTML5 and WebKit. And make it fast fast fast fast fast. As is obvious, most people hate to wait for anything. This is why Chrome and Firefox and Safari are gaining in popularity while IE market share is dropping.

Giba: don’t believe the hype in the echo chamber. IE may have lost a point or two of marketshare over the last few years, but it still has twice as many users as all of the other browsers put together. For many people, Internet Explorer *is* the Internet, and it has fine connotations, for the rare people who even know what a browser is.

Edward: Documentation on how to build "on demand" extensions for IE (toolbar buttons, menu items, and ActiveX controls) has been documented on MSDN for over a decade now. Web Slices, Search Suggestions, and Accelerators (which are basically on-demand) are also reasonably well documented there.

Matt: Here in Germany, Firefox has recently surpassed IE in market share. Thus, it’s not just a "hype" that’s happening.

The driving force behind that development here is that the two highly influential German computer magazines "c’t", which is for IT pros, and "Computerbild", which is a tabloid for home users, have been recommending Firefox as the top browser for the last 2 years. Computerbild had a browser test recently: Firefox was rated best, IE last. And we can read again and again: "Why should you switch? Firefox has much better add-ons, such as efficient ad filters".

Although I personally prefer IE (I’m an IE add-on developer), I have to admit that IE just cannot compete with Firefox regarding add-ons.

If you tell people about IE’s advantages (tab isolation, for example), this often doesn’t seem to matter to them because they cannot "see" this feature.

Another cause for the migration trend is that Germans are very concerned about security in general ("German angst"), and IE still is regarded of being more unsecure than Firefox. Of course that’s no longer true, but every patch day, Windows users see important security updates for IE, which regularly reminds people that IE is vulnerable. Firefox sees more security related fixes than IE, of course, but they are delivered as neutral new Firefox versions, not intimidating home users.

On the other hand, Germany has the fastest adoption rate of Windows 7 world-wide, and so there’s hope that lots of German Windows 7 users may rediscover the great IE that’s in Win7.

IE’s event model has another problem: how do you know which element ‘caught’ the event? In the W3C model, the ‘this’ keyword on the event handler function designates the element itself. In IE, you need to refer to event.srcElement – but then, event.srcElement always refers to the first element that captured the event, not to the element actually handling it (see http://www.quirksmode.org/js/events_order.html for a complete explanation).

This makes, for example, mouseover effects (extended help bubbles and tooltips) impossible to handle for non-top elements (say that you create a function that displays the content of a tag’s title inside a tooltip tha tfollows the mouse; a single ‘span’ or ‘strong’ tag will remove the tooltip in IE – something that other browsers handle much better). Working around this requires:

– either creating a ‘title’ for all children that don’t have one, and copy their parent’s, then register an event handler on each one of them (this will probably cause leaks in IE if you use an AJAX page)

Can you guys make a new browser like Google Chrome or Apple Safari? I think it is high time that MS start all over again from scratch to engineer something entirely new, FAST, SECURE, EASY TO USE. Too many people dislike IE and view IE as being old, slow, technology. By staying with IE, engineers are being forced to write legacy code; throw that code away, and start designing a browser with fresh eyes, with fresh mindset. You CAN do this. Your users want you to do this. And if you don’t do this, your competitors like Google Chrome and Firefox will continue to gain market share as IE continues to lose market share.

And, I forgot to add, Giba is right: Don’t call it IE. Too many negative connotations. Most of my twenty-something friends wouldn’t touch IE with a 10-foot pole (as the saying goes). Most of them used to use Firefox, but are switching to Google Chrome because it is even better than Firefox. Yes, it doesn’t have as many addons as Chrome but it is faster and more secure. As Giba says, people hate to wait. People want speed. Next time you turn on your PC or laptop, does the boot up time bother you? Do you wish it booted up faster? If so, then you already are aware of how long it takes to start a piece of software. Well, same thing applies to browsers. One of the reasons that I upgraded to Vista (and soon to Windows 7) from XP is that I found that Vista booted up faster (I know that some people found the opposite was true for them. But it is true for me.)

@Will: open the following URL with IE 7/8 (it should open in highest standard mode) and any other browser side by side. Look at the (simplistic yet valid) HTML and (unnecessarily complicated to allow two event models to work, but passing JSlint scrutiny) Javascript.

It makes use of (proprietary) mouseenter for IE, which makes it even worse than mouseover: it disables the bubble over text nodes too, or if the mouse left the event’s source element too fast. Yay.

@Victor: Will was right; he was correcting me on an inversion I had done. ‘IE never supported event capturing’ was what I meant.

@Matt: a billion people use IE:

– to download another browser :p

– because their IT department forces it upon them at work (IE’s share plummets on weekends)

– to access US banking sites, which still require IE

– because they are computer illiterate and think that the blue ‘e’ is ‘the internet’.

About the latter: they usually switch the day when GinaB’s twentysomethings, fed up with having to clean friends/relatives’ computers for them, install another browser and tell them: ‘the internet is now the fox/red O/colored sphere/compass’.

I’d like to add that there are more than a billion Internet user in the world. Much more, in fact.

After all, one has to wonder how Firefox, with a marketing budget in the six digits range, could get back more than 20% market share (in some countries, it’s over 45%) over IE, with its multimillion campaigns and forced installs on each and every Windows computer sold.

> IE may have lost a point or two of marketshare over the last few years,

IE has lost at least 25% of world browser market share in the last 5 years according to a very wide consensus of browser usage stats: en.wikipedia.org/wiki/Usage_share_of_web_browsers

There is an undeniable decline still going on.

> but it still has twice as many users as all of the other browsers put together.

In 1 year from now, this won’t be true anymore. In 2 years from now, this will not be true. In several countries (in Europe and in Asia), non-IE browsers have over 50% of the market and IE browser versions are steadily declining with time. Try

> You managed to install some junk that crashes IE? Are you expecting this to prove that you’re smart or something? Install junk in Firefox and you can break that too.

There are websites documenting how IE versions (6, 7 and 8) can crash, with or without add-ons. The nr 1 problem since IE6 was

a) to get Microsoft to realize such problems and

b) to get Microsoft to fix such problems.

It still takes a lot of time (months and years) and it is still difficult to have Microsoft fix those (CPU hang due to infinite loop, application crash) problems. This is not the case with other browsers like Firefox, Opera and Konqueror: crash bugs, hang bugs are reported, tackled, fixed much faster. I can document all this very easily, even with IE8 crashes.

Do not misunderstand me: browsers all have bugs, occasionally even crash bugs and hang bugs and dataloss bugs and other serious (with objective gravity, severity, criticality) bugs … but Microsoft is and has been (historically in the last 10 years and still today) the worse at fixing them.

For web developers, IE is still the worse:

– MSDN documentation is unreliable, full of mistakes, very IE-centric, utterly IE-specific and not web-standards-friendly

– MSDN documentation is full of examples without a doctype declaration, with markup errors, with CSS errors, with using and abusing known IE-only attributes, IE-only methods, IE-only implementations, IE-only features. In other words, those examples contribute to furthermore alienate web developers and contribute to break the web.

– good debugging tools and softwares, good HTML web authoring softwares (or assisting development like validators), advanced web authoring editors (HTML, CSS, PHP, javascript, etc) never come from Microsoft and those from Microsoft are not all free

For all those reasons (and many others), IE’s future does not seem very bright.

regards, Gérard Talbot

P.S.: Even working at Microsoft may not be a "rosy" adventure. Not demonstrating enough enthousiasm in pronouncing and perrot-shouting "Bing" can get you fired in front of everyone else during a meeting.

Sets the mouse capture to the object that belongs to the current document.

Default. Events originating in a container are captured by the container.

"

msdn.microsoft.com/en-us/library/ms536742%28VS.85%29.aspx

but it’s still not DOM 2 Events implementation.

Regarding IE browser usage decline

———————————-

Another point which may become quite important in the next few years: new Windows 7 buyers in European countries now have a choice (via a Windows 7 browser ballot screen) for their default browser. If Microsoft is so convinced that IE 9 can compete and will be the best, then Microsoft should not fear having a Windows 7 browser ballot screen for any/all new Windows 7 buyer, not just European customers.

2- If iB (iB for infobulle meaning tooltip) sole purpose is to display only text, then resorting to innerText and innerHTML can be safely, conveniently avoided, removed. Just use createTextNode() and childNodes[0].nodeValue etc… and you’ll reduce cross-browser forking code. DOM 2 CharacterData interface attributes and methods are very well supported in IE 6, IE 7 and IE 8. Why make editing/modifying the text of that tooltip more difficult? 99.9% of the time, innerText and innerHTML can be better replaced, removed, avoided with true web standards DOM attributes without any loss or problems.

3- initCommon() is called at window loading, not at document loading. Now, browsers compensate this but it’s still a mistake. Under normal and strict conditions, a script can not and should not be accessing document elements or creating new ones (like curtag, iB, infobulle, ct) before the document has been fully loaded. Window and document are not loaded synchronously, simultaneously.

I recommend to remove

addEvent(window,"load",initCommon);

and just add

<body onload="initCommon();">

I am sure, absolutely convinced that your webpage can work as expected in IE 7 and IE 8. Remember that IE beta feedback had a very annoying DHTML tooltip function. Also, your webpage goals as far as tooltip is involved could be made working without event models, just by using CSS.

I’ve been lurking on the IE blog for sometime. You seem to be the resident troll who camps this blog and flames everyone who asks a sincere question or expresses a criticism of Microsoft. This is a tacky way to support the company and its IE browser.

The "rabid IE fanboy who hates all criticism" defeats the purpose of this blog and increases the negativity of the discussion. Each time you post, you derail the comments and trigger a flame war of petty insults.

I assume you have no official connection to Microsoft and you are merely an overly-enthusiastic IE fan who mistakenly believes that spamming questioners with insults serves a constructive purpose. It doesn’t.

Perhaps you should temper your posts and find a more constructive way to craft your responses. Turning down your "Hostility Dial" from 11 to 1 would go a long way.

ted, you must be new here, since I’m fairly new to commenting on this blog, and while there’s plenty of hostility here, little of it is from me. If you’d actually been reading here any length of time, you’d recognize that there are few "sincere questions" nor very many worthwhile "criticisms" either. There’s a lot of ranting and gnashing of teeth from fanboys of less popular browsers who curse the unfairness of the real world.

So, yes, I recently have tired of reading the dreck and falsehoods in the comments and have momentarily taken up the banner of calling out the misrepresentations and outright lies that are posted therein.

It’s ultimately as pointless as the ranting from the other side, of course, but it’s a pleasant enough way to waste a moment here or there.

– IE’s event model is limited compared with the W3C’s, and quirky anyway

– working around a few (not all) of its limitations is possible (you demonstrated it), but still incomplete and it requires ungodly amounts of code to do something that the W3C event model accomplishes with ‘true’ for addEventListener’s useCapture=true.

As for IE’s market share, it varies so much depending on how, where, when, is someone farting in a server’s direction or whatever when it is being done that no one can come up with a reliable figure. 25% is conservative – yet a reasonable consensus.

@Matt: by making fun of Gérard, you’re at the same time discrediting the IE team, since they acknowledged his contributions (in a past article). Or maybe they just appreciate his fiction writing skills, who knows.

@Matt – Ted is right. You are quite rude in your comments. Gerard is very knowledgeable and can express himself in pleasant terms, as is Mitch74 and several others. You, on the other hand, just seem to want to annoy people by disregarding everything they say as false and inaccurate, also that we should accept IE as the "one true browser". While you’re totally entitled to your opinion – bear in mind the old addage, it’s not what you say but the way that you say it.

In my 25 years of dev/support/mgmnt, the one thing that has grown out of control are these stupid add-ons that ALL BROWSERS pester its users to download in the middle of their browsing experience, be it a shopping cart checkout, a web email reply, or even to this simple blog comment! Why must we be constantly bombarded with activex this and javascript that? Shouldn’t IE be PRE-LOADED with all available plugins that the web supports? It does make a lot of sense when you think about it. Today we take for granted, these add-on pop-ups, and simply click YES to anything that stands in our way of completing that post to yahoo or that submit to amazon because its far too common for us to do so. As a result, people inadvertently download malicious software – even professionals like me. The ones most affected are senior-citizens. Grandma phones me: "i want to send some pictures to your email but i need some kind of flash doohickey"….. After 15 minutes of instructions and finally a success, another popup hits her in the face – this time some kind of activex control that is not installed. "oh i’ll just send it in the mail" is her reply. Not surprisingly, my search for a better browser was in vain. Why cant we have a browser that simply works with everything? At the very least, work with the most popular standards? Flash, java, silverlight, quicktime, and those pesky activex plugs that common vendors often use like amazon, buy, newegg and for christs sake – even hotmail. And for crying out loud, when will IE have a download accelerator like Flashget built in?

point 1, use of setAttribute; you’re right. I think I used that construct to circumvent a bug in a browser (not IE), but I can’t remember which (could have been Konqueror 3.4, or even Mozilla Suite 1.0rc2). Anyway, setAttribute isn’t buggy in IE 5+ for ‘id’, so I didn’t worry about it too much afterwards. It is, after all, valid, and if it ain’t broken…

point 2, I did use textNode at first, but performance on complex pages with many small elements having a ‘title’ was sorely lacking in many browsers since I was forced to empty the bubble first (or re-create it) before I filled it (reason one), this method allows me to introduce HTML tags sometimes through a Javascript rewrite of the ‘title’ value, avoiding HTML entity encoding/character escaping problems (reason two), innerHTML is both widely supported and being considered for ECMAscript 4 (reason three), and textNode was causing event bugs in IE 7 on slow machines (probably linked to reason one: bad timings).

Point 3, I dislike using inline Javascript, and I usually call my initCommon function through:

– registering it as handler for the DOMContentReady event, when it exists (removed here for simplicity)

– a document.write+deferred hack for IE (removed here for simplicity)

– registering it as handler for the body.onload event (kept)

Thus, the ‘arguments.callee.done’ global check at its beginning: it might get called twice. Moreover, this is usually not the only function called at page load – this is, then, a matter of consistency. That I can keep all my Javascript in a single file and load it with a tag in any document’s header helps, too.

@the IE team, a point I wanted to raise; the code on my test page contains an unused workaround for IE: the ‘change’ event on ‘select’ elements that… change, doesn’t fire in IE, forcing me to register it on ‘click’ – which doesn’t cover keyboard handling (I should register functions on focus and blur events, check that value has changed between the two, plus register a function on keyup events that checks if value changed after element got focus but didn’t blur, for IE only, but even IBM stopped requiring people to program a new keyboard driver on each program load – why don’t you?). I’d enjoy getting rid of such exceptions.

"Shouldn’t IE be PRE-LOADED with all available plugins that the web supports?"

… That’s where I stopped reading.

Have you really been developing for 25 years? Maybe it’s time to retire.

I don’t think you realize how many plugins exist, and regardless of the fact most users don’t need them, IE wouldn’t even be able to start if you had that many. That’s almost like saying Windows should come with all existing programs ever (and run them on Windows startup while we’re here).

@Paul: the problem isn’t with how often IE fires the event (that’s it, I’ve found back the bug report I wrote down a while ago): it’s how the element’s value behaves that required the workaround.

Actually, IE does fire the event quite often (more often than Firefox, which mostly follows the RFC, while Webkit/Opera follow IE’s firing frequence).

But there is a problem with the SELECT’s value when using ‘change’: if you have another function (NOT the event handler) that looks at the element’s value after the event fires but before its event handler completes, this function gets the element’s previous value instead of its current (displayed) value (in essence, the element has two values simultaneously).

This doesn’t happen with other browsers, even those that follow IE’s way of firing the ‘change’ event.

One workaround is to force ‘blur’ on the element when running non event handler functions (for example, by shifting focus), or simply use ‘click’ (which doesn’t exhibits this problem but otherwise behaves like ‘change’ – even on keyboard events, which is incoherent).

@Will: yes – so you had to download a third-party library (jQuery, which is otherwise very nice), which weighs in at 19 Kb after minimization AND compression (unpacked, it’s around 120 Kb uncompressed – thus, the amount of code to actually be parsed by the browser) in order to circumvent the lack of a keyword in IE.

It’s rather like hunting ducks with a rocket-propelled grenade launcher: a waste of resources, too easy for you (but not on your dandwidth), and unsafe; what if I have no further use for jQuery? What if IE 9 (or any other browser) breaks that version of jQuery, requiring me to update the version I host on my website? What if I don’t maintain that website anymore?

Don’t you see? That’s actually the point! We, as web devs, must spend countless hours circumventing IE bugs, improper implementations, special cases and proprietrary features, through compatibility libraries, specific code development, tricky debugging, that _no_other_browser_causes_! Not that other browsers don’t have their own quirks and bugs, but all of them cumulated don’t approach that of a single IE version! I could have done the exact same thing on any other browser with 1.2 Kb of uncompressed, unpacked code (which ends up smaller after compression, thus a single high-speed TCP packet), if not for IE.

Also, when the demo is viewed in IE8 without JScript – you can still see the title attributes, as intended, since the default browser behavior is to display the title attribute in a tooltip. So, depending on how a demo like this might be used in a real world scenario – you may not even any JS for it at all.

I am not sure what you mean with "caught" here. Even in the W3C DOM 2 Events model, you need to set in javascript some kind of output (like an <input type="text">) to see-know which DOM node has actually received the event object within the containment hierarchy. And you would need to do that during capture propagation, at target and then during bubbling propagation.

> In the W3C model, the ‘this’ keyword on the event handler function designates the element itself. In IE, you need to refer to event.srcElement

Well, that’s not correct. I think you may have stumbled on something else (like global scope pollution [named form controls are visible in the global scope], or event scoping issue).

> mouseover effects (extended help bubbles and tooltips) impossible to handle for non-top elements (say that you create a function that displays the content of a tag’s title inside a tooltip tha tfollows the mouse;

As far as I understood you, I think you need to set a mouseover function handler for DOM nodes which have a non-empty title attribute in your page and then execute

event.cancelBubble = true; // stop bubbling

in your handler functions so that the event does not propagate to higher (what you refer as "top elements") containing (containment hierarchy) nodes.

"

whenever you use nested event handlers in this way, you need to consider carefully whether the event handler should carry out an action each time it is called. One way to control the action is to use the cancelBubble property.

A generic block-level element like a div is, by default and by definition, a block-level element, therefore has display: block. It has by default and by definition no padding. So, "display:block;padding:0;" could be easily removed, are not required.

I’ve never used compatibility libraries and I’ve never recommended one. I know how the event model works in IE. I know for certainty that your webpage code is not optimal, has a few mistakes, misunderstands a few things, resorts to unneeded declarations in CSS, resorts to strange decisions, etc.

I do not know for sure what exactly you want to achieve to begin with. Maybe you should explain all this in a web programming forum discussion newsgroup like comp.lang.javascript: you would get help there.

> Why must we be constantly bombarded with activex this and javascript that?

I agree with you: many sites over-use and misuse javascript (and Flash) … and often it just duplicates the standard default functionality of browsers. Why would I need a button inside the content area to bookmark a page, to increase text size, to print, go back in history, to close a window, etc.. when the browser by default can do all that to begin with?

> Shouldn’t IE be PRE-LOADED with all available plugins that the web supports?

Plugins and add-ons are browser extras, browser additions. The user is ultimately the sole responsible for plugins or add-ons in his/her browser. And websites which make their content only available through such plugins (without a fallback or alternate format) are the ones making huge mistakes.

Pre-loading all available plugins in IE may make the system unstable, run out of memory. Just imagine Adobe Acrobat Reader for PDF content: huge amount of cpu and RAM… and an user may not have to view any PDF content during his session.

> Why cant we have a browser that simply works with (…) the most popular standards?

Flash: it’s done and created by Adobe. Microsoft can not, just like that, add Flash into IE8 without the users’ consent. And Adobe has to update such plugin, fix bugs, fix security bugs too.

Java: it’s done and created by Sun Microsystems. There’s even a court order and court settlement between Suns and Microsoft [1] so that Microsoft stops embedding JRE plugin into IE.

Silverlight: that’s a MS plugin. If you download it and install it, it’s your decision. And you should be able to uninstall it. Websites relying on users having Silverlight and imposing Silverlight and restricting to Silverlight for their video content or web content are the ones making a huge mistake.

Quicktime: it’s from Apple. Again, multi-media content should be made available to any media player (Real One, Windows Media Player) and if no media player can handle the content, then there should be an alternate content/fallback available: that’s what Web Content Accessibility Guidelines are all about.

Web authors are ultimately the responsible, imputable persons for how they create their webpages and how their content can be accessed. Browser manufacturers like Microsoft and MSDN can and should educate web authors on accessibility and web standards compliance.

Ultimately, Yahoo! and Amazon lose customers and miss/"fumble" sales when they do what you described.

regards, Gérard

[1]: "in 2001 won a settlement of $20 million as well as a court order enforcing the terms of the license from Sun.[21] As a result, Microsoft no longer ships Java with Windows, and in recent versions of Windows, Internet Explorer cannot support Java applets without a third-party plugin. "

@Gerard – I think Mitch intended the compatibility library comment towards me, since I used a jQuery powered function to solve his bubbling scenario. The power of libraries like jQuery, MooTools, Dojo, etc is that I was able to come up with a cross-browser script in less than 5 minutes – just by writing a few lines of code.

…I think the most interesting thing about this though is that modern browsers (including IE8) display title attributes as a tooltip by default. So if displaying title attributes is the aim, then only basic HTML is needed.

If the compatibility library is there to work around browser bugs, browser flaws, then such compatibility library acts like a crutch for short-term and does not serve a proactive goal/approach. It’s not a real solution for everyone involved on the web (manufacturers, authors, users).

If the compatibility library is for cross-browser with IE7 and IE8, then it’s not a real solution for everyone. IE has to support properly all of the mature and stable web standards: DOM 2 Core, DOM 2 HTML, DOM 2 Events, ECMAScript 3.1, HTML 4.01, CSS 2.1, etc… so that we wouldn’t/won’t need to resort to a compatibility library (or code forks or complex js acrobatics) now/in the future.

If the size of the compatibility library is huge (like over 10KB), if its functions are long, complex, indecipherable for ordinary web authors, then a compatibility library is not a solution: it’s a nightmare.

If half of the compatibility library is to support IE5.x, IE6, IE7, Firefox 1.x, Opera 7.x, Konqueror 3.5.x, Safari 1.x, etc.., then such compatibility library wrongly replaces/substitutes the need for users of such browsers to upgrade their browser versions, to keep their browsers updated.

Manufacturers should fix their browser bugs (and implement mature, stable web standards) while users should keep their softwares updated. Where does a compatibility library fit into such equation?

@Gerard – In the world of software development life cycles, cost management and deadlines – JavaScript libraries are a very real and very useful solution. They are very effective at abstracting away the need for browser specific programming in modern web applications.

I predict that within the next couple of years we will start seeing modern web browsers integrate the major JS libraries as native to their script interpreters (or compilers). Because the handful of major JS libs are so commonplace now, browsers could get a huge performance boost by implementing this.

I am currently in contact with some of the IE staff, have even built test cases for some of the newer bugs I found in IE8.

While it is true that IE8 is not nirvana for WebDevs, I consider it a step into the right direction and will help MicroSoft at every opportunity to create a browser that will at least reach, at best even outperform in terms of speed, usability and standards conformance all other browsers. Currently they concentrate on features, but in the background, a lot of work is going into the rewrite of the JS engine, for example.

I know that there will be some more Versions than IE9, IE10 and IE11 to come this far. But at least they are on the way.

Why do you or would you need to resort to a compatibility library in the first place, to begin with? What’s the real problem, real issues here being addressed and being solved by using a compatibility library?

To work around browser bugs in various browsers and browser versions? To compensate for browser versions like IE8 which miserably fails at many DOM test suites on mature and stable DOM TRs? To work around many DOM 2 Core bugs, DOM 2 HTML bugs in IE8? To continue to support bug-ridden dinosaurs like IE6? To support very buggy browsers like IE7? To overcome/compensate lack of very cosmetic presentational/stylist properties like border-radius (rounded corners), text-shadow, etc.?

Deployment, implementability, debuggability: how complex, easy-to-grasp are such compatibility libraries?

How big (filesize) are such compatibility libraries? How cpu+RAM hungry (footprint) are those compatibility libraries? How many/much setTimeout, setInterval, event handlers is there in such webpage? Are you trying to do a DHTML-driven "snowflakes randomly falling in background" effect in your webpage?

There is such a thing as limited (and/or modest) user system resources. Normal, avg. people should be able to buy online a book at Amazon or something else at an auction site without

– running out of memory, eventually making application more prone to crash

– having an hourglass cursor shown most of the time (typical external symptoms): unresponsive application because overwhelmed

If browser manufacturers all support mature and stable web standards (HTML 4, CSS 2.1, DOM 2 interfaces, ECMAScript 3.x) and if all users keep their browser softwares updated, then why would you need to code thanks to a compatibility library? If there is a need, then it should be limited, targeted and for well defined context, circumstances (e.g. like a special game website, SVG-driven website) … and not for an ordinary person trying to buy a book, to pay his bill here or do a bid over there.

"Why do you or would you need to resort to a compatibility library in the first place, to begin with?"

To reduce development time.

"What’s the real problem, real issues here being addressed and being solved by using a compatibility library?"

The real problem is creating web-based software. The problem being solved, is being able to create it efficiently.

"To work around browser bugs in various browsers and browser versions? To compensate for browser versions like IE8 which miserably fails at many DOM test suites on mature and stable DOM TRs? To work around many DOM 2 Core bugs, DOM 2 HTML bugs in IE8? To continue to support bug-ridden dinosaurs like IE6? To support very buggy browsers like IE7? To overcome/compensate lack of very cosmetic presentational/stylist properties like border-radius (rounded corners), text-shadow, etc.?"

The term "bug" is all relative. Perhaps the standards bodies have created flawed drafts?

"Deployment, implementability, debuggability: how complex, easy-to-grasp are such compatibility libraries?"

If you know JS, the major libraries are easy to learn.

"How big (filesize) are such compatibility libraries? How cpu+RAM hungry (footprint) are those compatibility libraries? How many/much setTimeout, setInterval, event handlers is there in such webpage?"

Depends on what exactly you use, and how you use it. When building web apps for the enterprise, you usually have a managed environment where you know exactly what system resources will be.

"Are you trying to do a DHTML-driven "snowflakes randomly falling in background" effect in your webpage?"

No.

"If browser manufacturers all support mature and stable web standards (HTML 4, CSS 2.1, DOM 2 interfaces, ECMAScript 3.x) and if all users keep their browser softwares updated, then why would you need to code thanks to a compatibility library?"

If I lived in a fantasy world where 100% of users had the exact same browser, I would still use a library for the simple fact that having a nice set of objects and functions makes it easier to develop, maintain, and scale applications.

"To work around browser bugs in various browsers and browser versions? To compensate for browser versions like IE8 which miserably fails at many DOM test suites on mature and stable DOM TRs? To work around many DOM 2 Core bugs, DOM 2 HTML bugs in IE8? To continue to support bug-ridden dinosaurs like IE6? To support very buggy browsers like IE7? To overcome/compensate lack of very cosmetic presentational/stylist properties like border-radius (rounded corners), text-shadow, etc.?"

WP:The term "bug" is all relative. Perhaps the standards bodies have created flawed drafts?

What’s the use of several DOM test suites then? What’s the use of CSS 2.1 test suite? And what’s the purpose of reporting bugs if bug is "all relative" according to you.

When browsers take test suites in an automated manner, then there is no relativity in the results.

Bugs have been reported to browser manufacturers via public accessible bug tracking websites for 10 years now (only in the last 2-3 years for IE). When bugs are reproducible, testcase-ed, documented with excerpts of spec, then they are not obscur or "all relative".

and then compare my posts and yours and reach his own conclusions, all by himself.

Personally, I do not need a compatibility library to create web-based applications, websites. I need browser manufacturers to fix their bugs, reported bugs, testcase-ed bugs, documented spec. violations, failures that anyone can see for himself/herself in test suites.

The whole web does not need people using bug-ridden-dinosaur-IE6, very-buggy-IE7, Opera 7, Safari 1.x, Konquero 3.x, etc. when they all can upgrade for free. It’s in their best interests (security, stability, bug fixes, features, usability) to do so and it’s also in the web authors’ best interests that they do so too… so that we don’t have to maintain forever backward-compatibility and a nonsensical extensive bugward-compatibility (hasLayout, CSS hacks, etc).

jQuery 1.3.2 (jquery.com): 55.9KB (entrance page said 19KB but the download page says 55.9KB) with white-space compressed. Each and all variables are one-single letter.

Uncompressed: 117KB!

And you are supposed to use this for "efficiency" purposes (!) and reduce dev. time (!) but not to work around known, reproducible, testcase-ed browser bugs. It’s officially supporting IE6 and IE7 and other older browser versions. And the page clearly says "CSS3 compliant"! CSS 3 is still in development: it’s not stable and mature. CSS 2.1 is. Working drafts are more likely to be changing in CSS 3. Not so in DOM 2 interfaces and CSS 2.1.

MooTools 1.2.4 (mootools.net): 65KB compressed.

Uncompressed: 101KB!

Each and all variables are one-single letter. Support for Safari 2+, Internet Explorer 6+. There’s even a book available that you can buy.

Each and all variables are one-single letter. And you recommend this to save development time, for efficiency?? And you can’t even say that people are using this to work around browser bugs!!

> If I lived in a fantasy world where 100% of users had the exact same browser …

I live in a world where the latest versions of mainstream browsers all pass the acid2 test. I live in a world where browser manufacturers all have an accessible bug tracking system. Mainstream browsers (latest stable versions) should all get in the high 90% when trying DOM test suites, CSS 2.1 test suite and other automatable test suites.

I live in a world where a JVC television, a Toshiba television, a Sony television, Panasonic, LG, etc. sets will all render the same output from the same signal they shall receive.

I shouldn’t have to waste dozens, hundreds of hours just to understand what exactly is the dojo.js, mootools, jQuery js files are doing just to work around a bug here or an incompatibility there. Browsers now share almost all of the same default, initial values: so why not use these instead of fighting these with over-excessively declaring, over-excessively coding js?

I appreciate and admire your insight and knowledge. It is clear you have a strong opinion and a clear vision about browsers and the web.

That said, I agree with Will that something like jQuery can save lots of time and annoyance when you just want to get something done.

For about 95% of the things that are required of me, the time to develop it is the single most important factor to success. After that, it’s runtime speed and correctness that bang the drum. Way, way down is perfection and elegance.

In my experience, loading a 50k js library (provided proper caching by the browsers) is really not an issue for the majority of pages I have to deal with.

(That said, I can fully appreciate that there may be sites for which the requirements concerning footprint, bandwidth, etc. are more constraining.)

JQuery is great. Browser compatibility aside, it’s elegant and reuses the CSS syntax, so it’s not only very simple but also lets you reuse existing knowledge rather than create yet another new coding style. So, even if all browsers had a bug-free JavaScript implementation, I’d still use it.

Also, handling browser differences is the job of the library. For example, if later on they want to remove IE6-specific hacks from jQuery (in order to reduce size and improve perfs), then that’s cool, and it’s their job, not mine. One less thing for me to worry about. Also, such libraries clearly don’t prevent browsers from fixing their bugs (I certainly didn’t see any browser devs saying they wouldn’t fix a certain bug because jQuery works around it).

The size of the library is often insignificant (in most cases, users won’t notice a thing). And that’s what modern languages and technologies around about: simplicity, elegance, productivity and maintenance ease, possibly at the possible cost of size or performance, because that’s not what really matters in most cases. Micro optimizing everything is not the way to go, else we’d still be coding everything in assembler.

HTML, CSS and JavaScript are originally interpreted, and weren’t designed with performances in mind first. They’re text based in order to be simple and accessible. They weren’t made for performance-obsessed developers, else they’d be in some kind of compiled or pre-compiled format, or something like that (just like content that requires plugins).

Besides, with JIT-compiled JavaScript, the added cost of using a JavaScript library rather than bare JavaScript is getting increasingly blurred and irrelevent.

Let’s say I want someone to make a site for me, and that I have to choose between 30 lines of jQuery (therefore requiring the inclusion of the whole jQuery library), or 100 lines of bare JavaScript that’d load and run a tiny bit faster, I’d pick the jQuery version any day. Reason: maintenance cost. There *are* a few web apps where performances matter so much that micro optimizations are necessary (Google apps and the likes), but they’re a minority. In most cases, it’s not a high-priority concern.

To sum things up, no offense, but I think your view on this subject is old and dated, as if you lost sight of what actually matters. Don’t bury the lead, just get stuff done (and in a nice, non-hacky way).