- From: kawabata taichi <kawabata.taichi@gmail.com>
- Date: Fri, 4 Apr 2014 10:03:54 +0900
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- Cc: "www-style@w3.org" <www-style@w3.org>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
- Message-ID: <CA+PRW99r7BX8ttEh8AhJezS4_RYzZiBuJvg1_sR__gawm-ycWA@mail.gmail.com>
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
Received on Friday, 4 April 2014 01:04:23 UTC