Forums

Looking at Yahoo's Graded Browser Support Updates (f ex http://yuiblog.com/blog/2009/10/16/gbs-update-2009q4/), forecasts are only made for the upcoming quarter. What is YUI's long-term strategy for browser support - cut off browsers after a certain number of years or when going below a certain market share?

[I'm asking because of the current trend (among some webdevs and also library developers) advocating to remove IE6 support and force these users to upgrade their browser. I work with several clients that do not want to "lead the way" in this respect, and need to support IE6 as long as it has a fair usage share, which may be for several more years.]

Thanks
Mike

Thomas Sha correctly points out that the Dojo team is indeed having this conversation in an ongoing conversation on their contributors list. Alex Russell, among others, is advocating for a "sooner rather than later" strategy for deprecating IE6 support (sooner meaning something like 2011).

I don't see a public archive for that discussion, but it's a very active topic on their list -- so, you're right, this is being discussed for real by at least one of the major libraries.

-Eric

An advantage with YUI is that Yahoo is a very real user. YUI is not the consequence of a nice idea but it came out of a practical need and it shows in a lot of practical considerations in its design. The other example you provide is also of a toolkit tied to another big site.

Other toolkits out there, one step further from their users than the YUI team is, can spend their time in philosophizing about supporting this or that browser. Others have solid statistics to work with and a real need to reach people, they don't need opinions because they have real-life data.

That's only a good thing if you're on the corporate "never let IE6 die" side of the fence.

If you're a lucky web application developer on a project without the IE6 crutch (or simply adding sugar to a blog or pet project), that relationship means you're using a library that will put priority on supporting users you don't support over progressive new features/enhancements.

The way YUI handles class names is a perfect example, there's no good reason post-ie6 to have the huge compound class names everywhere, but I'm stuck with them.

If YUI was on the opposite side of the issue, I bet we'd see plugins/modules/css that add support for old or fringe browsers when and where needed and wanted, rather than it being a non-optional core part of the build. Instead my library will be sporting IE6 habits when most of my IE users are on IE9, or maybe even 10. I'm actually surprised that isn't the case anyways, since I'd think users who need strong IE6 support would also probably prefer the maturity and stability of the 2 line over the 3 line.

We are looking at breaking out the browser specific code into their own submodules to be loaded only when needed.

Not only does that help with IE6, but it can also help with mobile browsers and large widgets like Editor and DataTable. With Editor, the majority of the hacking code comes for things other than Firefox. So loading all that extra code in FF is a waste of bandwidth and processor power. If we split the code out, then loader would be smart enough to only load what the current browser supports. On the mobile side, for a smart phone, you would only be including modules that support WebKit, then iPhone/Android/etc browsers will get a customized version of YUI.

The reasoning for most of the classnames is deeper than just supporting .foo.bar style. If we use specific classnames instead of relying on tags and css cascade, we and the end users are free to change the markup associated with the widget.

For example, if we wrote an internal event listener like this ".foo.bar > em", that becomes overly specific and the user is now bound to only using that markup structure. That makes it difficult for them to add style elements to their widget markup, while it breaks our listeners.

Changing that to ".yui-foo-bar .yui-widget-tab" allows the developer to completely change the markup of the widget, all they have to do is make sure their markup classnames are in the right place.

Does that make sense/help?