[csswg-drafts] [css-break] Clarify how `box-shadow` should appear when a box is sliced (#10171)

jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-break] Clarify how `box-shadow` should appear when a box is sliced ==
The description at https://drafts.csswg.org/css-break/#valdef-box-decoration-break-slice does not seem to explicitly address the slicing of box shadows. There's an illustration there of how `box-decoration-break: slice` treats a _border_, which is straightforward, but it doesn't clarify how a _shadow_ should be treated.

See https://wpt.fyi/results/css/css-backgrounds/box-shadow/slice-block-fragmentation-001.html, which shows a test that currently passes in webkit and blink, but fails in gecko. IMO, gecko's result is what should happen, and the test expectation is incorrect, but I don't think the spec adequately addresses this.

When a box (with its decorations) is "sliced" into fragments, and its box-shadow is also "sliced", does the corresponding slicing of the shadow take account of its offset from the box? That's what gecko does, and to me it makes sense visually. Or does the shadow, although painted at an offset, get sliced at the same places as the box? That seems to be what the current test expects, but looks illogical.

With a more extreme example https://codepen.io/jfkthame/pen/yLrPrvr, where there's a simple yellow box that has a gray shadow, and then a cyan version of the box (with the same shadow) that is fragmented across columns, Firefox's rendering still looks reasonable, while both Chrome and Safari do things with the shadow of the sliced cyan box that just don't make any sense.

I'd like to adjust the WPT reference case to reflect the behavior I think is correct, but I also think an illustration in the spec to confirm this expectation would be useful.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10171 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 2 April 2024 10:32:23 UTC