[css-backgrounds] Make box-shadow a Shorthand Property

[Crissov]

• Level 3 box-shadow
• Level 4 box-shadow

box-shadow: none | <shadow>#
: {2,4} && inset? && ?

Since box shadows are frequently altered on hover etc., but not all of its components need to change, can we make them available independently?

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

[tabatkins]

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

[Loirooriol]

I guess text-shadow may also need this.

[Crissov]

Indeed. Unfortunately, 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>#
: [<'text-shadow-offset'> <'text-shadow-blur'>?] \ 
          && <'text-shadow-color'>?

[SebastianZ]

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>#
: <'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>#
: <'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 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

[ariarzer]

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

[LeaVerou]

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

[css-meeting-bot]

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

The full IRC log of that discussion

topic: Make box-shadow a shorthand
github: https://github.com//issues/4431
TabAtkins: we've discussed about this in the past
... people want to animate one bit of a shadow, like increasing the spread etc
+q to express support
... you can always use custom props and so on and it seems so straight-forward that I think we could try
https://github.com//issues/4431#issuecomment-790113613
... sebastian proposed a grammar (link above)
q+
TabAtkins: (describes linked proposal)
lea: I want to express support, this is a very common thing. It's one of the first examples I use for custom props
... is there an inset prop?
TabAtkins: yeah
https://github.com//issues/4431#issuecomment-790113613
lea: can we do it for text-shadow too?
ack lea
lea, you wanted to express support
TabAtkins: yeah, also in the proposal
ack dbaron
dbaron: I guess one of my reactions is that the stuff that background does is one of the most complicated parts of implementing value computations on CSS
... the code for dealing with that was a significant part of the old parser
TabAtkins: for this there is one controlling property
dbaron: true for backgrounds as well (for background-image)
... and you need to keep the whole list because you might inherit it somewhere where it matters
q?
TabAtkins: isn't this a common pattern like animation?
dbaron: yeah, but it's special code every time
smfr: should box-shadow-offset be further broken down into x/y offsets?
TabAtkins: [meh reaction]
q+
ack smfr
ack fantasai
fantasai, you wanted to mention that -position needs renaming 'cuz it's not a
ack fantasai
ack emilio
emilio: Regarding what dbaron said, not just about parsing complexity but also efficiency
emilio: you need to store 5 different arrays rather than one
present-
emilio: so it's also a bit more inefficient
fantasai: box-shadow-offset perhaps?
emilio: maybe OK if we consider these to be relatively uncommon
emilio: The parsing complexity is real. Background is the worst by far, but need to check also transitions/animations. It's not super amazing
TabAtkins: Question is, is linked list-valued properties something we want to add generally, or not
TabAtkins: the main q is whether adding more list-valued shorthands is ok, and if it's not we should not do it consistently
dbaron: I wouldn't say never do them but it's more expensive than you might thing
TabAtkins: curious, is the opinion different depending on "there's one length-controlling property vs. shortest wins"
dbaron: I don't think it makes a huge difference
... only if you truncate computed values perhaps
TabAtkins: that seems fine
Rossen: let's follow-up in the issue

[fantasai]

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 value (though the example of list-style-position: inside | outside was also mentioned).

[tabatkins]

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 originally. If that's the blocker, we can just do it.

[SebastianZ]

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 values like ruby-position or font-variant-position. Though names can of course be bikeshedded.

Sebastian

[SebastianZ]

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]

@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.

[SebastianZ]

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