- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Aug 2023 16:33:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-inline-3] It's impossible to use `text-box-trim` without changing line progression within the paragraph``, and agreed to the following: * `RESOLVED: Three longhand properties as proposed with two linked by a shorthand, names to be bikeshed, one issue for each to work them out` <details><summary>The full IRC log of that discussion</summary> <emeyer> fantasai: Two issues are open on the fact that the current way we’ve set up this trimming feature depends on a property that has two different effects<br> <emeyer> …I’ll call one the leading-trim effect<br> <emeyer> …This is the effect of taking the first line box and trimming down to some metric rather than the full ascent of the font and half-leading and so on<br> <emeyer> …Same thing on the bottom edge<br> <emeyer> …The second, the line-box-contain effect<br> <emeyer> …Line boxes can grow, but this effect allows us to say for an inline box, rather than using ascent metrics, use another metric like the cap-height<br> <emeyer> …That way an accent on top of a character can leak outside the line box and that’s okay<br> <emeyer> …The issues say it would b e useful to separate these two<br> <emeyer> …An author might want to use one over the other<br> <emeyer> [some things missed]<br> <emeyer> …Proposal is to split text-box-edge into text-box-edge and text-line-edge (names subject to bikeshed)<br> <emeyer> …Does this make sense or do we need more description?<br> <emeyer> astearns: It makes sense to have separate properties; the neames should give an idea of the connection between them<br> <emeyer> …Not sure ‘box’ and ‘line'<br> <emeyer> …do that<br> <emeyer> jensimmons: Use case: I might be an author who wants my paragrtaph box to line up with a floated image, so I need to chop off the paragrpah’s top whitespace<br> <emeyer> …So I use text-box-edge and chop it to the cap height or x-height or whatever<br> <emeyer> …Separate, there are accent marks or super/subscripts and I get weirdness where extra line box height happens<br> <emeyer> …I want the spacing to be regular throughout the text so the vertical rhythm is consistent<br> <emeyer> …I need to be able to say I want to use this different font metric than is used to line up block edges with floats or whatever<br> <florian> q+<br> <emeyer> dbaron: It wasn’t clear to me which property you were proposing to split<br> <emeyer> fantasai: Right now, leading-trim works at the intersection text-box-trim (which looks up text-box-edge)<br> <emeyer> …text-box-edge says what metric you care about: ascent, cap-height, something else<br> <emeyer> dbaron: And that only applies to inlines?<br> <emeyer> fantasai: Right<br> <florian> q-<br> <florian> q+<br> <emeyer> dbaron: You want to let people set inline and block trimming differently<br> <emeyer> fantasai: Yes<br> <emeyer> jensimmons: I think it will become best practice for authors to put into resets a thing to change how box models work for lines and line boxes<br> <emeyer> …Separately, you might need to do something different in certain places<br> <emeyer> dbaron: The one that interacts with text-box-trim needs to be narrowed?<br> <emeyer> jensimmons: I think so, yeah<br> <emeyer> dbaron: Okay, this makes sense<br> <astearns> ack florian<br> <emeyer> florian: Even if you’re not looking at different font metrics, in the old model you had to turn on line re-jiggling<br> <emeyer> …With this you can say this is what I do to boxes, leave the lines alone<br> <emeyer> jensimmons: I do think authors think of these things differently<br> <florian> s/on line re-jiggling/on line re-jiggling to be able to access the box trimming<br> <emeyer> …Having them tied together doesn’t quite make sense<br> <emeyer> fantasai: Going into the re-jiggling of the properties, we end up with three longhands<br> <emeyer> …text-line-edge to measure line edges<br> <emeyer> …text-box-edge<br> <emeyer> …text-box-trim, which sets the side you trim<br> <emeyer> …From there, we can create a shorthand which sets side and trim in one shot<br> <emeyer> …So an author who want to affect line sizing would set tex-tline-edge, which inherits<br> <emeyer> …An author could set text-box-edge to say which boxes are trimmed<br> <emeyer> …We can also eliminate the longhand of text-box and have a property that just sets the sidess with the trim<br> <emeyer> …The advantage of longhand is that you can set these things separately without needing variables<br> <emeyer> …That’s an open question of whether to have the longhands, or just have the shorthand<br> <florian> q+<br> <emeyer> …Another open question is whether the initial value of etext-box-edge shoudl be an auto that looks up text-line-edge<br> <emeyer> s/shoudl/should/<br> <astearns> ack florian<br> <emeyer> florian: I think we do want the longhands<br> <emeyer> …One seems to be linguisitcally dependent, the other not<br> <emeyer> …Not sure what we should call the shorthands, but we can figure that out<br> <emeyer> astearns: Should we resolve on having three longhand properties and have one issue for each?<br> <emeyer> fantasai: Seems fine; I would also add the shorthand to encompass two of them<br> <emeyer> astearns: I would really like to see examples, particularly of the reset things Jen was talking about<br> <emeyer> …Showing the motivation for having a separate property<br> <emeyer> …Then another example showing how you would use the properties together<br> <emeyer> RESOLVED: Three longhand properties as proposed with two linked by a shorthand, names to be bikeshed, one issue for each to work them out<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8829#issuecomment-1699500216 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 August 2023 16:33:06 UTC