W3C home > Mailing lists > Public > public-html@w3.org > January 2010

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sun, 17 Jan 2010 21:53:48 +0100
To: James Graham <jgraham@opera.com>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Graham Klyne <GK@ninebynine.org>, Julian Reschke <julian.reschke@gmx.de>, HTMLWG WG <public-html@w3.org>
Message-ID: <20100117215348036454.1406d3d0@xn--mlform-iua.no>
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:

http://www.w3.org/mid/20100117084516139352.d8e3677c@xn--mlform-iua.no

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:

<OBJECT 
class="VIDEO" data-SRC="/fm/015.ogv" data-CONTROLS data-AUTOBUFFER
profile="http://w3.org/html5tests" > 
<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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:58 GMT