`box-decoration-break` and inline elements

[captainbrosset]

CSS box-decoration-break is useful to repeat borders, backgrounds, etc. across fragments of a fragmented element.

Fragmentation can happen in multiple cases, but the most common case is when an inline element is fragmented across multiple lines. In this very common case, box-decoration-break works, and has worked for many years (modulo the need for the -webkit prefix on some browsers).

This repo's box-decoration-break feature isn't baseline high however.

I think it should, and perhaps we should create a separate feature that's about the support for box-decoration-break in other fragmentation examples, such as a fragment block element in a multicol container (which Safari doesn't support according to this BCD note This property is only supported for inline elements).

[captainbrosset]

@jamesnw what do you think about the above?

[jamesnw]

In this very common case, box-decoration-break works, and has worked for many years (modulo the need for the -webkit prefix on some browsers).

I think this is the key issue- because we don't account for prefixed properties (see #86), we simply don't have keys to back this support story. Support for the unprefixed box-decoration-break property is old in Firefox and very new in Chrome, so by our definition of baseline, it is not baseline high.

My hope is that when Webkit supports the unprefixed key, they will support the full spec, and it can remain as a single feature. If they continue to only support inline elements, then I think we'd want BCD to add a functional key so we could differentiate the partial support as a separate feature.

[captainbrosset]

The issue I see is that developers have successfully been able to clone their borders and background decoration across the various fragments of a multi-line inline element for a long time (see this 10 year old SO question), but we have no feature that matches this.

I tend to think that we should:

1. Look into making editorial decisions about accepting prefixed properties (BCD has a prefix: "webkit-" property which we could surface somehow too).
2. Define one feature for the inline support only of this property (because that's what people can do today), which uses the above prefix support.
3. Define another feature for the block support only. If it one day comes, it'll probably be considered as a new separate thing by developers (at least for some time, and later we can merge the features).

Related to this: an interop 25 proposal to unprefix the property. I know there's some interest from implementers on this. We'll have to see whether it actually gets selected next year, but if it does, then item 1 above is unnecessary.

CC @ddbeck for thoughts on this.

[ddbeck]

For this feature specifically, I do not think there's a plausible "clone text decorations on inline elements" feature. Just in the first two minutes of authoring such a feature, I'd have to ask myself: what's the specification URL for this feature? There's no such thing, since we'd be describing (in effect) the non-standard WebKit subset implementation. I'm very skeptical we'd be helping web developers by telling them that they can rely on a non-standard behavior.

In general, I would like us to be able to generate an annotation on limited availability feature to indicate useful, but not Baseline support stories. These would be cases like desktop only, mobile only, or works-fine-but-you-need-prefixes. See also: https://github.com/web-platform-dx/web-features/issues/1038.

If the only limitation were a prefix, then this feature would be a good candidate for such an annotation. But it's also a partial implementation. I think being able to report partial support, as in https://github.com/web-platform-dx/web-features/issues/915, would be a more transparent way to describe what's going on across browsers.