- From: Simon Pieters <zcorpan@gmail.com>
- Date: Fri, 13 Apr 2007 12:45:35 +0200
- To: "Matthew Ratzloff" <matt@builtfromsource.com>, public-html@w3.org
On Fri, 13 Apr 2007 06:10:07 +0200, Matthew Ratzloff <matt@builtfromsource.com> wrote: > 1. Provide no opt-in switch, but do not write the specification in such > a way that breaks content in Internet Explorer. This, in effect, means > adding to the spec the IE-specific bugs that at least 1% of websites > coded with IE in mind rely upon. This is IMHO what we should aim for. > + One specification governs all behavior; easy for authors Not only for authors, but also for UA developers, and new UA vendors trying to enter the market. > - IE bugs are introduced into the specification Why is this a problem? If all UAs agree on the same set of bugs, we have achieved interoperability, which is our aim here. > - Deprecating, removing, or otherwise specifying a change in usage > is severely limited No, it would not limit what we can deprecate, remove, or otherwise specify a change in usage at all. What authors have to do is completely orthogonal to what UAs have to do. e.g. we can forbid authors to use <plaintext> but still require all UAs to parse it in the same way. > 2. Make no allowances for browsers that do not comply with the standard > as specified. Require that these browsers implement their own opt-in > mechanisms (a la IE's conditional comments). > > + Specification does not inherit UA-specific bugs This is not a pro, since it would mean that we would never achieve interoperability between UAs on today's content. New vendors trying to enter the market would thus still have to reverse engineer another UA, which is what we're trying to eliminate here. In 500 years from now, it might not even be possible to reverse engineer today's browsers, and so it would be impossible to write a new browser from scratch, which means that today's content consisting of hundreds of billions of pages will go away into a black hole. > - Could ultimately result in Microsoft not implementing or only > partially implementing specification when spec differs significantly and > no clear way to opt in Indeed. > 3. Allow authors to peg pages to an HTML version. This might take the > form of a DOCTYPE switch, an <html version="5.0"> attribute, or some > other means. > > + Content will always render the same as it does today Same comment as your (2) pro above. > + Elements can be changed and deprecated as deemed necessary Same comment as your second (1) con above. > - If a rendering bug becomes prevalent and is subsequently fixed, is > the specification updated to account for this? HTML 5.1? HTML 5.2? I don't understand what you mean here. If we want to achieve interoperability on today's content, we have to specify the bugs today's content relies on (including quirks mode, IMHO). > - Introduces significant barriers to new browser development, since > browser makers must version their rendering engine Indeed. This is a major problem, IMHO (it already is a problem today -- let's not make it even worse by introducing even more rendering modes). > - What happens if a page specified for HTML 5 is later updated (as, > for example, by a different author) only to use a new element from HTML > 6, but has content dependent on HTML 5 rendering? In my world it would Just Work, just like if the content depended on quirks mode rendering. (<canvas>, an HTML5 feature, works fine today under an HTML 3.2 doctype in today's browsers.) > - IE conditional comments are still needed for compatibility with > older versions Until MS have completely and correctly implemented HTML5 (without versioning), they will need CCs. When they have, they might be able to safely drop them. CCs are powerful enough for authors to work around bugs in existing IEs, and they can do so without making assumptions about which bugs next IE will have. > 4. Allow authors to peg pages to the latest browser versions that the > page has been tested in and guaranteed to work with. This might take > the form of: > > <meta name="User-Agent" value="Internet Explorer 7.0" /> > <meta name="User-Agent" value="Firefox 2.0" /> > <meta name="User-Agent" value="Safari 2.0" /> > <meta name="User-Agent" value="Opera 9.2" /> > > In this case, it would obviously be better to peg it to rendering > engines and not browsers themselves, but that's probably asking too > much. AOL, Camino, Netscape, Konqueror, et al would just have to check > for the most common strings that match their rendering engine. > > + Content will always render the same as it does today Same comment as your (2) pro above. > + Elements can be changed and deprecated as deemed necessary Same comment as your second (1) con above. > - Introduces significant barriers to new browser development, since > browser makers must version their rendering engine Same comment as your second (3) con above. > - What happens if a page specified for Internet Explorer 7 is later > updated only to use a new element defined in IE 8, but has content > dependent on IE 7 rendering? Same comment as your first (4) con above. > - IE conditional comments are still needed for compatibility with > older versions Same comment as your third (3) con above. -- Simon Pieters
Received on Friday, 13 April 2007 10:45:40 UTC