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

On Mon, 27 Mar 2006, Maciej Stachowiak wrote:
> >
> > 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.
> 
> Agreed, it shouldn't say "the main purpose". I'll reword this to say 
> that is one feature of the Window object (the spec will actually require 
> that it be implemented by the ECMAScript global scope for in-page script 
> execution such as <script> elements or event listener markup) and put it 
> last, since that aspect is not language-independent.

I'd also suggest changing "namespace" to "scope" or "context", since 
that's what it is normally called.


> > 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.)
> 
> Should I move the definition to before the first use?

The first use is the first sentence of the introduction paragraph. IMHO 
yes, you should define the term clearly before using it, but this will 
probably require a lot of rejigging.


> Any use of "window object" is a mistake.

Well then you have a mistake in the second paragraph. :-)


> "Window Object 1.0" is the title of the specification, I try to use it 
> only with the version number.

Ok.


> "Window object" is "an object that implements the Window interface", so 
> I don't have to keep writing the 7-word phrase. "Window interface" is 
> the interface as defined.

Fair enough, but in that case the intro is wrong. It says "The Window 
Object 1.0 specification defines a subset of the features of the Window  
object", but by definition that can't be true (the spec can't define a 
subset of something defined by the spec itself).


By the way I just noticed you have "This section is not normative 
normative." (note the two "normative"s) in non-normative sections.


> > | Need to define the term "document"?
> > 
> > If you do, I'd define it as "A document is an object that implements the
> > Document interface" or some such.
> 
> Works for me.

(Leaving this in my mail since it's not yet done.)



> > "A browsing context is a place where a user agent presents a document"
> > 
> > I don't think this is true. A browsing context isn't a place, it's a 
> > set of views.
> 
> I suppose that depends on how much you reify the abstraction. I'm not 
> sure it is good to define it as just the set of views, but maybe that 
> works.

Well, it's certainly not a place, by any definition.


> > "Only one document of this sequence is presented at a time."
> > 
> > This is a statement of fact, and as such is incorrect. There is no 
> > technical reason why a UA couldn't show multiple documents from a 
> > browsing context at once; the WHATWG spec goes to some lengths to not 
> > preclude crazy UI "innovations" and I think the Window spec should 
> > likewise avoid limiting allowed UI unnecessarily.
>
> I need to think about this. I think removing this requirement would make 
> some of the conformance criteria either inconsistent with this 
> possibility or untestable.
> 
> For instance I intend to require that the default view for all documents 
> in the sequence must be the same object, since this behavior is 
> interoperably implemented and depended on by some content. This would 
> not be consistent with the same browsing context presenting multiple 
> documents given the requirement that the document property of the Window 
> object must be the document being presented.

Huh. Interesting. I hadn't realised that the window objects were indeed 
the same. That does change things.


> > Overall, would you consider using the WHATWG text instead of the 
> > current Window text? What is it about the WHATWG text that would need 
> > to change in order to make that possible?
> 
> I would have to compare the latest WHATWG text to evaluate this 
> possibility.

Any luck with the evaluation?


> > 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 didn't actually look at the WHATWG spec for this interface yet, the 
> bits of it that I wrote were based on reading docs and/or implementation 
> code for Safari, Firefox and IE. I will make sure to look at the WHATWG 
> spec when fleshing out this section.

Let me know when you do this. We should make sure we coordinate 
everything.


> > "When a document has no embedding element that points to it the 
> > document is a root document."
> > 
> > Any chance we could use the WHATWG terminology here? ("top-level 
> > browsing context document") It avoids the word "root" which I think is 
> > overloaded enough already. (You actually use the term "top-level 
> > browsing context" in the spec already, though without defining it.)
> 
> Anne wrote this section, using the terminology from CDRF, I plan to take 
> a pass at it to define things in terms of browsing contexts as you 
> suggest (I believe there is an editor's note to that effect).

Let me know when you do this, too.


> > I'd like the spec to make clearer typographic distinctions between 
> > normative text, "informative" notes, and examples. It's a little 
> > confusing right now.
> 
> Examples are supposed to be in grey boxes, but unfortunately so is IDL. 
> Normative requirements are distiguished by the use of an RFC2119 
> keyword, these are in small caps. Terms being defined are bold with a 
> green background. Informative notes are not specially distinguished 
> right now.

It's a little confusing right now. I agree that there are conventions 
used, I'm just hoping they might be clearer distinctions. :-)


> > "The name attribute of a Window object MUST be the name assigned by 
> > the embedding element, the empty string if there is no such element or 
> > a value set by the script author." makes not as much sense as it 
> > should.
> 
> I agree, I'll review this in context.

Not yet changed.


> > 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.
> 
> Well, the spec could normatively require the standard web security model 
> for prevention of cross-site scripting exploits, but I have two main 
> concerns with this:
> 
> 1) This might not be appropriate for all classes of implementations.

So only require it for classess where it is appropriate, or use SHOULDs 
when describing the security model (the latter is what I do -- it's not 
required for interop, so it's not a MUST, but it is in everyone's best 
interests usually, so it's a SHOULD).


> 2) It is possible that there is some as yet unknown flaw in the standard 
> model, I would not want the spec to normatively require it if it were 
> discovered to be insecure. As an example of a recent improvement in 
> understanding, until recently browsers allowed any frame to target a 
> navigation to any named frame or top-level window, since assigning to 
> location on any window object is allowed in the standard model. But this 
> was discovered to be possibly exploitable for phishing / pharming 
> attacks, so now browsers restrict what frames are visible by name. Maybe 
> we should just bite the bullet and accept the need for spec errata if 
> flaws are discovered. I'll raise this as an issue.

You'll find flaws in your spec, whether they are security or not. I 
guarentee it. (A spec is just another implementation, and all 
implementations have an infinite number of bugs.)

Security flaws in specs should be handled the same as security flaws in 
other products -- rev, fast.


> > I look forward to reviewing a more substantial version of this spec in 
> > due course, and hope we can work closely in aligning this spec with 
> > the WHATWG spec to avoid contradictions and keep the overlap at a 
> > minimum going forward.
> 
> Sounds good.

Let me know when you think you've addressed all my comments so I can do 
another thorough review.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 13 April 2006 08:49:51 UTC