- 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>
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 UTC