- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 29 Oct 2025 16:48:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-break-4][css-text-decor-4] Allow breaks to only affect text decorations`. <details><summary>The full IRC log of that discussion</summary> <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<br> <TabAtkins> SebastianZ: you can change the decoration break independently from border and background, and only affected text decos<br> <astearns> q+<br> <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<br> <TabAtkins> SebastianZ: 2) make box-deco-break a shorthand for the -layout, -background, and -content<br> <TabAtkins> SebastianZ: 3) intro a new property for the text-deco breaking<br> <TabAtkins> SebastianZ: there's a similar request asking for splitting the background-deco-break apart from box-deco-break, issues 3585<br> <TabAtkins> SebastianZ: my suggestion would go toward making box-deco-break a shorthand for the individual parts<br> <TabAtkins> SebastianZ: so we'd have box-deco-break-layout/-background/-content, which would all take slice|clone<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: we preivously discussed splitting up into subprops<br> <TabAtkins> fantasai: but we didn't have strong use-cases for the independent control. I'd say that's probably still true<br> <jfkthame> +1 fantasai<br> <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<br> <TabAtkins> astearns: I was on the q to basically say the same thing<br> <astearns> ack astearns<br> <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<br> <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<br> <TabAtkins> SebastianZ: so styling text decos seems independent from the rest<br> <schenney> q+<br> <TabAtkins> astearns: id' characterize that as theoretical purity without an example of a layout that looks bad with paired control<br> <astearns> ack schenney<br> <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<br> <TabAtkins> schenney: to the impl of text-deco-inset<br> <TabAtkins> schenney: if you need to inset only the very first/last, or for every line, it's similar impl either way<br> <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<br> <TabAtkins> q+<br> <TabAtkins> SebastianZ: so if text-deco-inset is shipped we won't have the option 3<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: not strictly true. We can make a new property that defers to box-decoration-break<br> <fantasai> TabAtkins: So there's space to do any of these options in the future<br> <TabAtkins> astearns: take back to the issue, if/when we have compelling cases we can resolve it again<br> <TabAtkins> fantasai: I think we do need to resolved on whether box-deco-break does affect it currently<br> <TabAtkins> fantasai: I think it should, having one prop to control them all, at first, is good'<br> <TabAtkins> SebastianZ: I think we already resolved on that, the spec says it does<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12947#issuecomment-3462660828 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 October 2025 16:48:56 UTC