Re: <object data type> when type is unsupported (detailed review of Semantics)

On 7/27/07, Simon Pieters <simonp@opera.com> wrote:
>
> (This is part of my detailed review of the Semantics and structure of HTML
> elements section.)
>
> The spec says about <object>:
>
>     Whenever the data attribute changes, or, if the data attribute is not
>     present, whenever the type attribute changes, the user agent must
>     follow the following steps to determine what the object element
>     represents:
>
>       1. If the data attribute is present, then:
>
>            1. Begin a load for the resource.
>
>               The download of the resource must delay the load event.
>
> Shouldn't UAs be allowed to opt to not begin load for the resource when
> type="" is something that the UA knows is unsupported? (Or perhaps it
> should even be required to not begin load for such resources.)

I see it like this:

If you change type or data (even to the exact same value, just in case
you want to reload the same handler), or add type or data or remove
type or data, the UA should kill the current object and reevaluate the
nodes of the OBJECT to load the new handler. Then, the UA would load
or fall back just like it would with a non-reevaluated OBJECT.

However,

Reloading the handler (native or plugin) when type or data changes
doesn't really work much in browsers now. I assume this behavior is
supposed to be new? (  as opposed to describing current behavior)

Currently, if you modify an existing OBJECT, you have to yank it out
of the document and put it back in (via parentNode.innerHTML =
parentNode.innerHTML or other dom method replacement) to get the
browser to reload the handler and use the new, modifed version of the
object.

Try taking
<object type="application/x-java-applet" width="200" height="35">
    <param name="code" value="MyJavaClass">
</object>

Then, use setAttribute to modify code -> FileName and value ->
file.wmv or something. Then, use setAttribute to change the type to
application/x-mplayer2 for example.  Nothing will happen.

Instead of monitoring type and data for triggering a reload of the
handler, I'd rather just have an OBJECT.evaluate() method. That way,
when I'm done modfiying the nodes of the object, I can explicitly call
for an evaluation of the OBJECT.

It's kind of annoying to have to yank an OBJECT out of the document
and put it back in when all you want to do is change it and reload it.
With something as complex as OBJECT, solving that by triggering a
reload based on data or type changes seems a little off when an
evaluate() is what one really wants.

Of course, if browsers can make it work with data and type changes, I
guess that's good. I just think that the reload has to happen whenever
data or type is added or removed or changed (even to the same value).

Put simply, if you do *anything* with data or type on OBJECT, it
should kill the current object and cause a reevaluation.

-- 
Michael

Received on Saturday, 28 July 2007 01:43:36 UTC