- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 15 Jul 2014 13:17:20 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style list <www-style@w3.org>
On Tue, Jul 15, 2014 at 1:07 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Specifically, what should happen with ruby display types on the root > element, and in combination with 'float' values other than 'none' and > position:absolute/fixed? > > A strict reading of CSS 2.1 section 9.7 says they compute to themselves, but > I'm not sure they make sense. > > For comparison, here's what flexbox says: > > If an element’s specified display is inline-flex, then its display > property computes to flex in certain circumstances: the table in > CSS 2.1 Section 9.7 is amended to contain an additional row, with > inline-flex in the "Specified Value" column and flex in the "Computed > Value" column. > > My personal preference would be to convert all the ruby display types to > "block" on the root and for float/abspos boxes. Agree, assuming this means the contents all wrap themselves in an anonymous ruby box (I haven't studied the box-generation algo yet). If it doesn't work consistently, I'd instead support explicitly defining block-ruby with basically that behavior (acts exactly like block; wraps its contents in an anonymous ruby box). On Tue, Jul 15, 2014 at 1:11 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 7/15/14, 4:07 PM, Boris Zbarsky wrote: >> A strict reading of CSS 2.1 section 9.7 says they compute to themselves, >> but I'm not sure they make sense. > > Which, by the way, suggests to me that CSS2.1 should explicitly list all the > display types it knows about and for others explicitly defer to the > specification that defines them, so people notice when a spec adds new > display types without defining how they should behave here. Agreed; having to explicitly monkeypatch the table like Flexbox does is annoying. ~TJ
Received on Tuesday, 15 July 2014 20:18:06 UTC