[css-borders-4] Allow declaring `box-shadow-offset` with a single value

[cdoublev]

I am sorry I did not comment on #4431 and #6083, but I did not know about them until today.

I think box-shadow-offset could be defined with none | <length>{1,2}# instead of none | <length>{2}#.

<spread-shadow> would have to be defined with <'box-shadow-color'>? && [none <length>{0,2} | <length>{2,4}] && <'box-shadow-position'>? with a prose saying that the first two <length>s are for box-shadow-offset, etc, and that it always serialize with two explicit <length>s in box-shadow, when other <length>s are not omitted.

[SebastianZ]

As noted in #8581, we could also introduce a new future-proof syntax that avoids ambiguities (while keeping the existing one for legacy reasons, of course).

The syntax suggested in the other issue uses slashes to distinguish the values:

<spread-shadow> = <modern-spread-shadow-syntax> | <legacy-spread-shadow-syntax>
<modern-spread-shadow-syntax> = <'box-shadow-color'>? && [ <'box-shadow-offset'> [ / <'box-shadow-blur'> [ / <'box-shadow-spread'> ]? ]? ] && <'box-shadow-position'>?
<legacy-spread-shadow-syntax> = <'box-shadow-color'>? && [ <'box-shadow-offset'> [ <'box-shadow-blur'> <'box-shadow-spread'>? ]? ] && <'box-shadow-position'>?

Sebastian

[SebastianZ]

And just to avoid that the notes from the other issue get missed, I mention them here as well.

Given that we also want to allow different values for the horizontal and vertical spread radius (and possibly for the blur radius as well), I suggest we rather introduce a new syntax and treat the current one as legacy syntax.

This is also similar to #6946.

And for a precedent where a new syntax was introduced, see the color functions in CSS Color 4.

Sebastian

[cdoublev]

And for a precedent where a new syntax was introduced, see the color functions in CSS Color 4.

RGB color functions always serialize with the legacy syntax. I hinted in #8566 it is for back-compat but I am not sure because I do not really see the conditions where it helps with that.

Therefore I am fine with the syntax you propose.

[LeaVerou]

I think allowing a single value in box-shadow-offset is a nice enhancement and I'd be in support.
I don't think the benefit is worth the drawbacks of moving to a different slash-based syntax however, and having to support both forever. I'm also unconvinced about the prevalence of use cases with 45deg offsets, though we can easily find out about that via an HTTPArchive query.

Furthermore, slashes are problematic, because there is no established precedence of operators (spaces, commas, slashes) across CSS, different properties use different precedences. E.g. in background slashes have a higher precedence than commas, whereas in font commas have a lower precedence than slashes.

[Loirooriol]

If it becomes possible to specify 1-2 offsets, 0-4 blur radii (#9125), and 0-2 spreads (#9123), then I think some delimiter will be needed.

[LeaVerou]

If it becomes possible to specify 1-2 offsets, 0-4 blur radii (#9125), and 0-2 spreads (#9123), then I think some delimiter will be needed.

Indeed — but at least we won't have to also maintain a separate legacy syntax.

[SebastianZ]

If it becomes possible to specify 1-2 offsets, 0-4 blur radii (#9125), and 0-2 spreads (#9123), then I think some delimiter will be needed.

Indeed — but at least we won't have to also maintain a separate legacy syntax.

I'm a little confused. When we introduce a new syntax, the existing one still needs to be supported.

Sebastian