W3C home > Mailing lists > Public > www-html@w3.org > May 2005

Re: [XHTML 2] 24.1 OBJECT declare and "completed loading" (PR#7751)

From: Justin Wood (Callek) <116057@bacon.qcc.mass.edu>
Date: Tue, 31 May 2005 16:45:08 -0400
Message-ID: <429CCCD4.8070802@bacon.qcc.mass.edu>
To: Jim Ley <jim@jibbering.com>
CC: Brad Pettit <bradp@microsoft.com>, w3c-html-wg@w3.org, www-html@w3.org, xhtml2-issues@mn.aptest.com

Jim Ley wrote:

>> "Brad Pettit" <bradp@microsoft.com>
>>>> Please remove the requirement that the document be completed loading
>>>> before a declare="declare" object can be executed
>> At what time do you propose the object execute? What if the object being
>> being executed references the DOM of the document that has not finished
>> loading? Additionally, since rendering of fallback content for objects
>> is dependent on whether outer objects have failed, nested objects that
>> have been merely declared should not be executed until their outer
>> content has failed loading.
>> Do you have a scenerio where the execution is necessary?
> The scenario is simply consistency, consider a document containing:
> <object id="video" declare="declare" ... a video ... />
> <a href="#video">Play Video</a>
> Here, the user will see the Play Video document as the document is 
> loading with progressive rendering, but nothing can happen until the 
> document has finished loading.   This won't be obvious to users, why 
> activating the play video link doesn't do anything whilst the rest of 
> the document is loading.
> The nested object argument is indeed an interesting one, and one I 
> cannot see easily reconcilable, but I can't see a use case when an 
> author would do it:
> <object >
> <object id="a"/>
> </object>
> <a href="#a">Activate</a>
> The Activate link will again do nothing, unless the first object is 
> unavailable (although I don't believe the spec is completely clear on 
> this), again the problem here is a consistency, and utility, it's not 
> good to have links which do nothing.
> I can see 3 ways of ways of resolving this, remove the functionality 
> to activate declared objects via links, returning it to the domain of 
> scripting as it is in existing clients, not good from functionality, 
> but good from a perspective of simplicity of specification.
> Modify the activation rules, such that <a href="#a" causes the 
> document to refresh itself and then activate the object onload, bad 
> for functionality, but as this would often be combined with scripting 
> in real browsers it's good fallback functionality.
> Add an attribute to the OBJECT such that the author can suggest if it 
> can be activated before the document is loaded, and add a conformance 
> requirement that the UA style any links to ones that can't be in a 
> disabled state until the onload event fires.
> This last one is my favourite.
> Cheers,
> Jim.
Regarding the last one, how would you be able to "define" this;

<a href="#notAvalidFragment">foo</a>
<a href="#object1">Activate Some Object Defined Later in Document</a>
<object id="object1" declare="declare" ... a video ... />
<object id="object2" declare="declare" ... a second video ... />
<a href="#object2">Activate Some Object Defined Earlier in Document</a>

The Object 2 link seems the only one which could be "reliably" disabled 
*as the document loads*, sure depending on relative placement of the 
Object 1 link, and Object 1 itself, it may be possible to assign the 
disabled flag to Object 1's link as well, but is near-futile;  The links 
will still be _there_ though they do not necessarily have to target any 
real fragment.  [Though a real fragment is good practice]

~Justin Wood (Callek)
Received on Tuesday, 31 May 2005 20:45:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:10 UTC