Notes:

• 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.
• Filter syntax is less expressive than SVG
• We were concerned about ctx.reset() but we see that it's being discussed productively.
• Clear feedback from implementors that perspective transforms are not implementable
• camelCase font properties are not consistent or predictable. Might be better to instead expose an API that accepts the actual CSS property as a string. Also, why expose font-variant-caps but none of the other font-variant-* properties, or even font-variant itself?

TODO: Lea works on finishing draft comment and posting it after the breakout (Done)

Draft comment:

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 where you've gotten a lot of feedback from other stakeholders. For instance, the ongoing discussion on the reset function has been fruitful and we look forward to seeing what conclusion everyone comes to.

Regarding using CSSColorValue for input, and as @plinss already expressed 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, 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 unexpected, 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 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. 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.

taken to plenary

Dan: Maybe ready to close? There are multiple PRs based on our feedback some merged...

Rossen: think Lea's feedback was on colorvalue and text modifiers - i think we already squared this. we have a path forward to define the color object so it's something that carries through the entire platforms. I think the spec can only benefit...

Rossen: I think this one is ready for closing.

Dan: mark proposed close and close at plenary.

Closed with comment