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

(+public-html)

On Fri, Jan 10, 2014 at 1:15 AM, Taichi KAWABATA
<kawabata.taichi@gmail.com>wrote:

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


like <table><tr>...</></> auto-inserts <tbody>? what caused them having
such "strong resistance"? just curious.


-- 
Masataka Yakura
<myakura.web@gmail.com>