W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Versioning and html[5]

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Tue, 17 Apr 2007 16:28:51 -0400
Message-ID: <46252E03.2090901@vectoreal.com>
To: Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org>

Hi, Jonas, all-

First, let me thank Jonas for his gentlemanly post.

Jonas Sicking wrote:
> 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.

Whenever I hear "Don't Break the Web", I think of "Support our Troops" 
or "Think of the Children".  Sounds great in principal, but it boils 
down to what the speaker is truly asking for.  Slogans are messy that way.

> 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.

Yes, even if we don't break the Web, can we at least bend it a little? 
Maybe a minor sprain or a flesh wound?

> 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.

Which is why specs which we want implemented should reflect the needs of 
the vendors that contribute to the process.

> 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.

Hear, hear.  I've heard people claim loudly that they know what users 
want, but they only know what they've heard (which is not necessarily 
what was said), not what the silent majority grumbles quietly about.

> 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.

As would I.  I suspect I missed the part of this discussion where <html 
version="5.0"> was roundly dismissed as completely unworkable... could 
someone please enlighten me why that's a problem?

Personally, I would rather do away with DOCTYPEs completely, and express 
the language in RelaxNG, but I suspect that's a bridge too far.  Perhaps 
we could allow the switch to be triggered by a funny new DOCTYPE *or* a 
root attribute?

> 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.

This is especially true of new UAs.  I can see a true market use case 
where authors and users might never encounter Ye Olde Webbe (HTML<5), 
and so the UA would not need to implement anything but HTML5.  Mobiles, 
set-top boxes, kiosks... all of these might be limited in accessing a 
subset of total Web content, and there's nothing wrong with that.  We're 
not talking the walled gardens of WAP and AOL, because normal desktop 
browsers could access the same content... it's the same Web, just 
optimized for certain device profiles.

But leave that out of it, if you just can't stand the notion that the 
market is moving toward single Web for all devices (but if you care to 
make a side bet, contact me offlist).  Mozilla, Opera, and Apple have 
all chimed in that they want to offset Microsoft's 800lb-gorillatude... 
but these guys are huge too, with large existing code bases.  What about 
the browser vendors just starting out?  A simple, coherent spec would 
aid them tremendously.

And don't tell me authors wouldn't love dropping their old kluges and 
known evils for a most consistent development experience, because they 
are doing so in droves.  Look at the popularity of Dojo, Prototype, et al.

The smattering of developers I've asked think it's brilliant to start 
with a cleaner base allowed by versioning.  I've heard no technical 
reason not to do so, only market reasons, and I think those are speculation.

> 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.

+1 (this 1's for you, Anne).

Received on Tuesday, 17 April 2007 20:29:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:19 UTC