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

Hi @mysteryDate & @fserb!

@hober and I took a look at this during a breakout this week.

Overall, we're happy to see that each of these additions is being discussed in [various WHATWG HTML issues](https://github.com/whatwg/html/issues/5613) where you've gotten a lot of feedback from other stakeholders. For instance, the ongoing discussion on [the reset() function](https://github.com/whatwg/html/issues/5618) has been fruitful and we look forward to seeing what conclusion everyone comes to.

Regarding [using CSSColorValue for input](https://github.com/whatwg/html/issues/5616), and as @plinss [already expressed](https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-837168505) in the Houdini TF discussion on this, we don't think `CSSColorValue`, as currently specified, is an appropriate object to use here. CSSColorValue is intended to represent CSS syntax in Typed OM, not as a general purpose Color object for the Web Platform. It would require substantial changes to be used in that way. However, there are plans to eventually define a `Color` object that other APIs can use as input.

On the proposed [CSS Text Modifiers](https://github.com/whatwg/html/issues/5617), we're concerned about the choice to use camelCased names instead of the actual CSS property names. The names currently proposed are not just camelCased versions of their CSS counterparts (e.g. `textLetterSpacing` instead of `letterSpacing`) , but even if they were, there is both mental and coding overhead to converting, compared to being able to use the CSS property verbatim. It might be better to instead expose an API that accepts CSS property names if you are looking to expand the set of CSS properties that you support. The set of properties proposed is also a little surprising, for example `font-variant-caps` is exposed but none of the other `font-variant-*` properties, or even `font-variant` itself.

You've gotten strong implementer feedback that [perspective transforms](https://github.com/whatwg/html/issues/5620) aren't feasible in at least one implementation. Perhaps it's best to leave this for the future, in case that stops being the case later on.

The syntax proposed for SVG filters is strictly less powerful than SVG filters, [as pointed out previously by @smfr](https://lists.webkit.org/pipermail/webkit-dev/2021-May/031850.html). Adding APIs that are very similar to other APIs but different in subtle ways is likely to be confusing to authors.

We did not see any issues with any of the other proposed additions.

-- 
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-838726027