Re: Microsoft versioning proposal

Preston L. Bannister wrote:
> On 4/18/07, *Dannii* <curiousdannii@gmail.com
> <mailto:curiousdannii@gmail.com>> wrote:
>     It seems to me that freezing behaviour and long release cycles has
>     been proved to work badly. I'd prefer to see more frequent releases
>     of IE, even up to every six months, releases that implement the
>     specs in stages. If people understand that the few bugs will be
>     fixed soon, they will be less likely to start depending on those
>     bugs or serve IE different content. They'll start expecting IE to
>     work as well as any other browser, which is something I think we all
>     want.
> 
> Oh, please no. :)  Long release cycles are a very good thing, when it
> comes to changing behavior.  Lots of frequent changes mean lots of
> slightly-different browser versions in use.  Lots of slightly-different
> behaviors mean the web application developer's work becomes much harder.

   While that may be true in extreme cases, IE6 was the opposite
extreme. Internet Explorer 7 is significantly easier to write pages for
than IE6 (although Microsoft still has a ways to go before you can just
write a standards-compliant page and have it work like you can in
Mozilla and Opera).

   Browser vendors need to release stable products, but they also need
to fix issues with their browsers as these issues arise. Allowing too
much time between products encourages hacks and exploitation of bugs
because, in that scenario, the bugs and hacks can be relied upon more
than the standards can.

> In fact much of the current wealth of new web applications is in part
> enabled by the fact that Netscape 4 faded out, and IE (in the form of
> IE6) was unchanged for so long.  Fewer differing targets mean the web
> developer can spend more time being creative, and less time in testing.

   Actually, it's because other browser vendors implemented
XMLHTTPRequest, thus allowing AJAX applications that work in most browsers.

> Intermediate releases for security/crashing bug fixes can be frequent. 
> Releases with changes in behavior should be infrequent.

   Again, somewhat true, but the span between improvements in behavior
should not be on the order of multiple years or decades. Mozilla seems
to to a good job with this. Major versions tend to be released about a
year apart, with months of prior alpha and beta testing before release.

> If your concern is with how closely IE-next implements HTML-next, if we
> want all browser implementations to converge on a single common standard
> in as few iterations as possible, then our collective interest lies in
> crafting an as-best-we-can-make-it set of validation tests that all
> browser implementors can use.

   As nice as it would be to have a perfect spec with a perfect testing
suite before-hand, I just don't see it happening. Browser vendors are
going to implement the features that their users demand. The best we can
do is to fast-track these features so that they are relatively stable in
 the earliest HTML5 drafts.

Received on Monday, 23 April 2007 02:05:18 UTC