Re: Versioning and html[5]

Hi all,

I must say, this thread has been quite an entertaining read so far. But
far too time consuming for me to read it all, so apologies if
conclusions has already been reached on these topics.

First off, hats off to Chris, he's had to take more abuse here than
anyone deserves, without blowing up. We're a friendly group here at
mozilla, let me know if you need moral support ;)

So on to the real contents of this mail:

On breaking the web:
The "Break the Web" phrase is commonly used here at mozilla too. However 
it seems to mean something slightly different for us than it does for 
microsoft. I am actually prepared to break a few pages for a number of 
reasons. For example to fix standard compliance bugs, make behavior more 
logical in the common case, fix security issues, or simply kill code 
that shouldn't have existed in the first place.

However in all above cases it's a cost/benefit trade-off. If the number 
of users being affected by a change is almost 0 I'm fine with killing 
even a public API even if the only immediate benefit is a few less lines 
of source code. But if it's going to break millions of sites that users 
use daily then an incompatibility with a standard is something we might 
have to live with. Both these have happened in the past. (Security would 
be an exception here, no matter how many sites will break we'll have to 
fix a security hole. But we'll work harder on finding a less invasive 
fix if the original fix breaks many sites).

Microsoft seems to have stricter policies here about not breaking 
existing pages. I think that's fine. It has to be up to each vendor what 
priorities to make here. Especially since vendors are going to follow 
their policies anyway, no matter what the spec says.

It is my experience though that authors are a lot louder when 
complaining about changed APIs than they are when they are thanking you 
for a less buggy APIs to develop their web apps on.

Ultimately I think we'll have to deal with switching mechanisms though. 
Mozilla currently only has two major (and one "minor") modes and 
hopefully we'll be able to stick to that for a long time to come.
But I think we should assume that more modes might happen in the future, 
so it would be good if the spec had some way of dealing with this.

That said, I really like the <!DOCTYPE html> "doctype" since it's very 
short and easy to remember. So I'd probably lean towards adding a 
version attribute to the html element.

On purpose of the spec:
I do not believe that we can write the html5 spec such that implementing
it alone will be enough to support every page on the web. The simplest 
reason is that I don't think it is possible to write a browser that 
supports the full web. Currently some pages work only in IE6, other 
pages only work in Firefox 1.5, and so on.

What I think we need to do is to find a good compromise.

If we make the spec cover too many current pages the spec will be 
horrible to read and author to and a royal pain to implement. By 
sacrificing a little compatibility I think we'll have a better spec both 
for authors and implementors. Again, a browser doesn't have to render 
every page out there in order to be competitive.

To sum up:
All decisions we make with regards to compatibility with existing pages 
and browsers are going to have to be compromises. There's no way we can 
come up with an absolute answer that works in all cases. For each case 
that comes up we have to judge how much it complicates the spec to add 
it, versus how many pages won't work if we don't.

Having some sort of versioning (and even <DOCTYPE html> is a form of 
versioning) seems like a good idea if it helps move more people to a 
newer version. However we have to make sure that whatever we propose 
will work in reality.

Best Regards,
/ Jonas

Received on Tuesday, 17 April 2007 19:23:14 UTC