Re: [css-ruby] Should CSS Ruby be consistent with HTML5 Ruby?

On 01/08/2014 04:10 PM, kawabata taichi wrote:
>
> My point is that, as long as HTML5's categorization algorithm is
> applied, we no longer need ruby-text-container. The role of <rbc> of
> XHTML can safely be ignored.
>
> "Display" property is originally for non-HTML XML documents to apply
> the role of ruby to their element names, but if we nolonger need
> ruby-text-container as its role can be complemented by an algorithm,
> do we really need its value for "display" property?

No, we technically don't unless we want to support XHTML Ruby.
But since the ruby base container exists in the layout model,
there is no reason not to give it a display value. Also it
allows the ruby layout model to be more easily applied to
other types of markup, if an author finds it useful.
(CSS Ruby, like CSS Tables, isn't a semantic structure,
only a layout one.)

> One problem of HTML5 Ruby is that it can specify Ruby Bases and Texts
> in an implicit way (unlike XHTML ruby). This means that we no longer
> be able to select Ruby Bases by simply selecting the <rb> or <rbc>
> node, or Ruby Texts by <rt> or <rtc>.  This may cause some problem on
> accessibility, and we may need to consider to device the new selector
> to select Ruby Bases even if they are implicity defined.

While theoretically we can define pseudo-elements to match up
to the implicit layout containers, it's actually the semantic
grouping that's wanted for selection here. The easiest way to
do that would be for the HTML parser to create the missing
elements. The alternative would be for Selectors to have a
mechanism for creating pseudo-elements from markup patterns,
which would be a very complicated new feature.

~fantasai

Received on Thursday, 9 January 2014 08:05:55 UTC