[css-paint-api]: should constructors / parsers be exposed in Worklets?

[annevk]

It seems like maybe those should not, if we want to keep things lightweight?

@bzbarsky

[shans]

We need at least some of them, for example CSSImageValue and CSSFontFaceValue objects. I think it makes sense to expose the rest too.

[bzbarsky]

The other question is whether the various setters are needed in worklets.

[annevk]

@shans well... Do we really want those to be constructed based on a URL? I don't think we can wait on network in short-lived Worklets. That doesn't make much sense.

[shans]

@annevk right, Worklets don't permit network access. But there are procedurally generated images (e.g. gradients, etc.) that we really should allow authors to construct directly inside the worklet rather than having to pass in through a custom property. Issue #186 is there to address the network issue.

[tabatkins]

Also, LayoutWorklets are expected to output style information, so they need to be able to construct lengths and so on.

[shans]

@bzbarsky the style map provided to the paint worklet is read-only and won't have setters. I don't know what will end up being specced for layout.

[annevk]

But should you construct lengths from strings or integers?

[bzbarsky]

is read-only and won't have setters

In that they will be hidden via appropriate [Exposed] annotations, presumably?

[tabatkins]

@annevk

But should you construct lengths from strings or integers?

I don't understand the context of the question.

@bzbarsky

In that they will be hidden via appropriate [Exposed] annotations, presumably?

Or it should be receiveing a StylePropertyMapReadOnly.

[css-meeting-bot]

The CSS Working Group just discussed Issue 238, and agreed to the following resolutions:

RESOLVED: don't expose constructor and parse methods

The full IRC log of that discussion

``` Topic: Issue 238 Github topic: https://github.com/w3c/css-houdini-drafts/issues/238 iank_: This is what API we should expose inside paint worklets iank_: Shoud the paths api and constructors be exposed or not? iank_: One side of why shouldn't be exposed is should be getting these objects through the style map as part of your input, and this would be the same for layout anm=imation as well zakim, hug minute-man :) I'm glad that smiley is there, ChrisL iank_: Flip side ismight want to ocnstruct these values out of other inputs, and then convert it to something else at some stage iank_: Thoughts? shane: ... gradients, those are quite useful, so at least procedure constructors should be usable iank_: So want to cssimage parse linear-gradient blah? iank_: Yeah, can see that shane: Tab responded also iank_: Trying to think about additional overhead of exposing... iank_: ... is the valid case shane: eventually font face information will have use cases too iank_: For font face you'll always want to comment in through style, because will need to know about loading font iank_: Same for images shane: If you're building a painter that wants to use text, and you want to use a font shane: drawing text is a valid operation, so if you always want to use COmic Sans, then it's kindof the analog to ? test: Comic Sans Georgia helvetica CSSWG plays with IRCCloud easter eggs iank_: upside to not having thise is it may make instance construction a bit faster iank_: Shoudlnt' be too concerned iank_: any thoughts on this till: Doesn't seem like there are any real use cases for having them till: So while perf concerns are slim that maybe should be nonexistent use case iank_: Can always add them later as well shane: Are you suggesting to just add image value ones? shane: I think image value use case is a significant use case shane: If you have a gradient background, makes sense to construct that value from within the paint worker iank_: ... cross-fade() would have to receive two images and receive those images to cross-fade them shane: Can you implement cross-fade with compositor operations? iank_: Yes, very easily iank_: Alright so sounds like we'll not expose the constructors and pass methods on the typed OM for the paint API, and probably layout as well iank_: but we'll want htese for the animation worklet API, because we need to set style Rossen: Any other comments? iank_: We'll have to work out what to do for typed OM, but that's separate issue RESOLVED: don't expose constructor and parse methods ... in the typed OM s/... in the typed OM// ```

[shans]

On review, this seems to contradict #237.

[shans]

See discussion in #237. Merging this issue with that.