[css-ui] Test serialization: -webkit-appearance

[jugglinmike]

This is in service of csswg-drafts #3024 - Unprefix 'appearance' and/or make the spec web-compatible

I've tried to avoid the parsing code paths from the serialization tests and vice versa. Was I successful?

[zcorpan]

Can you also test the same things but for the unprefixed 'appearance' property?

[zcorpan]

This needs to use setAttribute() instead. The setter here is forwarded to the cssText setter.

[zcorpan]

I've tried to avoid the parsing code paths from the serialization tests and vice versa. Was I successful?

I believe so, but I don't really know how these things are implemented to say for sure. :-)

[jugglinmike]

This needs to use setAttribute() instead. The setter here is forwarded to the cssText setter.

The path I'm trying to test is the attribute change steps for the owner node:

https://drafts.csswg.org/cssom/#ref-for-parse-a-css-declaration-block

By my reading, the relationship is the other way around--cssText seems to depend on the change steps:

The cssText attribute must return the result of serializing the declarations.
Setting the cssText attribute must run these steps:

[...]

4. Update style attribute for the CSS declaration block.

[...]

To update style attribute for declaration block means to run the steps below:

[...]

5. Set an attribute value for owner node using "style" and the result of
   serializing declaration block.

That's why using cssText seems like a less direct way of testing the same thing.

Can you also test the same things but for the unprefixed 'appearance' property?

As I understand it, such tests would verify that appearance is parsed as appearance and that appearance is serialized as appearance. Are there more nuanced expectations than that? If so, could you point me to where they are defined or proposed? If not, could you say a bit about what would make that an interesting test case for parsing or serialization?

[zcorpan]

The attribute change steps are run as a result of setAttribute() per the DOM spec.

https://dom.spec.whatwg.org/#dom-element-setattribute
https://dom.spec.whatwg.org/#concept-element-attributes-change
https://dom.spec.whatwg.org/#concept-element-attributes-change-ext

Setting elm.style is exactly the same as setting elm.style.cssText, since the former is annotated with [PutForwards=cssText] WebIDL extended attribute.

https://drafts.csswg.org/cssom/#elementcssinlinestyle

As for appearance, yes it should parse and serialize as appearance, but also calling getPropertyValue('-webkit-appearance') should also work. Basically I would test the exact same things for both appearance and -webkit-appearance inputs, to verify that they're properly aliased.

[jugglinmike]

Thanks for the clarification, Simon! I've improved the tests using a few commits and added an explanation to the body of each commit message.

This introduces new tests for direct property reference. I've added these in a new file because according to legacy name alias, they are neither parsing nor serialization. This motivated a lot of tests (just learned that "webkit-case" is a concept in CSSOM), and a dedicated file helps make the enumeration of all combinations (including how the methods should not recognize the camel-case/webkit-case versions) a little easier to see.

Since the serialization and parsing tests already use these API's, I didn't rely on serialization or parsing here. That lead to some overlap (i.e. multiple sub-tests rely on setProperty--not just the sub-test dedicated to it), but I think this is unavoidable.

These new tests also made some of the assertions in the "parsing" tests redundant. I've removed those extra assertions to keep things organized.

What do you think?

[zcorpan]

[jugglinmike]

I will cherish this all the days of my life

[zcorpan]

I think we can merge this.