1 Stable Development

I am all for Version Targeting because it gives my development team the ability to create stable releases. The team can push sites (or pages) live with respect to a given UA version rendering, and continue local development on the next version. When the new UA version comes, a responsible dev team should look to implement the new standards implemented (if any). I feel like we’ve been fighting for so long to have a way to preserve page rendering, and this is a great step in that direction.

posted at 06:49 am on January 22, 2008 by BJ Neilsen

2 Good Grief...

My gut is in knots just trying to think about how this would change the game.

As developers, we need to be able to know where we stand and be able to test our code against something that is solid and finite. We don’t live in a world where people update their systems and browsers with every advancement. Recently we have seen how some users who make the effort to keep up force companies to offer them a way to go back after the upgrade. (Thank you Vista)

I also ask myself, can we really depend on browser vendors to keep the keys working the same way with each new release? They have already proved they can barely handle supporting their most powerful users, the web developer. Isn’t the reason we have virtual machines because some browsers are so OS dependent we can’t make a stand alone version?

We need a solution that highly encourages people to keep up and think ahead when working on the web. As more people finish school where they are educated on web standards and browser developers continue to work hard on software that adheres to the standards, we will have a more standards compliant web to surf.

No change at all is better than what is proposed so far. If the vendors give us something with good “form”, we can give the users good “function”.

posted at 08:08 am on January 22, 2008 by Douglas Tondro

3 I'm curious...

…which reality this was posted from where browser vendors have the resources to maintain N versions of their engine, including security and crash fixes (consider that some IE7 feature deprecation was due to security concerns).

This is madness, pure and simple. Even if browser makers could implement it, what we would end up with in reality is a proliferation of targets, not a reduction:

IE10 emulating IE7, IE10 emulating IE8, IE10 emulating* IE9, and IE10
IE9 emulating IE7, IE9 emulating IE8, IE9
IE8 emulating IE7, IE8

None of these would render the exact same way. None of them. Then we get Safari 5 pretending to be IE8 emulating IE7 (otherwise it won’t work on www.importantsite.com which was coded poorly), and the universe implodes.

*why, you ask, wouldn’t IE10 simply load up IE7’s engine? Well, the engine API has changed (perpetual API freeze is a near-sure way to kill a product), and the underlying system APIs have also changed, and there have been many many security fixes that had to be backported, some of which probably changed compatibility (like, say, turning off DirectX by default in IE7).

posted at 09:44 am on January 22, 2008 by David Smith

4 Sigh...

pardon the formatting there; I accidentally tried to do a footnote with an asterisk, forgetting that would make it bold instead.

posted at 10:00 am on January 22, 2008 by David Smith

5 Why over-complicate?

Forgive me if I am missing out, but surely this is overcomplicating the issue to a massive degree.

Browser developers know when they release a new rendering engine. Developers know when they test the layout of a website. Wouldn’t it be far easier, and require far less browser-version-awareness on the parts of both parties, to simply include a metadata tag indicating the last ‘build’ date of the website?

Browser engines can use a timestamp as effectively as a human readable version number, and incorporate the dates of each rendering engine change into the browser itself. Developers know, (normally as its written in blood), when a site is launching. The date at which they test the deployment of a site across all of their target browsers is thus a simple way to embed the required ‘version’ data.

Its even simpler for WYSIWYG software, that simply needs to attach the date in the mark-up, thus not requiring dialogues or assumption to work out the target browser market.

posted at 11:11 am on January 22, 2008 by Ben Sekulowicz

6 Untitled

I agree with Ben Sekulowicz. If any system like this – which I don’t think is realistic – it should be based on a build date rather than browser name and version.

Best solution is for browser vendors to make their browsers standards compliant and for developers/website owners to periodically check their sites to see that they render correctly in the latest browsers.

posted at 12:30 pm on January 22, 2008 by Carl Holmberg

7 Untitled

I’m definitely not a fan of the “edge� keyword.

I have a feeling that it’s a consequence of having developers who work with Rails (Gustafson) involved in the committee who came up with this proposal.

I was surprised to hear about this, especially given Chris Wilson’s adversity to supporting two separate VMs for Javascript 1 & 2. Surely promising support within IE for throwing it into “IEx mode” (e.g. “IE8 mode”) will have the same consequences?

One can imagine the nightmare this will become 2 or 3 versions of IE down the track. I’m willing to put money on Yet Another IE-Specific Fix being proposed when the time comes to renege on the promise of indefinite backwards compatibility through version targeting.

posted at 01:32 pm on January 22, 2008 by Nathan de Vries

9 A few questions

Say Fx5 will be 2 times faster when rendering multiple backgrounds if compared to Fx4. But an user will not benefit from this improvement unless the author decides to update the lock-in-string from “FF=4” to “FF=5”. Why should vendors (that show no such big steps between the versions as MS actually does) apply this break at all then, if they partly loose the chance to play their trump cards – fast, standards oriented development?

Assume IE10 will be able to run under OS XII Mac/Nintendo. Will it be able to render a page that is locked in to “IE=8”? Switching back to IE8’s rendering engine does not help on a new OS. They would have to port all included engines to the new OS; alternatively, this IE10 would have to ignore all previous lock-in-strings? Or would a previously released engine like IE8 be emulated instead of included? But can an emulated engine match the bugs of the real one?

Updating the lock-in-string for a company’s site means new browser test cycles. Therefore, the lock-in-string will often be freezed in order to reduce costs, more probably than not. And why should a vendor develop an improved implementation with more CSS3 support if a growing number of industry pages is locked in to “IE=8; FF=4; Safari=4; Opera=10”? Currently, design decisions are made with the browser market share in mind. After the lock-in-invention, will these decisions be made with the latest lock-in-string-stats in mind? If so, will this cumulate to a “industry-standard-lock-in”?

Both articles have a hypothesis: that the lock-in won’t make assumptions for the future. In contrast, I think the assumption is that the lock-in will not break and that it will help improving the implementation of standards. Both remains to be seen. But you can’t go back once it is widely implemented.

posted at 02:43 pm on January 22, 2008 by Ingo Chao

10 Untitled

Not only could this make future IEs very bloated but also slower, as they will have to switch rendering to deal with separate sites or pages. The best thing Microsoft could do (in theory) is to drop IE altogether. Freeze it at IE8 and switch to Gecko, WebKit or Kestrel etc. This will be one huge change for many people (as it will likely affect all pages written solely for IE) but not for developers who have always coded for the common browsers in use today. Once that hurdle is over it will be much easier to code for a standard-based browser that isn’t decades old and full of bugs. Of course this won’t happen because it will mean Microsoft giving up control of their browser. But IE is already a patched-up antique. How much longer can they keep working on it before it simply belongs in the scrap yard?

posted at 02:58 pm on January 22, 2008 by Chris Hester

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)