css-houdini-drafts
css-houdini-drafts copied to clipboard
[worklets] Should paintWorklet be a static attribute?
IIUC, CSS
is not an instance but an interface (and will be changed to namespace
?), so paintWorklet
could be a static attribute[2] like this:
partial interface CSS {
[SameObject] static readonly attribute Worklet paintWorklet;
};
[1] https://heycam.github.io/webidl/#idl-namespaces [2] https://heycam.github.io/webidl/#idl-static-attributes-and-operations
@domenic, could you give us advice?
My questions are "what realm should be used when creating a new platform object in static IDL attributes/operations?" and "is it allowed (or good) to create a new platform object in static IDL attributes/operations?"
In CSSOM, it says that
Specifications that define static functions on the CSS interface and want to store some state should store the state on the current global object’s associated Document.
So, CSS.paintWorklet
in the first comment seems going to create a platform object (a Worklet) in the Current realm. However, is this well-spec'ed? I have several questions here.
- Is it okay to create a new platform object in static IDL attributes/operations? Like
document.createElement
andnavigator.permissions
, it shouldn't be static at all? - Is this CSSOM-specific rule? Should we have a general rule about static IDL attributes/operations? CSSOM should follow the general rule?
In case of paintWorklet
, it was/is originally window.paintWorklet
and there is no problem, but it will be moved into CSS
interface (or namespace) and will be CSS.paintWorklet
. I'm not sure how they should be moved. Maybe it should be css.paintWorklet
where css
is a singleton like navigator
?
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.
Changing to CSS
namespace is https://github.com/w3c/csswg-drafts/pull/437
Thanks for the detailed explanation. In summary, it's fine that static attributes/operations create/return a platform object, and in that case, the current realm should be used instead of the relevant realm of this
object.
I hope that it'll be clarified in Web IDL (or already?) and CSSOM simply follows the general rules. Anyway, my questions are resolved. Thanks a lot.
This issue's labels should be changed to one of the css-paint-api-*
labels, instead of worklets-1
.