Re: [css-ruby] About Ruby anonymous box creation.

I understand that; this is not like one is correct and the other is wrong, but rather pros/cons discussion I think.

HTML needs to define what semantics each element means, and I’m all good with that part. What makes the logic completed is that, currently the logic handles when the numbers of base and annotation do not match, when base is missing, or when there are inter-element whitespaces. That part could be either semantics or layout, and I like such cases consistently handled for HTML, XHTML, and XML.

If HTML has interfaces to retrieve annotations from bases, it makes more sense for HTML to define the logic in that detail. However, there’s no such use in HTML and rendering tree is the only user of the logic as of now, so implementers need to write rendering code based on the logic in HTML spec.

That’s one cons, but the biggest cons with the separation is that, it makes discussions harder, by different people, different groups, in different time frame.

I think in this case, the cons of the separation wins over the benefit.

[1] http://dev.w3.org/csswg/css-ruby/#ruby-display


On Apr 4, 2014, at 10:03 AM, kawabata taichi <kawabata.taichi@gmail.com<mailto:kawabata.taichi@gmail.com>> wrote:

Dear Koji,

I had the same thoughts, too, and I've discussed it with Robin a while
ago.  His opinion is as follows.

Robin> It is important that categorisation and pairing are supported in HTML
Robin> because that is what describes the actual semantics of the ruby model.
Robin> Otherwise, all that we would have would be a DOM tree with only limited
Robin> meaning. CSS should only handle the rendering aspects because you want
Robin> the meaning of the document to stay the same even if the style changes.

I think that the current ruby segmentation and categorisation
algorithm, that is somewhat complicated, is due to the fact that it
needs to keep the compatibility with past (X)HTML standards and
JavaScript programs which manipulates them in DOM tree.

However, when someone wants to introduce Ruby in entirely new
XML-formatted document, the one does not need to care about the
compatibility and rather simple, XML-friendly scheme may be adopted.
As of it, currently, I think current separation of semantic
interpretation (HTML5) and physical interpretation (CSS Ruby) is O.K.
for me.

Regards,


On Fri, Apr 4, 2014 at 1:45 AM, Koji Ishii <kojiishi@gluesoft.co.jp<mailto:kojiishi@gluesoft.co.jp>> wrote:
+public-i18n-cjk

After giving some more thoughts on this topic, although I understand the motivation to keep the ruby segmentation, categorization, and annotation pairing[1] in HTML spec, I think it’s better to move that part entirely to the CSS Ruby Level 1 for the following reasons:

1. Rather than having a logic split into HTML and CSS, and make sure the two are consistent, it’s easier and safer to maintain in one spec.
2. HTML having segmentation, categorization, and paring logic means that HTML could behave differently from other documents such as XML. I’d be more comfortable if HTML and XML renders the same way.
3. The logic affects how UA builds render tree. That part better be done in CSS spec.

What do you think?

[1] http://www.w3.org/TR/html5/text-level-semantics.html#annotation-pairing


/koji

On Mar 18, 2014, at 5:57 PM, kawabata taichi <kawabata.taichi@gmail.com<mailto:kawabata.taichi@gmail.com>> wrote:


Dear CSS people interested in Ruby,

I would like to propose the revision of CSS Ruby anonymous box
creation procedure, specified in current draft of CSS Ruby Level1
Section 2.2 [1].


Background:

HTML5 CR Ruby spec defines how Ruby markups in HTML5 will be converted
to DOM tree [2], and how each DOM components are semantically
interpreted as ruby bases and ruby annotations [3]. This specification
is mainly for HTML and JavaScript authors, to help understand how Ruby
markups are semantically understood.

The other side of Ruby spec is CSS Ruby [1], which specifies how Ruby
display properties are interpreted into Rendering Tree and physically
displayed on a screen (Anonymous Ruby Box Generation). This spec is
not only important for HTML/JavaScript authors, but also for Web
Browser developers.

As of it, HTML5's semantic interpretation or Ruby (DOM Tree) and CSS
Ruby's physical interpretation (Rendering Tree) should be consistent.

However, current physical interpretation defined in CSS Ruby (Section
2.2) has several inconsistencies with semantic interpretations defined
in HTML5 CR Ruby.

- Step 2 of current specification does not wrap the text element
  parented by <ruby> as <ruby bases>. This contradicts with Step 2
  of [4] (commit automatic base), which interprets text element
  (not inter-element whitespace) parented by <ruby> as <ruby bases>.

- Step 2 of current specification do not wrap two ruby bases
  separated by inter-element whitespace into single ruby base
  container. This is also not consistent with Step 2 of [4], which
  ignores inter-element whitespace on creating ruby base container.

  Similarly, Step 20.1 of [3] ignores inter-element whitespace among
  annotations, which may be inconsistent with Step 2 of current Ruby
  spec.

- Step 4 of current specification do not wrap ruby base containers
  and/or ruby annotation containers separated by inter-element
  whitespaces into single anonymous ruby container. As a result, it
  may be inconsitent with Step 2 of [4].

- Also, to enhance the clarity, we should say that any inline-level
  text to be treated as inline-level element, as defined in [5].


Proposal:

To solve this situation, I would like to propose to revise the step 2 to 4 of
Section 2.2 of CSS Ruby Level 1 as follows, to best fit with HTML5 Ruby.

2. Any text that is directly contained inside <ruby>,
   <ruby-base-container>, <ruby-annotation-container> must be treated
   as an anonymous inline element.

3. Any consecutive sequence of inline-level boxes that are not
   inter-element white-space, parented by <ruby> or <ruby base
   containers> is wrapped in an anonymous <ruby bases>.

4. Any consecutive sequence of inline-level boxes parented by <ruby
   annotation container> is wrapped in an anonymous <ruby annotations>.

5. Any consecutive sequence of <ruby bases> and <inter-element
   whitespaces> adjacent to <ruby bases> not parented by a <ruby base
   container> is wrapped in an anonymous <ruby base container>.

   Similarly, any consecutive sequence of <ruby annotations> and
   <inter-element whitespaces> adjacent to <ruby annotations> not
   parented by a <ruby annotation container> is wrapped in an
   anonymous <ruby annotation container>.

6. A sequence of <ruby base containers>,  <ruby annotation
   containers> and/or <inter-element whitespaces> surrounded by <ruby
   base containers> or <ruby annotation containers> not parented by a
   <ruby container> is wrapped in an anonymous <ruby container>.

Any comment is really appreciated.

With best regards,


[1] … http://www.w3.org/TR/css3-ruby/#box-fixup

[2] … http://www.w3.org/html/wg/drafts/html/CR

        (Section 4.5.21 to 4.5.25 and 8.2.5.3 to 8.2.5.4.7)
[3] … http://www.w3.org/html/wg/drafts/html/CR/text-level-semantics.html#segmentation-and-categorisation-of-ruby

[4] … http://www.w3.org/html/wg/drafts/html/CR/text-level-semantics.html#commit-an-automatic-base

[5] … http://www.w3.org/TR/CSS21/visuren.html#anonymous


--
---------------------------------------------------------------------
  KAWABATA, Taichi   E-mail: kawabata.taichi@gmail.com<mailto:kawabata.taichi@gmail.com>





--
---------------------------------------------------------------------
　川幡 太一 (KAWABATA, Taichi)　　　E-mail: kawabata.taichi@gmail.com<mailto:kawabata.taichi@gmail.com>