[cssom] Doubt about resolved value of shorthands

[mrego]

Spec text: https://drafts.csswg.org/cssom/#resolved-value

The resolved value for a given longhand property can be determined as follows:

• A bunch of properties defining it.
• A resolved value special case property defined in another specification.
  As defined in the relevant specification.
• Any other property.
  The resolved value is the computed value.

The spec talks about longhand so I'm not sure what's the expected behavior for shorthands.

I've tried the following example for the flex shorthand:

  <div style="display: flexbox;">
    <div id="flexitem" style="flex: 1;">item</div>
  </div>
  <script>
    console.log("flex: " + window.getComputedStyle(document.querySelector("#flexitem")).flex);
  </script>

The output in Chrome, Safari and Edge is:

  flex: 1 1 0%

However in Firefox it's:

  flex: 

In a different issue @upsuper commented:

IIRC in general we don't serialize new shorthands in computed style, only longhands are serialized there. There are several shorthands get serialized in computed style just for backward compatibility.

What's the expected behavior?
Should the spec be updated to be clearer about the resolved value of shorthands?

Thanks! 😄

[mrego]

And now that we're talking about this, one more question if instead getComputeStyle() you use style directly on the element.
Something like this:

  document.querySelector("#flexitem").style.flex = "2";
  console.log("flex (.style): " + document.querySelector("#flexitem").style.flex);

The output here is the same in all the browsers I've checked Chrome, Firefox, Safari and Edge:

  flex (.style): 2 1 0%;

[upsuper]

I think the spec indicates that shorthands don't have resolved value.

Gecko generally doesn't serialize shorthands for declaration block returned from getComputedStyle (with several exceptions of shorthands which were longhands), but it seems others do (or at least sometimes do) serialization for normal shorthands in resolved value.

I'm not completely sure what should we do for this. I guess a reason against serializing shorthands in resolved value is that, it is hard to keep backward compatibility. When we extend a shorthand to cover more longhands, their serialized form may change, and anything relies on it may be broken.

This breakage may still happen when a longhand is converted to shorthand, but that happens relatively fewer times, and the result can be kept if the author doesn't touch the expanded longhands, so probably it can still be considered backward compatible.

[upsuper]

I guess that reason may not be strong enough, because serialization of shorthands in specified value can also change when we extend the syntax. If we always omit the parts with initial value, then there is a larger chance that we can keep the result backward compatible with shorthand from both specified value and resolved value.