https://github.com/w3c/csswg-drafts/commit/cbc295bfa304e8cbe20a983ab51db5bfa49a04a1

I don't think that's reasonable, for several reasons:

1)  It's ambiguous about whether the canonical defaultView getter is invoked or whether the current defaultView value is gotten.  The latter may have been munged by JS.  This needs to be clarified somehow (and this is a general problem in specs, really...).

2)  If the node document is not the active document in its browsing context, the defaultView will still return, per spec "the Document's browsing context's WindowProxy object".  So as the spec is written right now, you could grab an element from a document, navigate the browsing context, then set scrollTop on that element to scroll the new document in the browsing context or get scrollTop to get its scroll position .  That's clearly undesirable.  So you need to bail out if the node document is not the current document in the browsing context if you want to use the defaultView (but see below).

3)  The various accesses on the windowproxy (scrollY, etc) have a problem similar to #1.

#2 is critical to solve.  Ideally we would solve it by just getting the Document's current Window, but I see nothing obvious in the HTML spec that defines such a concept.  Failing that, we can make do with a check for being the active document and then working with the windowproxy.  But that might actually give different behavior in cases when a presentation is cached (e.g. operating directly on a window might allow scrolling a cached presentation while operating on the windowproxy but restricting to the active document case makes attempts to do so no-op).  So we should decide what we actually want here for that case.

For #1 and #3 if there's a simple fix of some sort that would be great; might want to check with Anne whether there's an existing convention for it.

(In reply to Boris Zbarsky from comment #2)
> I don't think that's reasonable, for several reasons:
> 
> 1)  It's ambiguous about whether the canonical defaultView getter is invoked
> or whether the current defaultView value is gotten.  The latter may have
> been munged by JS.  This needs to be clarified somehow (and this is a
> general problem in specs, really...).

[[
When a method or an attribute is said to call another method or attribute, the user agent must invoke its internal API for that attribute or method so that e.g. the author can’t change the behavior by overriding attributes or methods with custom properties or functions in ECMAScript.
]]
http://dev.w3.org/csswg/cssom-view/#terminology

I plan to fix this overall in CSSOM but for now the above paragraph will have to do.

> 2)  If the node document is not the active document in its browsing context,
> the defaultView will still return, per spec "the Document's browsing
> context's WindowProxy object".  So as the spec is written right now, you
> could grab an element from a document, navigate the browsing context, then
> set scrollTop on that element to scroll the new document in the browsing
> context or get scrollTop to get its scroll position .  That's clearly
> undesirable.  So you need to bail out if the node document is not the
> current document in the browsing context if you want to use the defaultView
> (but see below).

OK. Good point. Fixed:

https://github.com/w3c/csswg-drafts/commit/5235256676fd00d870c51848686a8d8c46f1bb09

> 3)  The various accesses on the windowproxy (scrollY, etc) have a problem
> similar to #1.
> 
> #2 is critical to solve.  Ideally we would solve it by just getting the
> Document's current Window, but I see nothing obvious in the HTML spec that
> defines such a concept.  Failing that, we can make do with a check for being
> the active document and then working with the windowproxy.  But that might
> actually give different behavior in cases when a presentation is cached
> (e.g. operating directly on a window might allow scrolling a cached
> presentation while operating on the windowproxy but restricting to the
> active document case makes attempts to do so no-op).  So we should decide
> what we actually want here for that case.

How would you operate directly on a window? Don't you only have access to the WindowProxy, so scrolling operations will always scroll the active document?

I'm happy to use a hook instead of document.defaultView here if one is provided in HTML.

> For #1 and #3 if there's a simple fix of some sort that would be great;
> might want to check with Anne whether there's an existing convention for it.

I think Anne's convension is to define concept-foo and then have the API call concept-foo instead of calling another API.

Yeah, the existing convention is to have an internal abstraction that does the actual work and invoke that from the public APIs.

> How would you operate directly on a window?

Uh... you just do.

> Don't you only have access to the WindowProxy

Who is "you"?  The UA obviously has access to the Window.

Anyway, I carefully checked what Gecko does right now, and we in effect go through the WindowProxy, but with an active document check, which is what the spec now says.  Yay, I guess....

Ah, I was thinking about "you" as a JS author.

OK, setting to fixed.