- From: Justin Wood (Callek) <116057@bacon.qcc.mass.edu>
- Date: Tue, 31 May 2005 16:45:08 -0400
- 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