Re: The harm that can come if the W3C supports publication of competing specs

James Graham, Sun, 17 Jan 2010 19:11:38 +0000:
> Quoting Boris Zbarsky <bzbarsky@MIT.EDU>:

>> Again, the early implementation isn't helping the spec quality here
>> much; we'll end up with two attributes for controlling buffering (or
>> possibly drop autobuffer from the spec altogether, of course).
> In this case the feedback that @autobuffer was a bad design came when 
> someone tried out an actual implementation and realised that it did 
> not meet their requirements.

Toby's D.E. proposal - elements and attributes defines via class names 
and @data-* names linked to a profile, could probably have come long 
way a solving this issue:

Such D.E. profiles language are be definition only supported by those 
UAs that support it, with no guarantees about the future whatsoever.

<video> implemented via a D.E. profile:

class="VIDEO" data-SRC="/fm/015.ogv" data-CONTROLS data-AUTOBUFFER
profile="" > 
<P><A HREF="/fm/015.ogv">Download video</A>.</P> </OBJECT> 

For authors that want it to work also when there is no profile support, 
they can also use the normal <param> elements etc, so that it also work 
in legacy apps. Experimenting and backward compatibility at once!
leif halvard silli

Received on Sunday, 17 January 2010 20:54:25 UTC