[cssom] Should make it clear that static functions on CSS are Window-scoped

[tabatkins]

In w3c/css-houdini-drafts#216 there's some confusion about what scope the functions on the CSS interface should have - are they document-specific (somehow), window-specific, or global across the browser?

The intention is always that these are window-specific. The spec should have some clarifying text for this.

[dholbert]

(Though if it doesn't matter, maybe they should be document-specific (instead of window-specific), since object-lifetime is more interoperable for document than for window. So if lifetime/scope is what we're trying to hammer down here, it'd be better to chain off of an object whose lifetime is already interoperable.)

[zcorpan]

Isn't this defined by WebIDL? Same as any other interface?

[dholbert]

Isn't this defined by WebIDL? Same as any other interface?

I don't think so. Note that we're talking about static functions here. WebIDL says this about static functions:

A static operation is one that is not called on a particular instance
of the interface on which it is declared, and is instead associated
with the interface itself.

https://www.w3.org/TR/WebIDL/#idl-static-operations

When such a function is specced as...

• changing state in a way that influences behavior (as with houdini CSS.registerProperty)
• depending on state (as with CSS.supports in the face of possible calls to registerProperty which should influence supported styles)

...I don't think the WebIDL spec or Houdini Properties & Values says anything right now about where (or how long) that "static" state lives. WebIDL talks about state associated with instances of interfaces, but I don't see anything about state associated with the interface itself for static functions to read/modify.

[tabatkins]

Domenic just posted an excellent breakdown of what all the globals are for a page. This indicates that we (a) probably can't define this globally, but (b) have a pretty clear answer on what to refer to for any given API.

[zcorpan]

cc @domenic

[domenic]

You have two choices here, basically depending on whether you think of CSS as a state-carrying registry, or a namespace object full of functions.

The distinguishing code is window1.CSS.registerProperty.call(window2.CSS, ...).

• If CSS is a state-carrying registry, then this should register the property on window2.
• If CSS is just a bag of functions, it doesn't matter what the this value you call them with is, so this should register the property on window1.

To access window1 you'd use "this CSS interface object's relevant global object". (Alternately you could store the state on the CSS interface object itself, instead of grabbing a window.) "the current global object"

To access window2 you'd use "the current global object""this CSS interface object's relevant global object". (Alternately you could store the state on the CSS interface object itself, instead of grabbing a window.).

In both cases you could add "...'s associated Document" if you wanted things to go away during document.open(), which replaces the Document but keeps the Window.

[tabatkins]

CSS is just a namespace object. There should be absolutely zero difference between window.CSS.foo() and an alternative window.CSSFoo(). So we should be using the relevant global object for everything.

We probably want to attach to the document itself, so we actually want "this CSS interface's relevant global object's associated Document".

[domenic]

So we should be using the relevant global object for everything.

I'm sorry, I got it backwards in my post. You want the "current global object". My bullets were correct but my "To access" was wrong. Let me do some ins/dels.