[css-typed-om] StylePropertyMap order

[annevk]

Custom properties, sorted in increasing code-point order.

This seems potentially problematic given JavaScript strings. Do you have tests ensuring this is actually what's being used by implementations and they don't sneakily use code units?

[darrnshn]

I currently have some tests for the ordering, but it sounds like there are some subtle corner cases with code-point vs code-units?

[tabatkins]

Comparing by code point is already done elsewhere in CSS; sorting should be fine too. You're right that testing for that detail would be nice.

@darrnshn "code units" are JS "characters", basically - the UTF-16 two-byte chunks. So something from the astral planes is two units wide. Shouldn't be hard to put together a test that sorts oppositely depending on whether you're using code points or code units. I'll look into it.

[tabatkins]

Here we go, a custom property named --豈 (U+f900) should sort before one named --💩 (U+1f4a9), but as code units the first one is [0x2d, 0x2d, 0xf900], while the second is [0x2d, 0x2d, 0xd83d, 0xdca9], so they'll sort the other way around.

[darrnshn]

Cool, thanks for the example. I'll write a test for this.

[darrnshn]

Hmm sorting (non-custom) CSS properties by code point puts -prefixed properties before CSS properties, which appears to be different to getComputedStyle. Is that intended?

[tabatkins]

Ah, didn't think about single-dash prefixed things. Let's amend the spec to put them between normal and double-dash.