[css-break-4][css-text-decor-4] Allow breaks to only affect text decorations

[SebastianZ]

With the introduction of text-decoration-trim, we also defined that it takes box-decoration-break into account. So box-decoration-break affects whether the text decoration is split or cloned across fragments.

Though box-decoration-break also affects other parts of the box, which may be styled differently regarding fragmentation.

Therefore, I suggest a way to differentiate between the layout-related and content-related parts. I see three solutions to this:

1. Extend box-decoration-break
   Change box-decoration-break so that it allows to distinguish to what it applies, e.g. via new keywords that target layout, background, and contents.

2. Make box-decoration-break a shorthand
   Turn box-decoration-break into a shorthand for different longhands for layout, background, and contents. I.e. you'd have box-decoration-break-layout, box-decoration-break-background, and box-decoration-break-content, which take slice and clone.

3. Introduce a new property
   As suggested in [css-text-decor-4] Allow percentages in text-decoration-trim #8403 (comment), we might also introduce a completely separate property like text-decoration-break.

See also #8535, which refers to allow targetting only the background (and suggests to go either with option 1 or 2).

Option 2 currently seems to make the most sense to me, as it aligns well with what we already have and is backwards compatible.

Sebastian

[SebastianZ]

Given Mozilla has an experimental implementation which they want to push forward, I add this to the agenda.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed [css-break-4][css-text-decor-4] Allow breaks to only affect text decorations.

The full IRC log of that discussion

<TabAtkins> SebastianZ: while discussing trim, I realized that box-decoration-break, it might be better to allow individual handling of text decors separate from the other box decorations
<TabAtkins> SebastianZ: you can change the decoration break independently from border and background, and only affected text decos
<astearns> q+
<TabAtkins> SebastianZ: I came up with three possible solutions. 1) extend box-deco-break with keywords so you can distinguish between the different deco parts
<TabAtkins> SebastianZ: 2) make box-deco-break a shorthand for the -layout, -background, and -content
<TabAtkins> SebastianZ: 3) intro a new property for the text-deco breaking
<TabAtkins> SebastianZ: there's a similar request asking for splitting the background-deco-break apart from box-deco-break, issues 3585
<TabAtkins> SebastianZ: my suggestion would go toward making box-deco-break a shorthand for the individual parts
<TabAtkins> SebastianZ: so we'd have box-deco-break-layout/-background/-content, which would all take slice|clone
<astearns> ack fantasai
<TabAtkins> fantasai: we preivously discussed splitting up into subprops
<TabAtkins> fantasai: but we didn't have strong use-cases for the independent control. I'd say that's probably still true
<jfkthame> +1 fantasai
<TabAtkins> fantasai: if someone had a good example of wanting it, I could see splitting them, but until that happens my inclination is to leave them combined
<TabAtkins> astearns: I was on the q to basically say the same thing
<astearns> ack astearns
<TabAtkins> astearns: it's also not clear to me that a decision on this has a compelling interaction with shipping text-deco-inset, we could decide on it later unless i'm misunderstanding something
<TabAtkins> SebastianZ: my use-cases were to individually handle the cloning of the decos, because I think that shouldn't be part of box-deco
<TabAtkins> SebastianZ: so styling text decos seems independent from the rest
<schenney> q+
<TabAtkins> astearns: id' characterize that as theoretical purity without an example of a layout that looks bad with paired control
<astearns> ack schenney
<TabAtkins> schenney: re:impl, I don';t think delaying a decision on having a separate deco-break property would make a difference to the impl at this time
<TabAtkins> schenney: to the impl of text-deco-inset
<TabAtkins> schenney: if you need to inset only the very first/last, or for every line, it's similar impl either way
<TabAtkins> SebastianZ: my suggestion for option 3, a separate property, if we want to go a different route we ccan't do that anymore if inset is already shipping, as it would be depending on box-deco-break
<TabAtkins> q+
<TabAtkins> SebastianZ: so if text-deco-inset is shipped we won't have the option 3
<astearns> ack TabAtkins
<fantasai> TabAtkins: not strictly true. We can make a new property that defers to box-decoration-break
<fantasai> TabAtkins: So there's space to do any of these options in the future
<TabAtkins> astearns: take back to the issue, if/when we have compelling cases we can resolve it again
<TabAtkins> fantasai: I think we do need to resolved on whether box-deco-break does affect it currently
<TabAtkins> fantasai: I think it should, having one prop to control them all, at first, is good'
<TabAtkins> SebastianZ: I think we already resolved on that, the spec says it does

[fantasai]

Summary: We won't make changes to the current spec. We can consider splitting out control of text-decorations from other box-decoration-break effects if there's a compelling use case for independent controls. Until that point, we keep the combined switch only.