Re: [css-ruby][css-writing-modes] The writing-mode property on ruby internal boxes

On Wed, Jul 29, 2015 at 10:37 AM, fantasai
<fantasai.lists@inkedblade.net> wrote:
> On 07/16/2015 10:38 PM, Xidorn Quan wrote:
>> Then I changed my mind. Similar to table cases, we should exclude ruby
>> base container and ruby text container from "Applies
>> to" of "writing-mode", but still allow that property to be applied on ruby
>> base box and ruby text box, so their content is
>> allowed to be orthogonal to the line (probably with an anonymous
>> inline-block inside instead of making those boxes themselves
>> orthogonal).
>
> This probably works. Although I'd lean towards making the ruby text
> box and base box handle the writing-mode themselves, similar to how
> inline-block can handle writing-mode changes themselves.

I don't quite agree with comparing those ruby boxes to inline-blocks.
At least ruby base box continues the text run of the line, so that
things like line break and justification work as if the box is just a
normal unbreakable span. It should behave more like an inline box than
a block. (Although it seems to me other impls currently treat ruby
base box like inline-block, but I don't agree with their behavior.)

>> About "ruby-position", I give up my proposed change to make it always
>> force the writing-mode. But we indeed need some change
>> to the rule for inter-character (though it is unrelated to my proposal
>> here).
>>
>> Since the anonymous box generation step happens after style computation
>> stage (as we need to know at least the display type of
>> both parent and children anyway), and both <rt> and <rtc> can be an
>> anonymous box, it will need some hack. My idea is:
>> Compute the "writing-mode" of an element to "vertical-rl" if
>> 1) the display type is "ruby-text" and its parent has "ruby-position:
>> inter-character", or
>> 2) the display type is "ruby-text-container" and the element itself has
>> "ruby-position: inter-character".
>> Note that, the computed value for ruby-text-container is not applied to
>> the container itself, but for being inherited by its
>> non-pseudo children.
>
> I'm okay with this, but I don't quite remember the cyclic computation
> problem we were discussing earlier. Does this solve that problem?

The cyclic computation issue raised by dbaron is conceptual, the issue was:
1. `display` value is computed to a different value if it is `inline`
or `run-in`, and the `writing-mode` is orthogonal to its parent
2. the `writing-mode` may be computed to a different value when
`display` value is `ruby-text-container` and `ruby-position` is
`inter-character`

So the cyclic dependency between `display` and `writing-mode` is still
unsolved conceptually. But given the computations above won't cycle
themselves, it isn't a real issue in this case.

- Xidorn

Received on Wednesday, 29 July 2015 01:40:56 UTC