The discussion about version targeting continues. In Version Two Eric writes:
The handling of JavaScript libraries in a world where the pages calling the libraries will determine how the JS is interpreted – that’s definitely something I hadn’t considered. As I understand it, the problem case is one where a JS library that uses (say) IE9 features is loaded into a page that triggers the IE7 engine. The library would need to preserve backward compatibility with all the IE versions that could be used.
But isn’t that already the case? Every library whose source I’ve studied has all kinds of detection, whether it’s feature or browser detection, in order to work with multiple browsers. I would think that under version targeting, the same thing would be necessary: you do feature detection and work accordingly. Again, it’s entirely possible I missed something there, so feel free to let me know what it was.
The issue with JavaScript libraries (and embedded widgets) is an important one. Eric is right that libraries have to already cope with multiple browser versions, of course. The difference is that, over time, those old versions disappear. A library or widget developed today doesn’t need to really take IE5 or even IE5.5 into account because those browsers have gone away to an extent that it’s acceptable to not serve them your page’s behaviour layer (a la Yahoo’s Graded Browser Support).
The difference with version targeting is that IE7 ‘mode’ is never going to go away. Fast-forward to 2012 when the current version of IE is IE11, but there’s still a good proportion of IE10 in the marketplace. A JavaScript library has to include conditions not just around any quirks in IE10 and IE11, but also all those quirks from IE7.
If there happen to be any differences in the way IE7 mode is implemented, the library may even need to cope with IE10’s IE7 mode and IE11’s IE7 mode. If the library does anything with CSS (for example a drag and drop script) variations in CSS rendering across all those implementations has to be taken into account too.
Developing for the current browser plus the previous version is inconvenient but readily achievable. Developing for the current version, the previous version and a version 4 years old is not only a nightmare, but also limits the functionality you can use and slows the progress of the web.
With version targeting, IE7 will never go away. Just as browsers are born, they must also die and make way for the next generation.
Comments
Agreed. But (fortunately) there’s an important point you missed…
A library could be written to just target IE11 and IE10 and simply proclaim it cannot be used in IE7 targeted pages.
Since developers using a modern JS library are likely to prefer supporting the most modern rendering engines available, this may not be so big of an issue.
That might work for libraries, Bryan, but consider also things like embedded widgets and ‘badges’ (like a Flickr badge or similar). It’s in a company’s interests to get their service promoted through such things in as many places as possible – and to do so in a slick way, not in a way that looks like a crappy badge written 4 years ago.
I think I understand, although it seems like feature detection as opposed to browser detection would alleviate much of this issue, would it not? (Maybe not, which is why I ask.)
Also, I’ve noticed that a number of supporters of the general idea are JS library and AJAX developer types—Alex Russell, for one example, though there are others. What causes that difference in opinion, do you think? I’d like to know because understanding the difference might help illuminate the whole topic from a different angle.
Under current proposal IE10 and IE11 (or whatever) would default to IE7 but the amount of people actually using IE7 will be immeasurably small if not in fact none. Perhaps the default rendering engine could be updated but just on a much slower timetable. Indeed this highlights a problem with version targeting; Is it truly sustainable?
Good point in the argument on the new targeting mechanism proposed by Microsoft. Displaying old pages only by means of a specific mode in newer browsers seems ridiculous to me. The same issue accured in case of Word, and this problem still hasn’t been resolved properly. Hopefully IE9 will involve a more reasonable rendering mechanism.
I think the biggest problem here was hinted at, but not spelled out entirely: there is a significant possibility that IE10 etc will support JS3, but still allow the IE7-compatible CSS mode, so will support JS features that make no sense to the available DOM. Browser sniffing will be of little use, which is just one more reason to oppose this irresponsible idea from Microsoft.