- From: Matthew Ratzloff <matt@builtfromsource.com>
- Date: Thu, 12 Apr 2007 21:10:07 -0700
- To: <public-html@w3.org>
Everyone,
There's currently a lot of back and forth on the list but very little
concrete has been laid out.
As I see it, these are four possible solutions to this problem of "opt-in"
rendering. I've added a few pros and cons--I'm sure others have more in
mind.
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.
+ One specification governs all behavior; easy for authors
- IE bugs are introduced into the specification
- Deprecating, removing, or otherwise specifying a change in usage is
severely limited
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
- Could ultimately result in Microsoft not implementing or only
partially implementing specification when spec differs significantly and no
clear way to opt in
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
+ Elements can be changed and deprecated as deemed necessary
- If a rendering bug becomes prevalent and is subsequently fixed, is the
specification updated to account for this? HTML 5.1? HTML 5.2?
- Introduces significant barriers to new browser development, since
browser makers must version their rendering engine
- 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?
- IE conditional comments are still needed for compatibility with older
versions
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
+ Elements can be changed and deprecated as deemed necessary
- Introduces significant barriers to new browser development, since
browser makers must version their rendering engine
- 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?
- IE conditional comments are still needed for compatibility with older
versions
Thoughts?
-Matt
On Apr 12, 2007, at 22:46, James Graham wrote:
> the only solution I can see is to force authors to specify their opt-in
> to the bugs and features of a particular UA using e.g. <meta
> name="ua-version" value="IE7"> to specify IE7+ should work in IE7 mode
> when rendering the document.
Received on Friday, 13 April 2007 04:09:44 UTC