Re: Fwd: Re: HTML Ruby Extension

On 02/13/2013 10:33 PM, Richard Ishida wrote:
>> Email from Fantasai, forwarded with permission.

I forwarded it yesterday per darobin's request... Anyway, responses inline. :)

>> While it is true that jukugo ruby and mono ruby are stylistic variants
>> of each other when applied to a single word, my understanding is that
>> in the case where ruby can be combined into a jukugo rendering, you
>> also want the annotations combined when rendered inline.
>
> That's certainly preferable, but see below...
>
>>> At the very least you should state this, and not leave people thinking
>>> that they
>>> have to use a tabular approach for jukugo base text.
>>
>> This would mean having two different CSS models (one column-based,
>> one row-based) for ruby. Is it necessary to allow both variants?
>> Can you give me an example where jukugo ruby is appropriate but
>> split inlining is preferable?
> [...]
>
> It worries me in that the very small tail of inline placement is wagging
> a large dog of markup changes here.

It's large with respect to the non-implemented segment of HTML5 ruby.

> If a renderer is expected to know how to handle markup intrinsically for
> applying parens, as you say, why can't it automatically rearrange the
> content for display when inline ruby is required?

Because that's much harder than just adding parens. If inlining is just
about adding parens, then every implementation can trivially support it.
Meanwhile fallback behavior in old engines is still sensible, and for
documents that require good behavior there, can be done with <rp>.

Also, I believe it's important that reasonable handling of ruby markup
should be easy for a new implementation that hasn't yet worked itself
up to rendering ruby yet; or for an implementation that never will get
there (e.g. a non-graphical browser).

> That way we can also avoid having two different CSS models, and make
> authoring simpler too, n'est-ce pas?

I don't think this actually makes authoring simpler. Right now if you
have double-sided ruby, you have two very different markup models
that you have to choose from depending on the structure of how the
annotations map to the bases. This is an authoring problem as well
as an implementation one, as it forces very different box structuring
in the CSS model between the nested-<ruby> vs. stacked-<rt> approaches.

The point of these changes is to have a single model, where HTML5's
simple ruby is considered the simplest possible case: one annotation
to one base, and no association across bases.

> Bear in mind that the browser will have to do some fancy footwork
> with the rb.rb.rt.rt model anyway in order to deal with line breaking,
> since a jukugo can be broken in the middle of the word. In that case
> the appropriate rt text must be moved to the next line block, with
> the base text.

Well, let's suppose we did things your way: use alternating rb/rt
structure for jukugo ruby *and* do fancy inlining. One of the two
is going to involve reordering. :)

I'd rather the inlining be simple and the jukugo ruby, for which
we have to create more complex structures anyway, have to deal with
interesting line-breaking.

> By the way, I think you are proposing the introduction of a second
> CSS model yourself, since I believe we need to support the current
> HTML simple ruby model, which allows rb.rt.rb.rt...

I'm not. I'm proposing a CSS model that can incorporate that model
as well as the full extent of XHTML Ruby, along with all the steps
in between. The box model for this hasn't been written yet, but it's
relatively straightforward.

If we decide we want to use Hixie's proposal for double-sided ruby,
however, then we need two different box models for ruby, and there's
no way to get around that. His proposal effectively requires two
box models, one for nested <ruby> and one for stacked-<rt> ruby.
(And an implementation that also wants to do XHTML Ruby would need a
third box model.)

~fantasai

Received on Thursday, 14 February 2013 23:08:47 UTC