Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
On Mon, 12 Mar 2007 01:01:38 +0100, Matthew Ratzloff [EMAIL PROTECTED] wrote: The Web has done great so far without it? When strict mode was introduced, all existing websites didn't suddenly start rendering under it. It was opt-in. Versioning is just a formalized way of opting into a certain rendering method. On 14/03/07, Anne van Kesteren [EMAIL PROTECTED] wrote: FWIW: Introducing strict mode has been quite painful and still is. Every time you encounter a rendering bug on some web page you have to check on what rendering mode the page relies (quirks, almost standards or standards) and then figure out what the behavior should be for quirks and almost standards by reverse engineering other popular browsers. Next time such a thing comes up we should just fix the specifications instead in my opinion to keep things predictable for authors and easy for implementors. Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 and more important the standard DOM, so they can avoid breaking pages on the web that assume the old iew tagsoup parser and quirky not-quite-standard DOM. One thing in particular - I don't think iew can at all change the events model to follow standard DOM in their compatibility-with-the-web mode. Other browsers evidently can work with standard DOM, so the spec isn't broken. It's just that Microsoft have painted themselves into a corner and need a way for authors to tell iew that their documents don't rely on their old proprietary DOM-tagsoup-CSS handling. The HTML5 spec doesn't even need to deal with that. If the spec provides a way for authors to sing their documents as not relying on old iew behaviour, all Microsoft needs is a hint from the developers, or the spec writers, that they can use that to switch. Other browsers can calmly carry on doing whatever they were doing before. I don't think Microsoft are asking for a versioning scheme, they don't intend to make a new locked down mode that needs replacing in the future. They already have a CSS switch, now they need a DOM switch to accompany that. With ie7 they proved they weren't afraid of breaking sites using the standards rendering mode in the name of improving their standards support on the CSS side, so in all likelyhood the DOM switch will similarly not require versioning. Microsoft absolutely REQUIRE this switch however. Without it there is no way for them to correct their behaviour even if all other browsers are doing just fine with complying to the standard DOM. This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. And I don't see any reason why !DOCTYPE html shouldn't be the switch seeing as developers are already used to DOCTYPEs as mode switches. -- David liorean Andersson
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
On Wed, 14 Mar 2007 16:16:49 +0100, liorean [EMAIL PROTECTED] wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 and more important the standard DOM, so they can avoid breaking pages on the web that assume the old iew tagsoup parser and quirky not-quite-standard DOM. [...] Oh, yeah, I think !doctype html would be a good switch for Internet Explorer to use if they indeed need such a thing in text/html (besides doing the sane thing in XML). I've suggested that to them in the past. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
Anne van Kesteren Wrote IE doesn't have a broken box model in standards mode. I was under the impression you wanted to throw out different rendering modes because they are difficult for implementors. If so, at least for IE (and presumably quirksmode in other browsers, since they tend to mimmic IE's quirks), there would be two box models that aren't reconcilable. Authors code against implementations, not specifications. Yeah, authors eventually end up doing browser testing, and, in that way, code against an implementation. However, I have to look at the specification to determine what is valid markup. It seems, according to implementations, that HTML, HTML-XHTML, and real XHTML all allow user invented tags. While they don't validate (validating is coding against a spec), the browsers I test on all rendered the content and applied CSS markup. Except for Safari in real XHTML, the element was added to the DOM and accessible with JavaScript. This seems roughly congruent with HTML specs[2], though I don't know if it is congruent with CSS specs and DOM specs. However, if I code against the implementation, not bothering to code against the specification (e.g. by validation or by looking at the specification), I can make up my own elements and have them render on the page. Since validation is a part of the web standards movement, I would say that authors worth their salt will code against both implementations and specifications. [1] http://whatwg.robertdot.org/files/20070314-invented-tags/ [2] http://www.w3.org/TR/html4/appendix/notes.html#notes-invalid-docs -- Robert http://robertdot.org
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
On 14 Mar 2007, at 15:16, liorean wrote: This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. Other browsers introduced quirks mode to match buggy behaviour of others – what's to say that won't happen here, so that other browsers have an IE/Win DOM mode, which would therefore require a switch? - Geoffrey Sneddon
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
liorean wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 and more important the standard DOM, so they can avoid breaking pages on the web that assume the old iew tagsoup parser and quirky not-quite-standard DOM. I think that is why they changed the subject of the thread. That thread is still available for discussion. I mentioned some versioning stuff that happened to strike a vein. The HTML5 spec doesn't even need to deal with that. I wholeheartedly agree. That is why I proposed an HTTP header that would be completely proprietary and controlled by Microsoft. It could be either a real header or a meta http-equiv tag. The only advantage to having some item in the HTML 5 spec is that it would be something authors already use, thus saving a few extra seconds to create the HTTP header. The disadvantage is that I think the IE team would want something they could apply to HTML 4 and XHTML documents as well. So, it'd have to be something backward compatible. I don't think Microsoft are asking for a versioning scheme, they don't intend to make a new locked down mode that needs replacing in the future. I don't think they are either. I was initially hoping to solve two problems at once (lack of versioning and the IE switch). After thinking on it, I came to the same conclusion as you: a IE-only switch shouldn't be part of any spec. A quick way to offer the deliverable is with an http header. It can be easily added to existing sites with .htaccess files, as well. This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. And I don't see any reason why !DOCTYPE html shouldn't be the switch seeing as developers are already used to DOCTYPEs as mode switches. It won't work as a switch if you want Super-Standards Mode in HTML 4 and XHTML documents. I know I want that option. -- Robert http://robertdot.org
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
liorean wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 On 14/03/07, Elliotte Harold [EMAIL PROTECTED] wrote: I could well have missed this, but has Microsoft actually asked for this? I didn't hear them ask for it, but I haven't read every message in the thread. Well, first note something Cris Wilson said on his blog. http://blogs.msdn.com/cwilso/archive/2007/01/10/you-me-and-the-w3c-aka-reinventing-html.aspx On error correction standardization – I disagree with this goal of the WHAT WG because I don't believe it is responsible for Microsoft to cause any unnecessary compatibility problems (e.g. the problems that would be caused if we changed error-handling behavior). If the WHAT-WG wants to standardize on EXACTLY what IE6 does for any given error case, no matter how funky it may be, great, but I don't think that's what they would consider doing. While not asking for it, that is a strong indication they cannot change the default handling, that this new handling has to be opt-in. Second, yeah, they've asked for it. See Chris Wilson's opening statement here: http://video.yahoo.com/video/play?vid=287660 I'd hate to add something for this purpose if Microsoft hasn't made a firm commitment to actually use it. Well, it's not a commitment, just asking for developers giving them the option. I do think it'd be most sensible to give them a hint that if they are to do it some way, [x] is the preferred way, even if the spec doesn't explicitly spell it out. But then we need to come to an agreement about what [x] should be. On 14 Mar 2007, at 15:16, liorean wrote: This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. On 14/03/07, Geoffrey Sneddon [EMAIL PROTECTED] wrote: Other browsers introduced quirks mode to match buggy behaviour of others – what's to say that won't happen here, so that other browsers have an IE/Win DOM mode, which would therefore require a switch? It won't happen because the situation is actually better on this point - DOM code either uses only interoperable things, or it already forks for iew on one side and standards DOM on the other. The competing browsers have already proven that they don't need that iew compatibility on the DOM side. The only browser that needs this new switch is iew, because it's the only browser that has to support both this proprietary DOM and the standards DOM. liorean wrote: I don't think Microsoft are asking for a versioning scheme, they don't intend to make a new locked down mode that needs replacing in the future. On 14/03/07, Robert Brodrecht [EMAIL PROTECTED] wrote: I don't think they are either. I was initially hoping to solve two problems at once (lack of versioning and the IE switch). After thinking on it, I came to the same conclusion as you: a IE-only switch shouldn't be part of any spec. A quick way to offer the deliverable is with an http header. It can be easily added to existing sites with .htaccess files, as well. Well, I have several issues with that: - First of all, that developers have low awareness of the HTTP side of the web. Most web developers are happily ignorant about HTTP headers, and even if they know about them, it's mostly limited to some specific problem, such as cache control headers. - Second, that we already have MIME type switching (tagsoup/XML modes), Content-Type: ...;charset=xyz switching (and corresponding meta element), various cache behaviour switching, and DOCTYPE switching. Please don't add yet another type of switch, just reuse the most practical one of those already present. - Third, it has to work when there's no HTTP headers, e.g. from network shares or the file system. liorean wrote: This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. And I don't see any reason why !DOCTYPE html shouldn't be the switch seeing as developers are already used to DOCTYPEs as mode switches. On 14/03/07, Robert Brodrecht [EMAIL PROTECTED] wrote: It won't work as a switch if you want Super-Standards Mode in HTML 4 and XHTML documents. I know I want that option. Something I'm very grateful for here, is that XHTML documents don't have this problem. There is no quirks mode in XML in any XHTML aware browser. And iew is not an XHTML aware browser. The super-standards mode will be the only mode available in XHTML douments. As for HTML 4.01 or XHTML1.0 as text/html, that's an area I disagree. The text/html media type is tagsoup for all browsers. A certain set of doctypes act as standards mode switches, but only as token strings, not by actually meaning the document conforms to
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
liorean wrote: Well, I have several issues with that: - First of all, that developers have low awareness of the HTTP side of the web. Most web developers are happily ignorant about HTTP headers, and even if they know about them, it's mostly limited to some specific problem, such as cache control headers. To deliver real XHTML, developers are supposed to know about content-type headers. I don't think it's asking too much of the upper-eschalon of web developers to add a header for IE. Of the ~50% of people (according to Chris Wilson) that have DOCTYPE, I'm sure there is a good portion that have it because the WYSIWYG editor put it there. Since those ship with the ability to create compatible designs, it's not an issue for them. For those that work in quirksmode or just copy/pasted in a doctype from a tutorial, it is certainly not an issue. Having the extra standards support is an issue for those of us who hand-code our sites. If someone is purposefully triggering standards mode, I would hope they had a clue about HTTP headers. - Second, that we already have MIME type switching (tagsoup/XML modes), Content-Type: ...;charset=xyz switching (and corresponding meta element), various cache behaviour switching, and DOCTYPE switching. Please don't add yet another type of switch, just reuse the most practical one of those already present. The problem is that there isn't a practical one to reuse. I would hope the IE Team would have been smart enough to think of looking for a complete DOCTYPE first. They asked for another opt-in (presumably other than the doctype opt-in). - Third, it has to work when there's no HTTP headers, e.g. from network shares or the file system. Real XHTML turns to tag soup when there is no header. This can have quite a few unexpected consequences when a real XHTML document is downloaded and viewed not-over-the-network. At least with an IE-only header, it would only affect viewing the page locally in IE (unless the meta http-equiv tag was present, then it should display properly). Something I'm very grateful for here, is that XHTML documents don't have this problem. There is no quirks mode in XML in any XHTML aware browser. And iew is not an XHTML aware browser. The super-standards mode will be the only mode available in XHTML douments. The fact that IE doesn't support real XHTML is why real XHTML* never gained critical mass. I don't think we'd be working on HTML 5 if IE would have had support for real XHTML, even if it was buggy / semi-quirky support. As for HTML 4.01 or XHTML1.0 as text/html, that's an area I disagree. The text/html media type is tagsoup for all browsers. A certain set of doctypes act as standards mode switches, but only as token strings, not by actually meaning the document conforms to any particular HTML specification. With HTML and fake XHTML, it is the job of the developer to make sure that code conforms to a particular specification. There are quite a few people out there who care about delivering well-formed, quality code, even if their page will still render when there are syntax errors. There are quite a few of us who aren't lazy (even if we make mistakes now and again). There is no meaning in those strings to any of the browsers, except for their triggering different rendering modes. HTML2.0, HTML4.01 of XHTML1.0 are all the same HTML if you ask the browser. This mode is just another one added to the set of modes provided by one particular browser. There is (and ought to be) meaning to the authors. The spec we are working on now will have a text/html serialization. When I start writing for HTML 5, I will do my best to conform to the spec by writing valid code, and will write well-formed code because I take pride in the work I do. I do the same thing with HTML 4.0 (and would do the same with fake XHTML if I didn't believe it was ideologically broken... instead I don't use it at all). Just because it renders with a tag soup parser doesn't mean I shouldn't be able to reap the benefits of better standards-based rendering in IE. So, it'd be super great if whatever switch the IE Team decides to use is backwards compatible. * When I say real XHTML, I mean XHTML served with application/xhtml+xml Content-type headers. -- Robert http://robertdot.org
