W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: [css-ruby] Behavior of floats inside ruby

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 10 Aug 2014 19:47:01 +0100
Message-ID: <53E7BE25.9010709@inkedblade.net>
To: www-style@w3.org
On 07/23/2014 03:18 PM, Tab Atkins Jr. wrote:
> On Wed, Jul 23, 2014 at 4:19 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> Right now the CSS Ruby spec has a rule to "inlinize" the display types
>> of any boxes inside the ruby container. This is to prevent block-in-inline
>> splits of ruby structures and other such fun complications.
>>    See http://lists.w3.org/Archives/Public/www-style/2014Jul/0028.html
>> bz brought up the point that float handling isn't really considered in
>> the spec: if it contains a float, is the ruby structure the containing
>> block for that float, or, like regular inlines, does it get passed up
>> to the ruby structure's containing block?
>> Ruby is supposed to be a sort of fancy inline box: it breaks across
>> lines, its contents (ideally) participate in the line's justification,
>> etc. I think you could make an argument that ruby *annotations* are
>> little block containers, but the base text certainly isn't.
>> Also, I think it's probably best if the base and annotation layers have
>> similar behavior.
>> Therefore, imho, ruby containers should not trap floats.
>> Which brings us to, what *do* they do with floats? There are two reasonable
>> options here:
>>    A. Pass them up to the containing block, just like normal inlines do.
>>    B. Ignore 'float', similar to how we ignore block-levelness.
>> Since there are, afaik, no real use cases for putting floats inside ruby,
>> either option is fine. What do implementers prefer?
> Speaking as not an implementor, I think it should just be A.  Rubys
> are just inlines with more powers, and shouldn't act differently
> unless there's a good reason related to their rubyness.

The CSSWG took this up and agreed, so I've clarified the spec accordingly.

Received on Monday, 11 August 2014 16:46:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC