[css-backgrounds-4] Allow repeating `none` in `box-shadow-offset`

[cdoublev]

none, none is currently valid in box-shadow but not in box-shadow-offset.

animation, transition, scroll-timeline, view-timeline, accept declaring none with other values and repeating it in a coordinating value list. In #8440, I suggested restricting none in these properties, before considering some (contrived) use cases.

.box {
  box-shadow: 0px 0px, black none 1px;
}
.box:hover {
  box-shadow-offset: 1px 1px, 2px 2px;
}

Nit: stacking {1,2} and # does not seem invalid but some spec readers may think [ <length>{1,2} ]# is clearer.

[tidoust]

Nit: stacking {1,2} and # does not seem invalid but some spec readers may think [ {1,2} ]# is clearer.

I don't personally mind the stacking as a reader. However, I note that the Value Definition Syntax does not envision that stacking for now, and some parsers do not support this syntax. I reported this as an issue to CSSTree for instance, see csstree/csstree#249

[tabatkins]

Ah, we should allow that stacking pattern probably. (Probably we should just allow all of them; I'm not sure why we're being so precious about what stacks are allowed when they can all be expressed with brackets anyway.)

[tabatkins]

Ah no, we have that for a reason actually - given that #{1,2} is its own single multiplier (comma-separated list of 1-2 repetitions), it was possibly confusing to have {1,2}# be different

[cdoublev]

#{0,} is valid but also confusing (one or more, or zero or more?).

---

I understand that the use of none in coordinating value list does not get much attention (#2031 has been around for 5 years). Authors will use it alone in 99% of cases.

People are saying that implementing coordinating list value is hard in the transcript for #7164. I am not sure I identify the exact nature of the complexity but it could perhaps be decreased a bit by consistently allowing none to repeat in these shorthands and the corresponding coordinating list base property.

And why prevent the author from using none with other values, even if it turns out that it is always useless for the corresponding shorthand?

Below is a summary of the restrictions on none in shorthands taking a coordinating list value:

• animation
  • animation allows none with other longhand values
  • animation and animation-name allow repeating none
• background
  • background allows none with other longhand values
  • background and background-image allow repeating none
• mask
  • mask allows none with other longhand values
  • mask and mask-reference allow repeating none
• transition
  • transition allows none with other longhand values
  • transition disallows repeating none (in prose)
  • transition-property disallows repeating none
• scroll-timeline and view-timeline
  • *-timeline allows none with other longhand values
  • *-timeline allows repeating none
  • *-timeline-name diallows repeating none

In my opinion, box-shadow, transition (again, cf. #2031), scroll-timeline-name, view-timeline-name, should allow repeating none.

[tabatkins]

#{0,} is valid but also confusing (one or more, or zero or more?).

I'm not sure what's unclear about it. # by itself indicates one or more repetitions, but "It may optionally be followed by the curly brace forms, above, to indicate precisely how many times the repetition occurs, like #{1,4}.", so #{0,} indicates zero or more repetitions. (It would probably be more clear as #?, but sometimes #{0,} might parallel another construction that makes it the most clear way to express this.)

[cdoublev]

Right, sorry, I thought the application order was something you did not want to define explicitly, but it already is...

These stacks each represent the later multiplier applied to the result of the earlier multiplier.

... and this has nothing to do with the reason why {2}# is confusing. # just cannot apply on {2} in this order. Ok.

[SebastianZ]

@cdoublev provided good reasoning for none being repeatable, so I've edited it in.

The discussion about stacking multipliers together is orthogonal to that issue (and with the change irrelevant for that specific case). So we should create a new issue for that.

Also, box-shadow so far only allows both offset values to be defined together, i.e. {2}. Though this actually seems to be an arbitrary restriction to me and authors often define both to be the same, so I created #8581 to discuss allowing a single value for the offset.

Sebastian

[SebastianZ]

I created #8581 to discuss allowing a single value for the offset.

I just saw that @cdoublev already created #8568, so I closed my one as duplicate.

Sebastian

[Loirooriol]

Reopening because if none can be used in the list, this needs to change too:

Computed value: either none or a list, each item a pair of offsets (horizontal and vertical) from the element‘s box

And also I don't see the definition of what none is supposed to do.

[cdoublev]

And also I don't see the definition of what none is supposed to do.

Yes, I realized that too. Considering that none can now be intertwined with other shadow settings, I think it cannot be defined as shadow canceling (which indicates no shadows in CSS Backgrounds 3) but rather as equivalent to 0px 0px.

[Loirooriol]

Then I'm confused, what's the point of having none if it just means 0px 0px?

[cdoublev]

Nevermind. I think it should cancel the shadow, as defined in CSS Backgrounds 3, similarly as in animation:

if the animation name is none then there will be no animation

But it seems even weirder that box-shadow-offset has this control.