W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Removing the data attribute on <object> (detailed review of Semantics)

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Tue, 28 Aug 2007 08:43:22 -0400
Message-ID: <6b9c91b20708280543r29618336m3fb5d96189bae492@mail.gmail.com>
To: "Simon Pieters" <simonp@opera.com>
Cc: public-html <public-html@w3.org>

On 8/22/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:
> Does this also apply when the data (or type) attribute is removed? If so,
> please state that explicitly.

I think it should at least.

Further, I would say it more like:

"Whenever the data or type attribute is added, changed (even to the
same value) or removed, the user agent must follow the following steps
to determine what the object element represents:"

Note that currently, there's little support for reloading the object
in browsers on type and data changes. Even more, it's definitely not
the same across the board, so reloading on data and type changes would
mostly be a new feature.

Rationale for "(even to the same value)":

<object type="plugin_a">
    <param name="file" value="1.ext">

obj.getElementsByTagName("param")[0].setAttribute("value", "2.ext");
// Now, let's reload the object so plugin_a loads 2.ext instead.
obj.setAttribute("type", "plugin_a");

I'd rather just have an obj.evaluate() function than to mess with data
and type changes (especially for the example above where setting type
to the same value or removing type and adding it back in or changing
it to something else and then back seems silly).

Or have both where data and type changes invoke obj.evaluate(), but an
author can call it explicitly if wanted. Whatever's best and easiest
to implement though.

Received on Tuesday, 28 August 2007 12:43:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC