- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Jul 2020 21:49:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `tight vs loose fit into a line box`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: tight vs loose fit into a line box<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5239<br> <emilio> fantasai: dauwhe made a nice diagram, we had a lot of discussion about this. We recently added the text-edge property to control what is the size of an inline box in terms of deciding what is the size of an inline box<br> <emilio> ... for the purpose of fitting on a line or not<br> <emilio> ... which allows us to trim the half-leading and a bunch of other sutff<br> <emilio> ... deciding whether something fits inside a linebox is deciding whether something fits into our own half or the leading but it may be ok if it leak outside of our half leading if it leaks only into the half-leading of the subsequent line box<br> <emilio> ... I'd call that loosely fitting. We do this for ruby<br> <emilio> ... we make the assumption that there's a linebox before and after with the same metrics as the root inline box<br> <florian> q+<br> <dauwhe> q+<br> <emilio> ... do we want to allow this for other kinds of content than ruby and if so what does that look like?<br> <astearns> ack florian<br> <emilio> florian: to be clear we don't try to detect collisions nor special-casing for first lines right?<br> <emilio> fantasai: right, if you enable this you have a decent chance of overlapping content<br> <astearns> ack dauwhe<br> <emilio> dauwhe: I drew this because we put a superscript in a paragraph and we break the vertical rythm and we hate this<br> <emilio> ... text-edge controls how the child inline affects the line height<br> <emilio> ... to make this work you couldn't even do the text-edge checks on the cap height you need to cut it all the way down to the x-height for the cap not to get into the half-leading of the previous line box<br> <emilio> florian: I think the text-edge lets us get rid of the green part of the problem, but we're left with the yellow part of the problem<br> <emilio> fantasai: so with the line layout model you could give negative margins you'd allow overlap up to the margin and not more<br> <emilio> ... one way to get this is to set margin-top: -half-leading on the element you want to allow bleeding<br> <emilio> ... but we don't have such a value right now<br> <emilio> ... various things we could do<br> <emilio> florian: it seems there are two models, A and B, with ruby using one and regular layout using another, but authors not having the choice<br> <emilio> koji: do you want to allow bleeding unconditionally or do you want to detect conflicts?<br> <emilio> fantasai: ruby doesn't detect conflicts so we'd do the same<br> <emilio> koji: but ruby is safe because it's usually in one side, but generally you may have superscript on one line and subscript in the previous one<br> <emilio> dauwhe: I'd be willing to take the risk of some ink overlap to preserve the regularity of my line spacing<br> <emilio> ... in the case shown here I wouldn't have many problems unless stuff goes over the font descent<br> <emilio> ... if you know the font you're using then it seems worth the risk<br> <emilio> florian: collision avoidance seems expensive to compute<br> <tantek> Is there a user accessibility (readability) concern though with overlapping ink that may need to override the web author not minding about some ink overlap?<br> <emilio> koji: this proposal seems limited to that purpose in the issue<br> <emilio> ... would like a more general thing<br> <emilio> fantasai: for example?<br> <Rossen_> q?<br> <devsnek> the heck<br> <emilio> koji: most dtp(?) allows to control the exact line pitch, risking overlapping content, which I think is a good model for CSS<br> <emilio> ... but this seems only half-way there<br> <jensimmons> present-<br> <emilio> florian: dtp seems useful only if you render it in the computer of the author<br> <emilio> astearns: doesn't CSS allow you to have that setting line-height to a fixed length?<br> <emilio> fantasai: not really. It's possible with the new line layout model with negative margins<br> <emilio> koji: I think what I said is in fantasai's (missed)<br> <koji> s/(missed)/the Absolute Model in page 52 of fantasai's presentation<br> <emilio> fantasai: so I think that you're proposing an absolute model where we don't care whether stuff doesn't fit at all, while loose has some limits, and I think is good for the author to be able to opt out of some of those<br> <AmeliaBR> q?<br> <emilio> ... I think we should not allow to switch it off for the whole page<br> <emilio> astearns: I like the idea of taking the behavior we already have for ruby<br> <emilio> ... and expose it to authors<br> <fantasai> s/opt out of some of those/opt out consciously on specific content, but not to set a mode switch that would allow any amount of conflicts that the author may not even see on their computer/<br> <emilio> AmeliaBR: on the topic of absolute line spacing we have the vertical-rythm module, but IIUC the way it works is avoiding conflicts but pushing stuff down a whole line<br> <emilio> ... but this allows to keep some overlap while keeping the vertical rythm<br> <emilio> dauwhe: everything is tradeoffs but sometimes avoiding the collision is worse than the collision itself<br> <emilio> fantasai: as long as it is still readable, but there may be cases where not, like if the top of the capital P overlaps with the bottom of the n<br> <emilio> koji: I think dauwhe's case is that when the author has control of the text and wants collisions instead of separation, and I think it's a reasonable request<br> <emilio> fantasai: I'm fine with collisions as long as authors are explicit, and the new line layout model allows that via negative margin<br> <emilio> fantasai: this probably needs a lot more thought and there's not any concrete proposal on the table<br> <emilio> AmeliaBR: seems like a problem worth solving<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5239#issuecomment-665301317 using your GitHub account
Received on Tuesday, 28 July 2020 21:49:29 UTC