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

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

From: Brad Pettit <bradp@microsoft.com>
Date: Tue, 31 May 2005 18:25:58 -0700
Message-ID: <5B78805D3185784993C473999029D7360450AFA8@RED-MSG-53.redmond.corp.microsoft.com>
To: "Jim Ley" <jim@jibbering.com>, <w3c-html-wg@w3.org>, <www-html@w3.org>
Cc: <xhtml2-issues@mn.aptest.com>

What if the Xhtml document is not well-formed? Even a non-validating Xml
parser is required to check for well-formedness before determing whether
the document is xml:
http://www.w3.org/TR/2000/REC-xml-20001006#sec-conformance 

Document well-formedness -- or the lack thereof -- might not be
determined until the end of the content is reached. Is it wise to be
executing <object> elements -- particularly those that reference code
external to the browser -- as they are encountered during the process of
loading a potentially incomplete or incorrect document? 

Formally specifying that no <object> elements are executed until the end
of the document is encountered and well-formedness is determined
contributes to the standardization of browser behavior, making behavior
more predictable, increasing testability and contributing to security.

Please note that I'm differentiating between the optimization of
pre-loading resources referenced by the object vs executing external
code for one.

--Brad Pettit
--Microsoft Corp.

-----Original Message-----
From: Jim Ley [mailto:jim@jibbering.com] 
Sent: Tuesday, May 31, 2005 11:51 AM
To: Brad Pettit; w3c-html-wg@w3.org; www-html@w3.org
Cc: xhtml2-issues@mn.aptest.com
Subject: Re: [XHTML 2] 24.1 OBJECT declare and "completed loading"
(PR#7751)

>"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. 
Received on Wednesday, 1 June 2005 01:26:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:19:03 UTC