[css-break] Clarify how box-shadow should appear when a box is sliced #10171
Description
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.