Skip to content

[css-ruby-1] Propose to treat rtc with orthogonal writing-mode to be inter-character rather than using ruby-position #1773

@upsuper

Description

@upsuper

Motivation

In current spec, inter-character ruby is handled via ruby-position: inter-character, which would make the writing mode of ruby annotation container (rtc) vertical.

As discussed before, there are some difficulties for this mechanism from some kind of circular dependencies between properties. Specifically, display property depends on writing-mode of the specific element and its parent for blockification, while this mechanism would make writing-mode depend on display and ruby-position. Although in this specific case, the circular dependency can be resolved if we defined the handling steps clearly, it seems to be a broken approach in general.

There is another difficulty that, writing-mode is a property needs to be locked at very early stage of style calculation, because font metrics depends on this property, and font metrics may be used in various properties (e.g. for ch, ex units), which means the fixup of this property need to be done before other properties get computed. This would add unnecessary complexity to style cascading, at least for Gecko (especially our new style engine, Stylo), because we generally do all the style fixup after cascading all properties.

Another issue is that, setting writing-mode on ruby annotation container is not enough, because there could be ruby annotation box which don't inherit from ruby annotation container. e.g. in a form like <ruby>我<rt>ㄨㄛˇ</rt>起<rt>ㄑㄧˇ</rt>來<rt>ㄌㄞˊ</rt>了<rt>˙ㄌㄜ</rt></ruby>. In this case, writing-mode would not be set properly.

Proposal

I propose that we use a different approach to implement inter-character: when the ruby annotation container has an orthogonal writing mode [wm1] to that of its base container [wm2], the annotation container is put at the wm2 inline-end of the base container, and layout in wm1 direction, so it looks like inter-character when it has only a single ruby annotation inside. Then we can remove inter-character value from ruby-position property.

It would require author to write something like

<style> rtc { writing-mode: vertical-rl; } </style>
<ruby><rtc>ㄨㄛˇ</rtc><rtc>ㄑㄧˇ</rtc><rtc>ㄌㄞˊ</rtc><rtc>˙ㄌㄜ</rtc></ruby>

This would avoid the difficulties for handling style fixup described above. There is a side benefit of this approach that, it would allow horizontal-in-vertical style inter-character ruby, although we don't see many usecases for that, it removes the special case that inter-character only takes effect in horizontal writing mode, and it only generates vertical-rl writing mode, so I think this approach looks more elegant in general.

Drawbacks

The using of <rtc> is unfortunate for this kind of solution. But if we want to have <rt> work as well in this case, we can specify that the anonymous ruby annotation container inherits from its ruby annotation box children somehow. Since anonymous boxes are created after style cascading, I think this should be easier to do than resolving the style dependency.

There would be another issue that in a browser which doesn't support treating orthogonal <rtc> as inter-character, it would render the annotation vertically on top. This may become a larger problem if we propagate style from <rt> back to anonymous ruby annotation container. Having ruby-position: inter-character forcing writing mode on rtc wouldn't have this problem.

Alternatives

Probably we can create an anonymous box inside ruby annotation box which would have the new writing-mode. With this, we would not need to worry about style computation anywhere else, because anonymous box cannot be styled by author style. But the problem is that we cannot have any element inherit from an anonymous box, that means element inside ruby annotation box would be in a weird situation in that case.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions