- From: Shadow2531 <shadow2531@gmail.com>
- Date: Sun, 1 Apr 2007 07:46:27 -0400
On 3/29/07, Laurens Holst <lholst at 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 04:46:27 UTC