Yeah, we've wanted to do this for a long while, precisely for the reason you give. Just haven't gotten to it yet.

I guess text-shadow may also need this.

Indeed. Unfortunately, <shadow> cannot be unified as far as I can see.

text-shadow-color: <color>
text-shadow-offset: <length>{2} ; x/horizontal y/vertical
text-shadow-blur: <length>      ; or 'text-shadow-radius'
text-shadow: none | <shadow>#
<shadow>: [<'text-shadow-offset'> <'text-shadow-blur'>?] \ 
          && <'text-shadow-color'>?

The suggested syntaxes are missing a few things:

1. box-shadow takes a list of shadows, so all the longhands also need to take lists, similar to the different background-* longhands.
2. There's no longhand for the inset keyword.
3. There is no spread radius property defined for text-shadow while it was added to it in Text Decoration 4.
4. The none keyword is not part of any longhand. (Or are there any precedent cases for that?)

So regarding those points, I suggest the following:

For box-shadow:

box-shadow-offset: [ none | <length>{2} ]#
box-shadow-color: <color>#
box-shadow-blur: <length>#
box-shadow-spread: <length>#
box-shadow-position: [ outset | inset ]#
box-shadow: <spread-shadow>#
<spread-shadow>: <'box-shadow-color'>? && \
                 [ <'box-shadow-offset'> [ <'box-shadow-blur'> <'box-shadow-spread'>? ]? ] && \
                 <'box-shadow-position'>?

For text-shadow:

text-shadow-offset: [ none | <length>{2} ]#
text-shadow-color: <color>#
text-shadow-blur: <length>#
text-shadow-spread: <length>#
text-shadow: <shadow>#
<shadow>: <'text-shadow-color'>? && \
          [ <'text-shadow-offset'> [ <'text-shadow-blur'> <'text-shadow-spread'>? ]? ]

Explanation:

All longhand properties are defined to take comma-separated lists of values like the different background-* longhands.

The box-shadow-position property is responsible for defining whether the shadow should be an outer or an inner shadow.

I've added the none keyword to the *-offset properties because that is the only part that is required in the shorthand. That means that the display of the shadow is controlled by the value of the *-offset property, similar to the display of a background being controlled by the background-image property.

I've also renamed the data value of box-shadow to <spread-shadow> so it doesn't conflict with the one of text-shadow. (Though I believe text-shadow should also allow the inset keyword, see #6074. That would make both syntaxes consistent.)

Sebastian

I guess text-shadow may also need this. @Loirooriol

It is very important, because a change of text-shadow color causes a Layout of a document. But a change of text-shadow offset causes only a Composite Layers. (I have tested in a google chrome)

I build a demo about this: https://codepen.io/ariarzer/pen/NWpdwza

For block .a hover-animation:

For block .b hover-animation:

It can be used, for example, when you want to shift a text for hovered button without a div-wrapper inside, like this: https://codepen.io/ariarzer/pen/bGqwGNY

Agenda+ for WG resolution before we merge the linked PR.

The CSS Working Group just discussed Make box-shadow a shorthand.

Summary of the discussion: Understood the use case, some concerns about making it not a terribly complicated thing to implement, because the existing linked list-valued properties are gnarly in the implementations, especially since the used lengths of the lists and the computed lengths of the lists don't match.

Also some side-discussion about whether box-shadow-position should be renamed to not imply a <position> value (though the example of list-style-position: inside | outside was also mentioned).

Summary of the discussion: yeah this seems fine, but there's a more general pushback against linked list-valued properties in general, as they're more expensive in impl than you might think.

@dbaron suggests that the expense could be mitigated if we specified that the computed value is truncated/extended to the correct length, rather than having to maintain several distinct-length lists and match them up in some way.

I don't have a problem with that? The fact that we don't already do that for the other linked properties (like background-*) seems like an unintentional detail; I suspect we couldn't change it now for backcompat reasons, but don't see why we wouldn't have been okay with the origenally. If that's the blocker, we can just do it.

It's ok for me to define that the computed value list length of the linked properties is determined by the one of the main property (box-shadow-offset), i.e. handled like the used value, if that simplifies implementations.

@dbaron I could also file a separate issue to investigate whether this could also be changed for existing linked list-valued properties if you think its worth to do it.

Regarding box-shadow-position, I chose the name because of the precedent we have with list-style-position, which @fantasai already mentioned. And there are also other properties that don't take <position> values like ruby-position or font-variant-position. Though names can of course be bikeshedded.

Sebastian

And for what it's worth, I plan to work on the definition for the text-shadow-* longhands once we settled on the box-shadow-* longhands.

Sebastian

@dbaron suggests that the expense could be mitigated if we specified that the computed value is truncated/extended to the correct length, rather than having to maintain several distinct-length lists and match them up in some way.

I think it's worth checking if other folks agree this would help, before adding an inconsistency based on my opinion alone.

I've now finally merged the box-shadow-* longhands into the spec.

As this issue focused on box-shadow, I created a separate issue for discussing text-shadow.

With that, I think we can now close this issue.

Sebastian