W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-61: text for Window and ReferencingElement

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 24 Mar 2006 21:46:24 -0800
Message-Id: <C8A642A3-898F-4CA0-84F6-9044752CDB3B@apple.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
To: Anne van Kesteren <annevk@opera.com>

Hi Anne,

This looks great! And sorry for taking so long to give you feedback.

I am going to fold this in (my last task before I think Window 1.0 is  
ready for a very rough working draft), but I think am going to change  
a few technical aspects. Let me know if you have any thoughts on this:

On Mar 20, 2006, at 11:03 AM, Anne van Kesteren wrote:

> More improved text:
> ===
> An element that refers to another document that is then embedded is  
> called a <dfn>referencing element</dfn>. A document such an element  
> points to is called a <dfn>child document</dfn>. Seen from a child  
> document, the referencing element is part of a <dfn>parent  
> document</dfn>. When a document has no referencing element that  
> points to it the document is a <dfn>root document</dfn>. A document  
> can be both a parent document and child document at the same time.

- I will change the term from "referencing element" to "embedding  
element". The reason is that "reference" could refer to a wide  
variety of things. The name "referencing element" seems like it  
should apply even to external references that don't embed a document,  
like <a href="otherdoc.html"> or <script src="foo.js">, and neither  
of these is a "referencing element" in the sense relevant here.  
"Embedding element" seems to more clearly scope it to something that  
incorporates an external document.

- I think this explanation would be enhanced by using the concept of  
"browsing context", which I believe was invented by Ian Hickson and  
which I used in Section 2. Terms like "top-level browsing context",  
"nested browsing context", "parent browsing context" etc can help  
make it a little more abstract than just documents and windows, and  
allow a more precise definition of how the documents and windows  
relate. But I won't change any of that in the first version of  
incorporating your changes.

> <code>Window.frameElement</code> from a child document MUST reflect  
> the referencing element or <code>null</code> if there is no such  
> element.

I think instead of the term "reflect", we want to write things more  
like "The value of the frameElement attribute MUST be the referencing  
element for this window's browsing context, or <null> if there is no  
such element." Similarly for all the text below.

> <code>Window.parent</code> MUST reflect the parent document  
> <code>Window</code> object or <code>Window.window</code> if there  
> is no such document. <code>Window.top</code> MUST reflect the root  
> document <code>Window</code> object. Some language specific  
> bindings allow these DOM attributes, even though readonly, to be  
> set to different values. In such cases the attributes simply  
> reflect the values set by the script author.

I think replaceable properties can be described solely in the  
ECMAScript bindings appendix, I'll put the relevant part of your text  

> ISSUE: This does not deal with security. Security should probably  
> be taken care of in a separate part of the specification. That way  
> these attributes are not restricted by design, but by security  
> environment.

I don't think any UA restricts access to parent or top. Instead, they  
restrict access to the properties of the Window you get back. In some  
cases they also restrict property access on the resultant Window's  
document, instead of blocking access to the document entirely. I'll  
put an <ednote> about this.

> <code>Window.name</code> MUST reflect the name assigned by the  
> referencing element, the empty string if there is no such element  
> or a value set by the script author. How this name is extracted  
> from the referencing element is language specific.

Perhaps we should define this for the most important past specs, and  
say future language specifications should define it themselves to be  
Window-compatible. I'll put an <ednote>.

> ISSUE: Perhaps mention that it can be set by Window.open() and the  
> "target" attribute in some language.
> For example, if you have &lt;object data="<var>file</var>"  
> id="test"/&gt; in an XHTML document the <code>window.name</code>  
> DOM attribute within <var>file</var> will be "test".

I think we need to mention this. We're not documenting window.open  
but I think we could say something general about mechanisms that can  
open a new top-level browsing context with a specified name, and cite  
these as examples. I'll make this an <ednote> for now.

> <code>ReferencingElement.contentDocument</code> MUST reflect the  
> child document <code>Document</code> object or <code>null</code> if  
> there is no such object. Likewise  
> <code>ReferencingElement.contentWindow</code> MUST reflect the  
> child document <code>Window</code> object or <code>null</code> if  
> there is no such object.

We might want to describe the circumstances under which an embedding  
element could lack a document or a window. I guess this is somewhat  
specific per element. I'll put an <ednote> to that effect.


> ===
> -- 
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
Received on Saturday, 25 March 2006 05:46:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC