- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 16:19:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-text-decor-4] Allow percentages in `text-decoration-inset` ``, and agreed to the following: * `RESOLVED: add %s, and they resolve on either sum of segments or individual segments depending on b-d-b` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> SebastianZ: We already introduced text-decoration-inset, takes a <length><br> <TabAtkins> SebastianZ: for other use-cases like animating the line from 0 to a length, it should be allowed to add percentages to the proeprty<br> <TabAtkins> SebastianZ: this discussion was going back and forth on how to do it<br> <TabAtkins> SebastianZ: especially wrt box-decoration-break<br> <TabAtkins> SebastianZ: I think we concluded that we can make it so %s either take into account the total width of the decoration, or when you set box-dec-break:clone, it takes the individual widths of the broken boxes<br> <TabAtkins> SebastianZ: there were also use-cases mentioned regarding the animation itself<br> <TabAtkins> SebastianZ: sometimes you want it to be animated for each line individually, with different speeds, sometimes you want a constant speed<br> <TabAtkins> SebastianZ: I think with this proposal you can achieve both<br> <TabAtkins> SebastianZ: %s give individual speeds, lengths give constant speed<br> <TabAtkins> astearns: so I understand the area, but what is the specific change to be resolved on?<br> <TabAtkins> SebastianZ: to add %s to the property<br> <TabAtkins> SebastianZ: there are many pages that underline a link when you hover it, with the underline growing into place<br> <kbabbitt> q+<br> <TabAtkins> SebastianZ: so q was just how %s apply to the deco boxes<br> <TabAtkins> astearns: so we've already added %s and just need to resolve on how they work?<br> <TabAtkins> SebastianZ: not added yet, due to this issue<br> <astearns> ack kbabbitt<br> <TabAtkins> kbabbitt: if i'm understanding correctly, 50% means you don't get a deco, bc you've taken half the width from each end, right?<br> <TabAtkins> SebastianZ: yes<br> <TabAtkins> kbabbitt: what if I'm < 50%?<br> <astearns> s/< 50%/> 50%/<br> <dbaron> I think kbabbitt perhaps meant to ask > 50% :-)<br> <TabAtkins> SebastianZ: so the value cuts the deco on each side, 50% is 50% of each side, so no deco at all<br> <TabAtkins> kbabbitt: so what about < 50%?<br> <TabAtkins> SebastianZ: it's based on the width of the deco box, so if the box is 100px and you set 10%, it's 10px chopped off each end<br> <TabAtkins> kbabbitt: [works thru the math again...]<br> <TabAtkins> kbabbitt: sorry, >50%<br> <flackr> q+<br> <flackr> q-<br> <TabAtkins> SebastianZ: I interpret that as cutting more than half<br> <TabAtkins> SebastianZ: you can specify two values, one for the start and one for the end<br> <TabAtkins> SebastianZ: so you cut from each side<br> <kizu> Yep, like 70% 10% — will be 20% width, offset by 70% from one side, and 10% from another, so you could animate it moving etc.<br> <TabAtkins> SebastianZ: so >50% just cuts more<br> <TabAtkins> florian: so to clarify if the *sum* of both is >100% it's invisible, right?<br> <TabAtkins> SebastianZ: yes, that's a better way to put it<br> <dbaron> >=, even :-)<br> <TabAtkins> TabAtkins: how does it react to box-deco-break, then?<br> <TabAtkins> SebastianZ: you have slice and clone<br> <TabAtkins> SebastianZ: with slice, you use the total width of the deco box. if it's split you count the sum width of the fragments<br> <TabAtkins> SebastianZ: but with clone each fragment is considered individually<br> <TabAtkins> SebastianZ: (this works the same with length values,, it's not % specific)<br> <flackr> q+<br> <astearns> ack flackr<br> <TabAtkins> flackr: what does the % resolve against when there are multiple breaks?<br> <TabAtkins> SebastianZ: [re-explains]<br> <TabAtkins> flackr: so I'm worried that we can't have a computed length for the inset. that's not how most length-percent properties work<br> <TabAtkins> TabAtkins: a number of layout-related %s are in the same bucket<br> <TabAtkins> flackr: ok, that's fine then<br> <dbaron> BTW, some of this also seems interesting in the context of bidi-fragmentation, where bidi reordering splits up an inline<br> <TabAtkins> flackr: so with slice... you extend from the first break to the last break and it's the total length of all the breaks<br> <TabAtkins> astearns: so proposed resolution is we add %s, and they resolve on either sum of segments or individual segments depending on b-d-b<br> <TabAtkins> RESOLVED: add %s, and they resolve on either sum of segments or individual segments depending on b-d-b<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8403#issuecomment-4178982235 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 16:19:58 UTC