css-contain-1 defined the grammar for contain with size at the start when using the longhand syntax, like so:

Value: none | strict | content | [ size || layout || paint ]

...whereas css-contain-3 flips the order to put size (and the new value inline-size) at the end:

New values: layout || style || paint || [ size | inline-size ]

The order matters for serialization, per https://drafts.csswg.org/cssom/#serialize-a-css-value , which says:

If certain component values can appear in any order without changing the meaning of the value (a pattern typically represented by a double bar || in the value syntax), reorder the component values to use the canonical order of component values as given in the property definition table.

If you're looking at css-contain-1, you would expect size (and hence inline-size) to serialize at the start of the list. If you're looking at css-contain-3, you'd expect them to serialize them at the end of the list.

Looking at what immplementations do & WPT tests expect:

• implementations do serialize size at the start, and Chromium/WebKit serialize inline-size at the start too (whereas Firefox serializes it at the end, but probably should put it at the start, for consistency with the fact that we serialize size at the start).
• Two WPT tests expect size and inline-size to serialize at the start: https://wpt.fyi/results/css/css-contain/parsing/contain-valid.html and https://wpt.fyi/results/css/css-contain/parsing/contain-computed.html

So probably the ordering in css-contain-3 should be fixed to put [size | inline-size] at the start.

(Perhaps we should also add none | strict | content keywords to it as well, while we're at it? I'm not sure whether it's problematic for those to be omitted from "New values" or not, given that we're repeating most of the preexisting grammar there except for those ones.)