W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

Re: [csswg-drafts] [css-ruby] Box model / layout model for nested ruby containers (block axis) (#4980)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 06 May 2020 14:00:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-624667339-1588773643-sysbot+gh@w3.org>
The CSS Working Group just discussed `Box model / layout model for nested ruby containers (block axis)`, and agreed to the following:

* `RESOLVED: accept the proposal in the issue, with the caveat that it should apply only to in-flow content`

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> topic: Box model / layout model for nested ruby containers (block axis)<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4980<br>
&lt;emilio> florian: I think this one is a little bit more involved<br>
&lt;emilio> ... but the previous ones have cleared the way so that we have less moving pieces<br>
&lt;emilio> ... you can have a ruby inside the base or the annotation<br>
&lt;emilio> ... how these behave is interesting<br>
&lt;emilio> ... let's say we have a ruby inside of a base<br>
&lt;emilio> ... currently the spec defines this<br>
&lt;emilio> ... but it's not clear if the wrapping around descendants happens for only direct descendants or for all descendants<br>
&lt;emilio> ... I think the answer that makes more sense is that the base container is sized to wrap tightly around all the descendants<br>
&lt;emilio> ... and same for the annotation containers<br>
&lt;emilio> ... would probably be easier with a whiteboard<br>
&lt;emilio> fantasai: I think this model makes sense, if we add _in flow_ descendants<br>
&lt;emilio> ... I think it doesn't require the layout model to dig through nested levels other than via the sizes of the boxes, which makes this simpler<br>
&lt;emilio> xidorn: I think FF is currently doing something magically<br>
&lt;emilio> ... not sure how it'd differ in practice<br>
&lt;emilio> florian: I couldn't understand what magic FF is doing, but the effects of it seem less useful<br>
&lt;emilio> ... when you have nesting there's more spacing than there would be from this model<br>
&lt;emilio> ... and I don't know where it is coming from<br>
&lt;emilio> xidorn: [missed]<br>
&lt;emilio> koji: I agree that if you look at this case the proposed model looks good<br>
&lt;emilio> ... I have my preference to not define this because this is not demanded by users and this is a special case / divergence from inlines<br>
&lt;emilio> florian: that part of ruby is already different<br>
&lt;emilio> ... bases and annotations can take border / margin / padding<br>
&lt;emilio> koji: it seems this model requires looking at the ruby base of the bc<br>
&lt;emilio> florian: it's not the base which is sized different from inlines, it's the container which would be sized magically<br>
&lt;emilio> koji: which base?<br>
&lt;emilio> florian: let's have two levels, the outer rbc and the outer rb inside which there's a ruby ...<br>
&lt;emilio> ... all the ruby bases and containers are sized like inlines<br>
&lt;emilio> ... but the outer ruby base containers gets sized to wrap all the descendant bases and annotations<br>
&lt;emilio> fantasai: yeah the base container sizing needs to be special<br>
&lt;emilio> ... otherwise we can't account for "one of the bases has grown the font-size"<br>
&lt;emilio> ... it needs to grow to fit the bases that are inside them<br>
&lt;emilio> ... I'd go further to make this more consistent, we may want to consider that the base container is sized to fit their bases and any other base containers<br>
&lt;emilio> ... or maybe that it fits all of the margins of all of the inlines inside it<br>
&lt;emilio> ... in which case the definition would just work<br>
&lt;emilio> xidorn: it would not<br>
&lt;emilio> ... because annotations are not inlines<br>
&lt;emilio> fantasai: oh, that's right<br>
&lt;emilio> koji: ok<br>
&lt;xidorn> s/annotations are not inlines/annotation containers are not inlines/<br>
&lt;emilio> koji: can we mark it at risk?<br>
&lt;emilio> florian: not sure it's the right term for this, but we'll actually come back to this<br>
&lt;emilio> ... after this we have enough info to write the block layout<br>
&lt;emilio> florian: at risk means we can remove it when switching from cr to pr<br>
&lt;xidorn> florian: could you send me an example that you see Firefox's behavior unhelpful? from my testing there doesn't seem to be difference on annotations.<br>
&lt;emilio> fantasai: I think defining nested ruby so that it actually works is the right thing to do for the spec<br>
&lt;emilio> florian: and the spec was already hinting at this working, it just didn't say how<br>
&lt;fantasai> nested ruby testcase - works in Chrome and Firefox http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cruby%3E%3Cruby%3EABC%3Crt%3Eabc%3C%2Frt%3E%3C%2Fruby%3E%3Crt%3Exyz%3C%2Fruby%3E<br>
&lt;fantasai> It should continue to work, fundamentally. It's ok if the exact spacing is a bit off, but not ok if the two annotations paint on top of each other.<br>
&lt;emilio> florian: xidorn: the screenshots in the issue are just FF with a bit of photoshop<br>
&lt;emilio> xidorn: what's going on it's the whitespace taking height<br>
&lt;emilio> ... you can remove it and you see what you want<br>
&lt;emilio> fantasai: so currently nested ruby works in both Chrome and FF<br>
&lt;emilio> ... so we need to make sure that it keeps working correctly<br>
&lt;emilio> myles: nested ruby is actually pretty common in books<br>
&lt;emilio> astearns: agree, that's why I think we should define it in the spec<br>
&lt;emilio> RESOLVED: accept the proposal in the issue, with the caveat that it should apply only to in-flow content<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4980#issuecomment-624667339 using your GitHub account
Received on Wednesday, 6 May 2020 14:00:48 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:06 UTC