Re: [w3ctag/design-reviews] CanvasRenderingContext2D API Improvements (#627)

Hi @mysteryDate 👋🏼 

@atanassov and I looked at this during a breakout today at our virtual f2f meeting. 

> **CSSColorValue as input:**
> As @annevk has pointed out in [this issue](https://github.com/whatwg/html/pull/6609) if CSSColorValues can stringify then we can use them as style input without changing anything in the specification. A User Agent could short-circuit this and accept the object as an input, but the code would still work the same with the string translation. Would it be ok to add a note to that effect on the spec?

It seems like an implementation detail, so we aren't sure a note is needed, but if you want to add one, sure, go ahead.

> **TextModifiers:**
> With the original proposal, we were trying to make sure that all text related attributes were prepended by the string `text` or `font`, which is the case for current text/font properties on CanvasRenderingContext2D. But we also see the rationale behind keeping the names equivalent to those found in HTMLElement style. Unless there’s any other mention to the contrary, we’ll go ahead and change the two affected ones: `textLetterSpacing` and `textWordSpacing` will become `letterSpacing` and `wordSpacing`, respectively.

We saw there was some [pushback](https://github.com/whatwg/html/issues/5617#issuecomment-909116756) to that, because these attributes do not have the same syntax as the corresponding CSS properties.
We still feel these should be named the same as CSS, since the functionality is the same, even if the values are not. It is more [consistent](https://w3ctag.github.io/design-principles/#consistency) that way, and it means that if the syntax is extended in the future to support more types of values, the property name is already harmonized. The fewer concepts that people need to learn, the better. Keeping names the same is better for discoverability and education.

> **SVG Filters:**
> The under-powering is intentional and based on implementer feedback. As @litherum mentioned [here](https://github.com/whatwg/html/issues/5621):
> 
> > if we're going to add filter support, we should start with a small set of popular filters, and only expand the set if compelling needs arise. Also, we should start with the "linked-list" model of filters that the css filter() function accepts, rather than arbitrary graphs that are allowed by SVG.
> 
> This is a rather large change and it made sense to bite off a smaller chunk for the time being. The proposed syntax could be trivially extended to support DAGs in the future, by allowing CanvasFilters as parameters values.
> 
> One of the major motivations for this feature is to make filters available on WebWorkers with OffscreenCanvas. SVG and CSS are DOM dependent, and not trivially available on WebWorkers and thus a new syntax would already be necessary. This proposal has the advantage of being trivially parseable (as a regular Javascript object) and familiar to Javascript developers. Attribute names are copied verbatim from the SVG implementation also with the goal of being as un-surprising as possible.

That seems reasonable to us.

Thank you for working with us and being receptive to feedback. Good luck, we look forward to seeing this progress!


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/627#issuecomment-920982811