Re: [whatwg] <video> element feedback

On 3/29/07, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> The URL parameter (as also seen in e.g. Quicktime and Flash) is imho a
> dirty hack to work around implementations not providing plugins with a
> streaming file reader object. At least, that is the only explanation I
> can come up with. There is a DATA attribute on the object, and that
> should be sufficient.

There are a few problems with data for OBJECT and src for EMBED.

1. The plugin doesn't always support those params for a file resource
and browsers have to hack in support on a per-plugin basis to make src
/ data work (if they choose to).

The java plug-in, tcl plugin, wmp plugin, neptune plugin, videolan
plugin, tcl plugin and the Real plugin all don't support a data param
by theirselves.

2. They cause the browser to automatically download the resource.


A plugin should support 3 different params for specifying a source file.

'data' to cause the browser to automatically download the resource via OBJECT:
<object data="file.ext"></object>

'src' to cause the browser to automatically download the resource via EMBED:
<embed src="file.ext">

'another_param' to prevent the browser from automatically downloading
the resource if a autoplay (for example) param is set to false:
<object type="type">
    <param name="another_param" value="file.ext">
    <param name="autoplay" value="false">
</object>
object.play() starts the downloading.

<embed type="type" another_param="file.ext" autoplay="false">
embed.play() starts the downloading

(The effect of another_param could be simulated by just writing out
the whole object with JS when ready, but ...)

Anyway, with a VIDEO element, that stuff wouldn't be a problem as it
can be dealt with specifically as opposed to OBJECT where you have to
worry about all the existing behaviors.

-- 
burnout426

Received on Sunday, 1 April 2007 11:46:31 UTC