Incorrect and missing CSS `longhands` entries

[cdoublev]

The longhands property has recently been added for shorthands in @webref/css, but there are two problems:

• it includes entries that are not longhands but shorthand sub-properties
• it is missing reset-only sub-properties

For example, the longhands of border are defined with border-width, border-style, border-color. I do not think that a definition of "longhand" exists in CSS specs, but CSS Cascade 5 defines this:

A shorthand property sets all of its longhand sub-properties, exactly as if expanded in place.

Ie. a shorthand sets a declaration for all its longhands. But there is no shorthand declarations internally stored.

So I believe that these are shorthand sub-properties, not longhands.

The longhands of border are missing border-image-* longhands, which are its reset-only sub-properties. When border is declared, it sets a declaration for all its longhands, including its reset-only sub-properties.

If you are interested, you can see my own maintained version of the shorthand/longhands mapping here. Note that I split reset-only subproperties in a separate group, which would be handy in @webref/css.

[tidoust]

So I believe that these are shorthand sub-properties, not longhands.

I may misunderstand you but you seem to be willing to get rid of intermediary shorthands. I was more thinking that this could be up to consumers of the data. That is, it seems fine to me if, when you look at border, you get border-width as a longhand, realize that it is itself a shorthand property, and further expand things as needed. Is there anything broken with this approach?

Other consumers may want to see and use the intermediary level. For example, MDN currently says that the constituent properties of border are border-width, border-style, and border-color. Which seems good to me.

The longhands of border are missing border-image-* longhands, which are its reset-only sub-properties. When border is declared, it sets a declaration for all its longhands, including its reset-only sub-properties.

Ah, good point! We haven't mapped reset-only sub-properties. They did not appear in mdn/data, they seem to be only mentioned in prose in some MDN pages for now, and essentially no one had mentioned them until now... I agree that it would be good to have them though, and that they should be listed separately. Looking at your data, the following properties seem to have reset-only sub-properties:

• animation
• background
• border
• font
• mask

Is that list exhaustive?

[cdoublev]

Is there anything broken with this approach?

MDN currently says that the constituent properties of border are border-width, border-style, and border-color.

That is also what the spec says, but this is misleading. Both could say that border sets border-top & co instead, which would also be misleading:

element.style.border = '1px'
console.log(...element.style) // Longhand names

Declaring border sets declarations for its longhands in element.style.

Is that list exhaustive?

Yes.

[tidoust]

That is also what the spec says, but this is misleading.

OK, we tend to align with specs when possible. I guess we'll stick to that for now. I note that the code you maintain uses the same approach on surface, for example when it defines border as (an expansion of) borderWidth, borderStyle and borderColor, so maybe that approach is not so misleading? ;)

[tidoust]

For animation, I see that you list animation-composition as one of the reset-only sub-properties. I'm wondering why, as the spec does not seem explicit that this is the case.

[cdoublev]

When you declare border using CSSStyleDeclaration.setProperty(), the spec says:

8. If property is a shorthand property, then for each longhand property longhand that property maps to, in canonical order, follow these substeps:
   1. Let longhand result be the result of set the CSS declaration longhand with the appropriate value(s) from component value list [...]

If you think implementations should set a declaration for border-width, border-style, border-color, please take a look at the algorithm for CSSStyleDeclaration.getPropertyValue(), to understand why this would not work.

The canonical order is defined in the property definition table, but it is always "per grammar" (which is not enough for some shorthand, but I disgress). For border, the grammar is <line-width> || <line-style> || <color>. So expanding to the border-<side> shorthands is misleading and incorrect, fair enough.

---

For animation-composition, see this resolution and the next one. Until the grammar of animation is updated, I consider animation-composition to always be omitted in the shorthand value, which is equivalent to defining it as being reset-only.

[tidoust]

If you think implementations should set a declaration for border-width, border-style, border-color, please take a look at the algorithm for CSSStyleDeclaration.getPropertyValue(), to understand why this would not work.

What I'm saying is that what we list under longhands includes intermediary shorthands, as defined in the spec, and that the logic to build the actual list of "true" longhands to apply this algorithm is up to consumers. That's another case where we need to document what the field contains.

For animation-composition, see this resolution and the next one. Until the grammar of animation is updated, I consider animation-composition to always be omitted in the shorthand value, which is equivalent to defining it as being reset-only.

Thanks for the pointers! We may take the opposite approach until the CSS WG sorts out their specs. We try not to be too "forward-looking" in Webref and I'm not sure how the resolution is going to be applied in practice. It seems to trigger backward-compatibility issues in that I would expect that animation-composition gets reset to replace by the following animation declaration in the example below, and that does not seem to be what currently happens in Firefox and Chrome at least:

animation-composition: accumulate;
animation: slide 5s linear infinite;

Or I don't understand what a reset-only sub-property entails, which is entirely possible ;)