- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Jul 2022 16:48:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-text-decor] Feature request - add a property text-decoration-length that modifies the length of the underline`, and agreed to the following: * ``RESOLVED: Remove text-decoration-skip-inset, add `text-decoration-trim: <length> <length>?`, follow-up for improvements and issues`` <details><summary>The full IRC log of that discussion</summary> <emilio> topic: [css-text-decor] Feature request - add a property text-decoration-length that modifies the length of the underline<br> <emilio> github: https://github.com/w3c/csswg-drafts/issues/4557<br> <emilio> fantasai: there's been a variety of requests for controlling the length of underlines<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/4517<br> <emilio> ... we have some spec text to ensure that underlines break between words<br> <emilio> ... but we've been asked to provide more control<br> <emilio> ... suggestion is to define a new `text-decoration-trim` property<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/4557#issuecomment-1117735704<br> <emilio> ... which would take a `<length-percentage>`<br> <emilio> ... and shortens the underline by the given amount<br> <emilio> ... there's the question of what's the percentage relative to<br> <emilio> ... so we could start with `<length>`<br> <emilio> ... on block containers we could apply it to both sides of the block<br> <emilio> ... on inlines it should follow the behavior of box-decoration-break<br> <emilio> ... negative values are allowed and would extend the text-decoration<br> <emilio> ... percentages were suggested to be relative to the containing-block<br> <emilio> ... there's some effect animating where that'd be useful for<br> <fantasai> https://www.w3.org/TR/css-text-decor-4/#text-decoration-skip-inset-property<br> <emilio> ... if we want to discuss percentages we can do that now but I'd like to add this to the spec and remove `text-decoration-skip-inset`<br> <emilio> ... as described above wrt inlines / blocks<br> <emilio> astearns: is text-decoration-skip-inset implemented anywhere?<br> <emilio> fantasai: I don't think so<br> <emilio> astearns: is trim the best word when negative lengths can be an extension?<br> <tantek> just like indent negative means outdent?<br> <fantasai> yep<br> <emilio> fantasai: I think so since negative trim is to extend the same way as negative extend is trim, I think use case is mostly trimming<br> <emilio> florian: the property that would be dropped had an auto value<br> <emilio> ... should this have the same value?<br> <emilio> ... if you want the browser to trim by the right amount<br> <emilio> ... so we'd be losing this but we could reintroduce this if wanted<br> <emilio> fantasai: yes<br> <emilio> astearns: fantasai, would this go into your initial write-up? or should we decide later?<br> <emilio> fantasai: I don't think an auto value is particularly useful if you can specify lengths<br> <tantek> +1 fantasai, worth documenting an actual use-case of for 'auto', like what problem is it solving?<br> <fantasai> it's solving the problem documented in https://www.w3.org/TR/css-text-decor-4/#text-decoration-skip-inset-property<br> <emilio> florian: in CJK when you have a piece of content and they might be next to each other, and without skipping you might not notice that they're different words<br> <emilio> ... you might want to say "browser, just do something"<br> <faceless> Easy enough to define "auto" as "the width of the underline" perhaps?<br> <emilio> ... you could do "3px" or something, but then why that?<br> <emilio> fantasai: I think the width of the underline was my initial thought<br> <emilio> ... though might not be useful if the underline is very big? So might be more like `min(0.1em, underline-width)` or something<br> <emilio> florian: do we want browser guidance here?<br> <emilio> fantasai: I think we want to do that so people know what to implement<br> <emilio> florian: [missed]<br> <emilio> fantasai: one of the problems we have with percents is that we have percentages for word-spacing etc to reference the font-size of the element? Maybe we can do that<br> <astearns> s/[missed]/I have wanted this without having an opinion on a specific value/<br> <florian> s/[missed]/As one data point, I have authored CJK content where I've wanted this, without having a view as to how big it should be./<br> <emilio> fantasai: happy to start with `<length>` / `<length>|auto` / then add percentages<br> <emilio> ... probably worth starting with length and add things afterwards<br> <emilio> plinss: question, removing lengths from the end of the decoration, or also from the skipping between descenders and so<br> <emilio> fantasai: just end<br> <emilio> astearns: we discussed that and run into implementation difficulties<br> <emilio> plinss: ok, just wanted clarification, would be weird if it trimmed from both<br> <florian> s/do we want browser guidance here?/can we leave it as browser defined, or do browsers want guidance here?/<br> <jensimmons> `text-decoration-trim: <length>` for the resolution<br> <emilio> jfkthame: one thing I wondered is whether we want two values, one for start, one for end<br> <emilio> fantasai: makes sense<br> <emilio> jensimmons: separate for start/end could be declared all at once<br> <tantek> q+ to ask about interactions with text-overflow<br> <emilio> ... could see authors creating some kind of drop-shadow-like effects<br> <fantasai> -> illustration https://github.com/w3c/csswg-drafts/issues/4517<br> <emilio> ... specially when combined with underline offset/thickness<br> <dbaron> maybe also when combined with italic/oblique<br> <emilio> ... there's the question of what happens with inline-box breaking<br> <emilio> astearns: that's the part where it'd follow box-decoration-break<br> <astearns> ack tantek<br> <Zakim> tantek, you wanted to ask about interactions with text-overflow<br> <emilio> tantek: just wanted to add with potential interactions with text-overflow: ellipsis<br> <emilio> ... do you want this always, only when there's no text overflow, do you want to trim from the ellipsis start...?<br> <emilio> fantasai: can't even remember whether the ellipsis gets underlined or not atm<br> <emilio> astearns: if you're not using trimming at all, it seems this is a higher level question, you should get control for whether the underline applies to the end overflow<br> <emilio> plinss: my intuition would be that the end would be that the end would be where it'd be without text overflow<br> <emilio> fantasai: [missed], something about box-decoration-break<br> <emilio> plinss: I like separate start/end, provides more interesting animation possibilities<br> <fantasai> box-decoration-break defaults to slice, which would get the behavior plinss describes<br> <emilio> RESOLVED: Remove text-decoration-skip-inset, add `text-decoration-trim: <length> <length>?`, follow-up for improvements and issues<br> <emilio> florian: could I ask people familiar with in-design and similar software if they have auto values and how it works if so?<br> <emilio> astearns: don't recall<br> <emilio> astearns: will ask about in-design underlines<br> <emilio> fantasai: should I add the definitions with auto / percentages in the first draft?<br> <emilio> astearns: I think it'd be good to add at least a note<br> <emilio> florian: either that or put the value in with an issue on how to define it<br> <emilio> fantasai: if people are fine with me adding it in I'd just do that since it makes it easier to discuss<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4557#issuecomment-1183456098 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 July 2022 16:48:18 UTC