CSS operations static or not static?

[tabatkins]

On Wed, Jun 8, 2016 at 4:04 PM, Jonathan Chan jchan@mozilla.com wrote:

Hi! I’m an intern at Mozilla looking into implementing the Properties & Values API in Firefox/Gecko.

My mentor & I noticed that a year ago the spec changed 0 about what interface the registerProperty/unregisterProperty functions are defined to hang off of. They used to be defined on the Document interface, but now are defined on the CSS interface 1, which previously only had static functions 2(escape and supports).

Is the ownership / lifetime / etc. of the CSS object specced/described anywhere? Right now in Firefox, there is no CSS object — it’s just a class with a few static functions. Is it supposed to be owned by the document, the global object, or something else?

Alternatively, should the register/unregisterProperty functions be static, like the other functions defined on CSS?

Finally, is the ownership model / lifetime / etc. of the CSS object explained or implied in any spec at this point?

Thanks.

Best regards,
Jonathan Chan

[tabatkins]

Whoops, that's just a mistake - all methods on the CSS global should be static. It's nothing more than a namespacing object for things that would otherwise go on window with a longer collision-avoiding name.

[jyc]

Awesome, thanks for the clarification! I'll submit a tiny pull request.

[dholbert]

@tabatkins Wait, so if these methods are static, does that mean one page can call registerProperty/unregisterProperty and influence the behavior of other tabs/pages in the same browser? Or are their effects supposed to be scoped to the current document (or current window, or current $THING)?

I suspect/believe the scoping is why these methods were on the Document interface in the first place (before they moved to CSS).

[shans]

Previous discussion: #50

We moved the properties from Document to Window scope deliberately, it seems. I think Window is the correct scoping?

So I guess the question is whether CSS is Window or globally scoped.

[dholbert]

Hmm, the discussion in #50 asserts that "CSS is Window scoped", but I don't think that's backed up by any spec at this point. The two existing specs that I'm aware of which put stuff in the CSS interface so far (cssom-1 and css-conditional-3) both simply say:

The CSS interface holds useful CSS-related functions that do not belong elsewhere

...and the functions that they added (escape(), supports()) aren't obviously scope-specific at this point.

(BUT, I suppose supports() will need to become Window-specific after the Properties and Values API is implemented, if type-restricted custom properties are intended to be recognized in CSS.supports() invocations.... so that e.g. CSS.supports("--my-logo-color:red") will have the correct behavior in documents that do vs. don't register that custom property.)

So I think I agree that CSS needs to become Window (or document?) specific, if it's not already, in order for CSS.supports() to meaningfully work in the face of typed custom properties.

[tabatkins]

Wait, so if these methods are static, does that mean one page can call registerProperty/unregisterProperty and influence the behavior of other tabs/views in the same browser? Or are their effects supposed to be scoped to the current document (or current window, or current $THING)?

They're scoped to the window; I assumed that was obvious, but we may very well be missing some text that makes that explicit in CSSOM.

[tabatkins]

I'll open a separate issue back in css to fix this in CSSOM.

[dholbert]

They're scoped to the window

Specifically the window? (not the document) It's a subtle difference; note that in most cases there's a 1:1 relationship between the two.

All things being equal, bz tells me it's actually better to hang things off of document as opposed to window from an interop perspective, because Chrome & Safari are non-conforming on the lifetime of window objects. (Specifically: Chrome/Safari do not replace the window object when document.open() is called, but the HTML spec says they should (see section 8.4.1, step 15, first bullet point: "create a new Window"). Firefox/Edge are spec-conforming on this point. I believe there's no such confusion about the lifetime of document objects, though.)

[tabatkins]

I don't have a strong opinion.

[zcorpan]

The document.open() case appears to be https://bugs.chromium.org/p/chromium/issues/detail?id=149785

[dbaron]

So if this is going to be on CSS, how does a script in a document register a property for the document inside one of its iframes? Does iframe.contentWindow.CSS.registerProperty work for CSS being an interface but not a property on Window?

[tabatkins]

Yes. Am I missing something that makes that question interesting? It seems like the obvious answer.

[dbaron]

Does the way interface and static methods work in WebIDL and Javascript map to something where the implementation of registerProperty knows which window's CSS interface it came from? (Including in the presence of all sorts of interesting Javascript stuff, like usage of call?) (Aren't static methods normally ones where there's no concept of a this pointer?)

[tabatkins]

A static method is just one defined on the interface object, rather than on instances of the interface. Methods thus still have a perfectly reasonable this - the interface object.

Do we need to do anything about .call() and such? Does document.open.call(otherDocument) need special handling, or is that just handled automatically by WebIDL? We just want "the obvious behavior", where this is identical to calling a method on window and having its effect scoped to the window's primary document.

[zcorpan]

See w3c/csswg-drafts@e9edde3