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)