- From: Sander Tekelenburg <st@isoc.nl>
- Date: Sat, 21 Apr 2007 04:58:44 +0200
- To: <public-html@w3.org>, <wri-talk@webrepair.org>
At 15:05 -0700 UTC, on 2007-04-20, Chris Wilson wrote: > Sander Tekelenburg wrote: >>Do you agree with my earlier analysis[*] that a proprietary switch would make >>it much harder for authors to produce conforming web pages? If so, can you >>explain why this should be acceptable? > > I guess I don't know what you mean by a conforming switch. I didn't say "conforming switch". I said "proprietary switch", quoting you. So I don't understand what you're asking me to clarify. I did say "conforming web pages". If you mean to ask what I mean with that, then: "a HTML document that is in conformity with the HTML spec". For clarity's sake I'll restate what I'm asking you to explain: +++++ If you insist on [1] requiring authors to explicitly opt-in to IEn standards mode, and [2] the switch for that to be conforming but proprietary, then unless I'm missing something, that means that for authors to opt-in to IEn standards mode they cannot rely on a HTML conformance checker to warn them if the opt-in switch in their HTML is not compliant with IE's propietary "opt-in switch standard". A conformance checker cannot check something that isn't specced. So a proprietary switch makes it much harder for authors/authoring tools to produce conforming HTML documents that trigger IE standards mode. Similarly, authoring tools (which don't necessarily contain conformance checkers) cannot know how to trigger IEn standards mode if that switch is not specced. If you disagree with this analysis, please explain why. But if you agree with it, please explain why it should be acceptible to make authoring that hard. (In case it isn't obvious: note that although hiding a proprietary switch in HTML comments would allow the HTML document to be conforming, it would still be impossible for a conformance checker to verify the conformity of a non-specced switch.) +++++ If IE's proprietary switch would make a document *non-conforming*, that would be even far worse, because it would force authors to choose between producing a conforming document that triggers IEn non-standards mode, or a document that triggers IEn standards mode but is non-conforming. But that would be so insane that I don't believe that that's what you are aiming for. >>> (If there are no breaking changes, we don't need to worry about this. >>>That is unlikely to happen for quite a while.) >> >>I can't follow. "breaking changes" in what? "worry" by whom about what? > > Breaking change in our behavior. Changes that cause differences in >rendering, object model or interactive behavior. OK. I assume "our" refers to IE. (You're often saying "we", "us", "our" without making it clear if you've got your Microsoft or HTML WG chair hat on. That's confusing.) >>> I want the HTML spec to have version - e.g. in DOCTYPE - because I 1) think >>>it's insane to build a format with no version identifier, and 2) will >>>opportunistically use this to automatically turn on any future opt-ins when >>>such a version identifier becomes popular. >> >>I'm afraid I cannot follow this either. Could you elaborate please? [...] > > Part 1 or 2? Both part 2 and the preceding "e.g. in DOCTYPE" -- it's not clear to me what the status of your "e.g." is. Given that many strongly oppose versioning the doctype, what specific other possibilties for a specced opt-in switch would you be willing to consider? -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Saturday, 21 April 2007 03:08:46 UTC