- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 24 Mar 2006 21:46:24 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>
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 there. > 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 <object data="<var>file</var>" > id="test"/> 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. Regards, Maciej > === > > > -- > Anne van Kesteren > <http://annevankesteren.nl/> > <http://www.opera.com/> > >
Received on Saturday, 25 March 2006 05:46:45 UTC