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

>> In <52CE5847.8080509@inkedblade.net>, 
>> fantasai 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.)

Actually, in HTML5 ruby, ruby-base-container may be split by ruby texts
(e.g. <ruby>A<rt>a</rt>B</rt>b</ruby>), and thus they are described as a
list of DOM ranges. I'm afraid that the existance fo ruby-base-container
may cause a misunderstanding that ruby bases exist as a single DOM range.

> > 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.

Inserting (creating) the missing elements by HTML parser has several
problems.  e.g.

1. XHTML documents, extensively used in EPUB books, are not the subject
   of HTML5 parsing, thus this approach can not save the existing
   Electronic Books,

2. Changing HTML specification to insert missing elements by HTML parser
   may cause problems with past HTML documents with JavaScript which do
   not assume such element insertion.

3. HTML people has strong resistance with such an automatic element
   insertion mechanism, based on past experiences.

Regards,

-- 
---------------------------------------------------------------------
  kawabata.taichi@gmail.com       KAWABATA, Taichi

Received on Thursday, 9 January 2014 16:15:57 UTC