Re: [css-houdini-drafts] [worklets] Should paintWorklet be a static attribute?

> Should paintWorklet be a static attribute?

So, my understanding was that CSS was going to be a namespace, or maybe was already; @zcorpan worked with me on getting that working. In that case it's just an attribute, but it's automatically "static", since namespaces are themselves "static". I guess that hasn't happened yet though? In which case adding `static` makes sense. But switching to namespaces would be better...

> My questions are "what realm should be used when creating a new platform object in static IDL attributes/operations?"

It should be "the current realm", since in static attributes/operations, there is no `this` object to look at the relevant realm of.

> and "is it allowed (or good) to create a new platform object in static IDL attributes/operations?"

I think it is fine, but see below.

> So, CSS.paintWorklet in the first comment seems going to create a platform object (a Worklet) in the Current realm.

My interpretation was that each Document has an associated paint worklet, which is a Worklet. This is created at the same time the document is created, maybe. Then the paintWorklet attribute just returns the current global object's associated Document's paint worklet.

Of course this could be done lazily too, as an implementation detail.

> Is this CSSOM-specific rule? Should we have a general rule about static IDL attributes/operations? CSSOM should follow the general rule?

I agree things are a bit confusing here. I probably was the one who suggested "should store the state on the current global object’s associated Document." But I am not sure why that is better than just "the current global object". All the "associated Document" bit does is make things confusing when document.open() gets involved. So maybe if we simplified it to just "the current global object" as the rule for all static things (and all namespace things), it would be better.

> Maybe it should be css.paintWorklet where css is a singleton like navigator?

I don't think this should be necessary. We want to be able to create a world where you can use namespaces. It's very silly right now to have things like Navigator + navigator, i.e. singleton classes which can never be constructed by authors. That is very un-JavaScriptey. Namespaces are the right solution for the singleton pattern in JavaScript. So we should make sure they are clear and easy to use.

-- 
GitHub Notification of comment by domenic
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/410#issuecomment-304980638 using your GitHub account

Received on Tuesday, 30 May 2017 19:20:27 UTC