[cssom] How safe is it really to shorthandify properties? #8398
Description
I'm trying to understand how risky it is to change an already-established longhand into a shorthand. I'm opening this issue against cssom, because it's the only spec I can think of (at the moment) which makes problematic distinctions on longhand/shorthand.
Example: white-space is a longhand in css-text-3, but a shorthand in css-text-4 which expands to text-space-collapse, text-wrap, text-space-trim.
This is observable in that e.g. Array.from(getComputedStyle(e)) will no longer contain white-space.
Are there other problems?
- I initially thought css-typed-om might be a problem, since there is no shorthand support there. (But then I found that the spec seems to allow it, it's just Blink's incomplete implementation that doesn't support it).
- I initially thought the pending-substitution value might be a problem, but actually that's just observable via (new) longhands that old sites don't know about.
So the only real problem I see is when enumerating things in cssom. It does not seem easy to create a use-counter for this or otherwise investigate the impact of such a change. At the same time, being able to make a longhand into a shorthand seems quite important for future spec development, so the question is: should we do something to make the longhand->shorthand transition (near-)zero-risk? For example, include shorthands in the enumeration? (Or perhaps just those that have been converted).
@emilio @Loirooriol @tabatkins (can you think of other places where the conversion to shorthand is problematic?)