Re: [csswg-drafts] [cssom] How safe is it really to shorthandify properties? (#8398)

Okay, so if I'm correctly re-reading the above, whenever you shorthandify a property, it changes behavior in the following two back-compat-relevant ways:

1. It's no longer enumerated in CSSStyleDeclarations (its longhands are, instead).
2. It no longer shows up in CSSTransition or TransitionEvent objects (its longhands do, instead).

The longer a property has been *not* a shorthand, the more likely it is that one or both of the above will break in deployed code, thus making it incompatible to shorthand the property. (See, for example, <https://g-issues.chromium.org/issues/40269890> reporting that (1) caused breakage for a site due to `white-space` becoming a shorthand.)

Chrome is, in fact, doing something custom for `white-space` and `text-wrap` rather than shorthanding normally, to avoid some of these issues. (I'm not sure of the exact details; Koji or Ian would know better.) We're fairly certain we'll have similar problems with `position` (from #10321).

--------

We have a big set of existing shorthands that we *also* can't change the behavior of - they need to not enumerate, and not show up in transitions.

So, the simplest answer is just: we define, for a small set of compat-required new shorthands, that they *do* enumerate and *do* show up in transition JS objects, despite being shorthands.

Enumeration ordering is likely important to preserve. Alphabetical ordering will *usually* automatically place the shorthand before its longhands, but when that isn't the case, we'll have to explicitly specify a break from alphabetical ordering to maintain the "shorthand comes first" property. Assuming the shorthand is the legacy property, we'd leave it where it always was and say that the new longhands, which would otherwise precede it, instead come right after it.

Open question: is this a behavior we want to apply to all shorthands going forward (and thus we require an explicit, fairly large, list of grandfathered shorthands that don't serialize)? Or do we want to let new stuff stay consistent with old stuff, and only invoke this special behavior when we're doing a compat-constrained "upgrade" shorthandification? I suspect we want the latter; it's far fewer cases overall, and the existing behavior is well-established across dozens of shorthand properties.

Is there anything else we'd need to define for these "upgraded" properties? Or is that it?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8398#issuecomment-2123561486 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 21 May 2024 22:54:49 UTC