Re: Further update to Window Object 1.0, I think it's ready for first Working Draft

Hi Ian,

I made changes to the spec to address some of your comments (the ones  
where the needed change was reasonably obvious). See below for what I  
did. I will file ISSUEs or ACTIONs for the remaining items you raised  
and will send a separate reply covering those.

On Mar 27, 2006, at 7:41 PM, Ian Hickson wrote:

> On Mon, 27 Mar 2006, Maciej Stachowiak wrote:
>>
>> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Window/publish/ 
>> Window.html
>
> "With this specification, it is recommended for all implementations  
> that
> present documents to the user or provide the equivalent of a browsing
> context." makes no sense.

Replaced with: "This specification is intended to be suitable for all  
implementations that present any sort of DOM document [DOM3Core] to  
the user."


> I don't think I agree with:
>
>    The main purpose of the Window object is to provide the global
>    namespace for script execution.
>
> That's the purpose of the global scope object, which is an ECMAScript
> concept. As specced, the Window interface (it's not an object) is just
> something that the global scope object implements.

I struck this sentence from the beginning of the paragraph in  
question. I added this paragraph after the one listing the four  
features instead:

       In addition, for some languages, such as ECMAScript
       [ECMAScript], the <term><code>Window</code> interface</term> is
       implemented by the object that provides the global namespace for
       script execution. The details of how this works for ECMAScript
       are specified in <a href="#ecmascript-binding">ECMAScript
       Language Binding Appendix</a>.

> You inconsistently refer to the "window object", "Window object",  
> "Window
> interface", etc, in a way that is a bit subtle for me. In particular,
> speaking of the Window object in the singular and with that  
> capitalisation
> seems a bit odd to me. (later note: It seems this may be because you
> define "Window object" after you first use it.)

For now I changed nothing, but let me know if you have a specific  
suggestion on how I could improve this. Move the definition of  
"Window object" earlier? Not use until defined?

> Is the Introduction meant to be normative?

I marked it "not normative"

> Starting a sentence with "And finally" is poor form.

Reworded to avoid "And finally"

> You have "this section is informative" twice in" 1.2. Not in This
> Specification".

Gone now.

> I personally have issue with the word "informative" used as an  
> antonym to
> the word "normative". I've often read specs that say "this section is
> informative" and gotten very confused and thought "no it isn't, it's
> highly uninformative". I recommend using the term "non-normative".

I updated ReSpec to support a normativity level of "not normative"  
and now the text should say "This section is not normative."

> "MUST, REQUIRED and SHALL level criteria" should be "MUST-,
> REQUIRED- and SHALL-level criteria".

Done.

> "An visual user" is a typo ("a").

Fixed.

> "In a conforming implementation, an object that implements the  
> Document
> interface [DOM3Core] and is presented in a browsing context MUST also
> implement the DocumentWindow interface."
>
> The first four words of that sentence are redundant (given your  
> earlier
> definitions of "conforming" and "must").

Removed "In a conforming implementation".

> "In addition to the DocumentView interface, the Document MUST  
> implement
> the Document and DocumentWindow interfaces."
>
> This is redundant. You already required this. Either drop it or  
> make it a
> statement of fact.

Replaced with the following statement of fact: "As a result, in  
addition to the <code>DocumentView</code> interface, it implements  
the <code>Document</code> and <code>DocumentWindow</code> interfaces."

>     readonly attribute Window window;
>     readonly attribute Window self;
>
> It seems that while "window" is readonly, "self" is replaceable in
> Mozilla (at least). The spec doesn't currently mention anything  
> like this.

For now I have changed nothing, however, this will be covered in the  
ECMAScript appendix.

> I think it's confusing that you have different definitions for  
> "self" and
> "window". I also think it's confusing that you have two MUST  
> requirements
> for what "self" should be -- if you can't just use the same  
> definition,
> you should at least make one of those two definitions a statement  
> of fact.

I thought about this. I think the second requirement for "self" is  
only redundant if the relations "be the same object" and "has the  
same value" are the same relation and transitive. I would like this  
to be the case (=== for ECMAScript, whatever the equivalent is for  
Java), but I think I would need to define these terms for this  
requirement to be redundant. I added a note to define "the same  
object". For now I reworded it like this:

             The value of the <term><code>self</code> attribute</ 
term> MUST be the
             same <code>Window</code> object that has the attribute:  
the attribute
             is a self-reference. Consequently, the value of the  
<term><code>self</code>
             attribute</term> MUST be the same object as the  
<term><code>window</code>
             attribute</term>.

And added this note:

             <ednote>
               Need to define "being the same object" in such a way
               that it is an equivalence relation. Then the second
               conformance clause for "self" can just be a note.
             </ednote>


> : 2.1.2. Use in scripting
> :
> : The Window object also has a special role as the global scope for
> : scripts in the document in languages such as ECMAScript  
> [ECMAScript].
> : Such use is specified by individual language bindings. For  
> ECMAScript it
> : is specified in the ECMAScript Language Binding Appendix.
>
> Given that the ECMAScript binding is far more important than the  
> others,
> I'd like to request that things that affect that binding be moved  
> into the
> main prose instead of being relegated to an appendix.

I decline to take this suggestion for now. I think the appendix will  
provide a clean separation of ECMAScript-specific and language- 
independent issues, and the way I defined the conformance classes  
makes things simpler and clearer if ECMAScript-only requirements are  
all in the appendix.

> "For documents not being presented in a browsing context, the value  
> of the
> defaultView attribute MUST be null."
>
> There is no requirement in the spec that such documents even implement
> this interface, so that seems wrong. Indeed the spec is clear that  
> it is
> documents that _are_ in browsing contexts that implement this.
>
> So I would request that this be removed. Documents not being  
> presented in
> a browsing context wouldn't even have the defaultView attribute.

The spec doesn't forbid a document that's not being presented in a  
browsing context from implementing the DocumentWindow interface. In  
case such documents occur, I wrote the following:

         If a document is not being presented in a <term>browsing  
context</term> but nontheless
         implements the DocumentWindow interface, the value of the
         <code>defaultView</code> attribute MUST be <code>null</code>.

This seems better than leaving it implementation-defined. Let me know  
if you disagree. I still have the note about whether this is  
reasonably testable.


> Sections "3.1. The Window Interface, Location Attributes" and "3.2.  
> The
> DocumentWindow Interface, Location Attributes" are woefully inadequate
> right now so I've not looked at them in detail.

Noted, no action taken for now.

> Section "3.3. The Location Interface" duplicates the definitions in  
> the
> WHATWG spec. Is there any way we can just use the text from the WHATWG
> spec here? The WHATWG spec is equally incomplete, but I'd like to  
> not have
> to fork here.
>
> I haven't looked at the rest of section 3 in any more detail since  
> this
> section is very incomplete right now.

Ditto.

> "Security should probably be taken care of in a separate part of the
> specification."
>
> Please don't relegate security to an after-thought. It should IMHO be
> defined right there in the part the implementors are going to read,  
> and
> the separate security section should be a set of statements of fact
> explaining the reasons for various requirements in the prose.

My current plan for the "security considerations" section is that it  
will contain the following:

* Non-normative statements of fact about various security  
vulnerabilities that may affect Window implementations (unauthorized  
data access, phishing/pharming, frame injection, etc).

* A normative requirement that UAs implement some security policy  
that is in line with some general principles of cross-site scripting  
security, with exemptions allowed for "trusted" content. Some rough  
cuts at it (this language is not nearly precise as it should be, just  
trying to get the rules across):
     - "A script executing in a browsing context currently presenting  
a document from one origin MUST NOT be allowed to access remote  
content from a different origin in such a way that the script can  
then access the contents." (where "same origin" is defined as same  
URI scheme, host and port, modulo differences for document.domain  
which I guess needs to be in the spec).
     - "A non-trusted document MUST NOT be allowed to navigate a  
browsing context unless one of the following holds: the browsing  
contexts have the same top-level browsing context; the target  
browsing context has the same origin as the source browsing context;  
one of the ancestor browsing contexts of the target browsing context  
has the same origin as the source; OR the target browsing context is  
a top-level browsing context and the user can see the context's  
current location."
     - "A non-trusted document MUST NOT be allowed to access or  
navigate to content from a file: URI in any way."

* Specific cases where access and navigation must be allowed,  
notwithstanding any additional security restrictions (anything from  
the same origin).

* Normative restrictions on what may be considered "trusted" content  
(MUST be from a specific known location, MUST NOT be transmitted over  
a network via an insecure protocol -- so you can't just say "my UA  
considers all content to be trusted" or "my company's homepage sent  
over non-SSL http is trusted".)

* An example of a specific security model that is believed to satisfy  
these constraints.

I would rather not have normative requirements on when UAs must or  
must not throw exceptions or return null or whatever, since these  
would merely represent our best current understanding of how to  
implement the security policy.

It may be that some of this belongs in the main body of the spec  
instead of in Security Considerations, let's figure that out when the  
security part is actually written.

I hope this brief outline assuages your concerns about the planned  
security-related content of the spec. I also put the above in an  
editorial note in the draft.

> "does it make sense to spec this without being html-specific or  
> defining
> open?"
>
> I don't understand the problem with being HTML-specific here.  
> Pragmatism
> should win over theoretical purity.

I removed this from the IDL comment.

> The "4.1. The Window Interface, Embedding Attributes" section  
> "defines"
> ("informatively") the bits that are actually normative defined in the
> earlier block of text. This is inconsistent with how the earlier  
> part of
> the spec is organised.

I added a note for now, I'll fix this soon.

Regards,
Maciej

Received on Thursday, 30 March 2006 19:26:05 UTC