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

Dear Koji,

I agree that current algorithm of ruby segmentation and categorisation
is complex and could be obstacle of facilitating implementation by
brower vendors. However, I also doubt that treating unpairable ruby as
"irregular" and "undefined" and leave its interpretation to CSS Ruby,
as it could be a violation of leaving semantic interpretation to CSS,
that should only focus on a presentational interpretation.

On the other hand, if my proposal posted in
[http://lists.w3.org/Archives/Public/www-style/2014Mar/0392.html] is
incorporated into CSS Ruby, then I believe that it safely complements
current HTML5 CR ruby segmentation and categorisation algorithm, so
that current denotational and algorithmic specification to can be
unnecessary.

As of it, my opinion on my proposal is that,

as soon as [www-style/2014Mar/0392.html] is incorporated into CSS
Ruby, make HTML5 Ruby spec to only explain the semantic interpretation of
ruby in basic mannar (and optional, as non-supported browser
still be able to dsiplay it properly with <rp> tags), and refer CSS
Ruby for strict interpretation. In this way, all ruby-related
non-parser tests will become a part of CSS tests, but not HTML tests.
This will make implementation of brower much easier.

Robin, Fantasai, Ihii-san, and Ishida-san, if possible, can we discuss
on this issue in telephone meeting? My main concern is to make
implementation of HTML5 ruby much easier to browser vendors while
pertaining its abilities.

Regards,



On Sat, Apr 5, 2014 at 5:56 AM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:

>  To make my points clearer, my preference is:
>
>    1. HTML defines elements and their semantics
>    2. HTML defines tag omission rules
>    3. HTML may define annotation pairing for normal cases (the numbers of
>    bases and annotations match, no inter-element whitespaces, etc.,) but
>    leaves other irregular cases undefined, or delegate to CSS Ruby.
>    4. Add a section to CSS Ruby to handle those irregular cases.
>
>
>  This way, in addition to the benefits below, implementers can work on
> parser code for HTML5, then work on the rendering tree when CSS Ruby gets
> more stabilized. With the current setup, implementers have to change not
> only the parser code but also the rendering code once for HTML5, then
> re-open it when CSS Ruby gets stabilized. That’s a lot harder to implement.
>
>  If you have different opinions, want to hear what other CSS members
> would say, or want me to talk directly to I18N/HTML WG, please let me know.
>
>  /koji
>
>
>  On Apr 4, 2014, at 1:38 PM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
>
>  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>
> 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>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>
>> 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
>>
>>
>>
>
>
>  --
> ---------------------------------------------------------------------
> 川幡 太一 (KAWABATA, Taichi) E-mail: kawabata.taichi@gmail.com
>
>
>
>


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