Re: review of content type rules by IETF/HTTP community

On Mon, 20 Aug 2007, Sam Ruby wrote:
> 
> If there was such a header parameter, it will never be 100% respected, 
> but as long as (1) all compliant HTML5 browsers do, (2) the parameter is 
> chosen such that the possibility that existing content accidentally uses 
> it, and depends on it being misinterpreted is vanishingly small, and (3) 
> the default behavior without this parameter is what the current HTML5 
> spec is currently specifying; then if all three are satisfied, we should 
> all be happy.

The problem is the following scenario:

   Author Al hears about this new feature and puts it on his popular site.

   User Bob goes to Al's site and his browser works fine.

   User Bob upgrades to the latest and greatest browser and visits Al's 
   site again. Because the new browser now respects the new header, the 
   new browser renders Al's site in an inferior fashion.

   User Bob uninstalls the new browser and goes back to his old one (or 
   worse, from the vendor's point of view, goes to a competing one).

So I would add a fourth condition: (4) the parameter is chosen such that 
authors either won't use it until a very large proportion of the install 
base is conforming, or won't ever set it incorrectly.

Also, we have this problem:

   Author Al creates a site that uses this feature incorrectly, but in a 
   way that only hurts a minor part of the site (so that he doesn't 
   really notice and doesn't care to fix it if he does). (This happens 
   remarkably often. For example, many pages use CSS in ways that cause 
   problems at small screen widths, but the authors don't care.)

   Browser vendors A, B and C all see this problem but say "the site is 
   wrong, it's not our fault".

   Browser vendor D says "we will break the standard here, so that we 
   render this page better than the rest!". They implement an exception to 
   the specification, and render Al's site better than A, B, and C.

   User Ellen upgrades to D, finds Al's site renders even better than 
   before, and tells her friends to use D instead.

   Browser D gets lots of market share.

   Sites start unintentionally relying on this exception in ways that make 
   the site render fine in popular browser D, but not in browsrs A to C.

   Now, A, B, and C are all forced to break their implementation in the 
   specific way D did, just to remain competitive.

So I would add a fifth condition: (5) the parameter is chosen such that 
browser vendors cannot ever get a competitive advantage by not supporting 
it or by supporting it incompletely.

The problem is that I cannot see any solution that fulfills conditions (4) 
and (5) while still being a useful solution that fulfills (1)-(3).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 20 August 2007 20:15:30 UTC