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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 23 Jul 2014 07:18:14 -0700
Message-ID: <CAAWBYDBSndbuTgqhLzA_F7UtwzC17sqJBi-n6LetBR95r+17Aw@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
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.

~TJ
Received on Wednesday, 23 July 2014 14:19:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC