Re: Versioning and html[5]

On Thu, 12 Apr 2007 18:40:07 +0200, Chris Wilson
<Chris.Wilson@microsoft.com> wrote:

> [...]
>
> Håkon then  
> said<http://lists.w3.org/Archives/Public/public-html/2007Apr/0339.html>,  
> in response to the same thread: "Standards are like vaccination -- it  
> hurts a bit, but it's better in the end."  That would seem to imply an  
> expectation we would break the web as it is rendered today in IE.

I don't think anyone in this WG expects any browser vendor to break the
Web. If implementing some part of the spec breaks the Web, then that is a
bug in the spec, and should be changed so that it doesn't break the Web.

> Those statements belie the ideal that Anne  
> stated<http://lists.w3.org/Archives/Public/public-html/2007Apr/0405.html>  
> when he said "yes" to Henrik's  
> question:<http://lists.w3.org/Archives/Public/public-html/2007Apr/0404.html>  
> "Let's say someone wants to create a 100% compliant browser completely  
> from scratch, guided *only* by HTML5 and other standards external to  
> HTML and with no prior knowledge of the functionality of current  
> browsers.  Should this browser then be compatible with 'today's  
> content'?" - if you require the market leader to break compatibility,  
> then you simply are NOT defining the standard of "today's content".

Indeed. Let's instead define something that is implementable without
breaking today's content.

> [...]
>
> So, that sucks.  I don't want every other browser (and every browser to  
> come) to have to implement IE's bugs.
>
> [...]
> I also don't want to bake IE's poor behavior in some cases into the  
> standard -

If today's content rely on them, then why not?

> that would mean EVERYONE should have the hasLayout() side effects,

Does hasLayout have side effects that would affect the HTML spec?

> choose not to quote <q>, etc.

I would be fine with that, FWIW.

> [...] I'm frankly somewhat ambivalent about how much IE-ism we take into  
> the standard, because it won't be exactly IE7's behavior, and therefore  
> can't replace our current behavior when faced with text/html - because  
> we can't Break the Web.

If the defined behavior would be as close as IE7 as possible while still
not tampering with other specs (in particular DOM and CSS), and wouldn't
break the Web (to the extent possible), then what is the problem? (If
implementing DOM or CSS would break the Web, then issue the WebAPI or the
CSS WG, respectively.)

> I believe we (the WG) need to build a web we all believe in, starting  
> from where we are, make sure it's downlevel-compatible with the current  
> web (HERE's where the XHTML 2.0 effort screwed up, both in the details  
> and in the mime type issue), and watch the current proprietary things  
> rot away in usage.

Agreed.

> However, you need to understand that you can't ask the market leader  
> (and given some of my private conversations, even other UAs) to change  
> the details of what they're shipping today, without causing immense and  
> unnecessary pain to their users and developers.

It may be necessary anyway should you want to conform to other specs, such
as DOM and CSS. (If you don't care about conforming to other specs, like
other browser vendors do AIUI, then I understand why you wouldn't want to
change your behavior, but I don't understand why you would want to
conform to this spec while not conforming to others. In any case,
implementing HTML5 should make you more conformant to DOM at the same
time.)

> [...]
>
> There are some here who are suspecting that I'm suggesting that other  
> browser should implement the standards, and IE will remain the only  
> browser that implements the "real web" - that is, the web laden with  
> errors due to IE bugs.

I think the intent is that a browser implementing the spec would work with
the "real web" (which means IE bugs are specced, many are already in
WHATWG's HTML5 proposal). Again, if that's not the case, it's a bug in the
spec.

> For example,  Ian  
> said<http://lists.w3.org/Archives/Public/public-html/2007Apr/0329.html>,  
> in response to me saying that we could not change how IE7 renders  
> floating content even though we know it's wrong because it would break  
> the web: "How do the browsers that handle floats more correctly cope  
> with this? Do they misrender half the Web?"
>
> In short, no, because I don't think half the web misuses floating - but  
> let's say 1% of the web does misuse float - that's a significant  
> blocking problem for us,

I presume that it is a serious blocking problem for other browser vendors
too.

> as that is hundreds of thousands of web sites that we've broken.  But  
> it's not for others, for the most part, because typically Web developers  
> today write content to standards, then patch it work in IE under an IE  
> switch - so if we fix our bugs, the patches no longer work and now  
> damage the site, because authors are EXPECTING us to be broken.

It depends on what switch is used. Authors can use <!--[if lte IE 7]> and
then you could still fix your bugs in IE8. (If you don't, then they would
have to update their CC.) I get your point though, and it's sad that their
expectation of IE doing things wrong prevent you from fixing bugs. If you
do fix bugs and update regularly then perhaps authors' expectations
changes over time.

> But, of course, other UAs are just fine, either way.  So what's a market  
> leader to do?  You're suggesting that the HTML WG gets to pick and  
> choose what the market leader breaks compatibility with - in fact,  
> you're trying to give them (us) no choice.  I note, for example, that  
> the WHATWG HTML5 removes a few key attributes from the <object> element  
> that were in HTML 4.01 - namely, classid and codebase - that are heavily  
> used by ActiveX in IE.

Could you elaborate on how the current definition of <object> wouldn't be
implementable in IE, and what you would need in order for it to be?

> (And y'all seem to get quite upset when we add proprietary features and  
> attributes.)

Innovation is good, but sometimes it's better to bring it to the table and
discuss it in the WG and get it specced and implemented at the same time,
than first being implemented and then reverse engineered and then specced.

> Unfortunately, the problems with this sort of change are rampant, and  
> frequently (unlike the ActiveX example) they are quite small.  Boris  
> said<http://lists.w3.org/Archives/Public/public-html/2007Apr/0334.html>:  
> "...I'm not suggesting you [break sites] gratuitously.  ...I frankly  
> wouldn't expect significant numbers of pages to depend on any particular  
> UA's behavior [in corner cases]."  You're incorrect in your  
> expectation.  Developers (and even more importantly, users, who mostly  
> don't think to care about standards anyway) care about consistency.   
> Whitespace handling is different in IE today?  Bummer.  Sorry.  We broke  
> pages when we tried to change it in days of yore.

Is this something the HTML5 spec says anything about (parsing)? What would
you need the spec to say instead?

> [...]
>
> I believe our (IE's) only tenable answer (to satisfy the goals of 1)  
> don't break the web, and 2) improve our standards compliance) is that we  
> must require that document authors opt in to standards compliance.

This doesn't help to get interoperability on today's content,
unfortunately.

> [...]
>
> But wait, you say, Chris that sucks!  That means the incorrect behavior  
> is the default!  Yeah, I know.  Like I said, I don't like it.  Show me  
> another way to not Break the Web.  But wait, there's another way too -  
> the BEST thing for us, then, (and now I'm talking about Microsoft AND  
> the WG) is to have new DOCTYPE identifiers occur every so often (where  
> "every so often" trends to infinity, as implementations get more and  
> more compliant), because then we can automatically opt that content into  
> whatever our current "most compliant" behavior is.  Despite Anne  
> thinking<http://lists.w3.org/Archives/Public/public-html/2007Apr/0337.html>:  
> "standards mode and quirks mode is an unfortunate thing from the past,"  
> it is actually quite a great invention, in my opinion; it allowed us to  
> automatically use more standard-compliant behavior without Breaking the  
> Web.

The net effect though is that any new browser has to implement both quirks
mode and standards mode in order to render the Web. In my opinion it
would have been better to specify the quirks mode back then, make that
compliant, and only have one rendering mode. Then it would be easier to
write a new browser from scratch. It's too late now though, but it's not
too late to not introduce even more rendering modes. (i.e., change the
specs to be compatible with the current Web instead of introducing a new
rendering mode to implement a spec that is incompatible with the Web.)

> Unfortunately, "standards mode" is too widely adopted now, and we break  
> too much compatibility if we change our UA behavior there,

Indeed.

> so its time has come.

I don't understand this part.

> I think some of you (WG members) are thinking I'm saying we (the WG) can  
> use that as a free license to break backward compatibility with current  
> systems, as if we were the XHTML 2 group.  That is NOT true.  I don't  
> believe in that path of development for HTML.

I don't, either.

> I just don't think that we can change what "current systems" mean - and  
> if you believe we can, then I would hold up that IE is still the browser  
> for oh, let's call it three quarters of web users worldwide, and was up  
> around 95% a few short years ago - meaning a lot of current web content  
> was authored to IE's behavior - so I believe in the interest of your own  
> claimed tenet (representing the current web), you would have to say that  
> IE defined the standard.

Indeed.

> Y'all better get working on that ActiveX support.

AIUI, ActiveX would only work under Windows, so that wouldn't be realistic.

> (And no, I'm not seriously claiming that IE should or must define the  
> HTML5 standard.  But I do believe IE, far more than anything else,  
> defines the de facto "current web content" specification standard, for  
> better or worse.)

I do believe HTML5 should define "the de facto "current web content"
specification standard". If that means doing what IE does, then so be it.

> [...]
>
> The Microsoft IE team is committed to implementing standards  
> compliance.  At the same time, we can't change current behavior for  
> current content.  That paradox requires us to require authors to opt in

...or we define the spec in a way that you can implement without authors
having to opt in.

> [...]

-- 
Simon Pieters

Received on Thursday, 12 April 2007 19:06:26 UTC