- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Sat, 3 May 2014 15:45:24 +0000
- To: kawabata taichi <kawabata.taichi@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
--Apple-Mail=_B7C77A56-C269-4D91-8ACB-23874E324560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > 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. That=92s the discussion point. Since there are zero use cases of the = annotation pairing other than layout as of today, and the algorithm is = complex enough to require several revisions until stabilized (maybe you = have different view on this point,) developing this algorithm across two = WG has more risk than the hypothetical violation you mentioned. I think = the violation is reasonable given the risk, and it=92s somewhat similar = to what we=92ve already done with the white-space property. > 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. I don=92t understand this logic. Let=92s discuss on our next offline = conversation. > As of it, my opinion on my proposal is that, >=20 > 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. I think the order should be opposite; i.e., we should resolve the latter = first. Since the latter could affect the former, we should not work much = on the former until that was agreed and resolved. If there were any reasons the former should be done first, can you = please elaborate? > 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. That sounds like a good plan. Are you facilitating this? Anyone else who wants to joint he offline conversation, please let us = know. /koji --Apple-Mail=_B7C77A56-C269-4D91-8ACB-23874E324560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;"><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>I= agree that current algorithm of ruby segmentation and = categorisation</div><div>is complex and could be obstacle of = facilitating implementation by</div><div>brower vendors. However, I also = doubt that treating unpairable ruby as</div> <div>"irregular" and "undefined" and leave its interpretation to CSS = Ruby,</div><div>as it could be a violation of leaving semantic = interpretation to CSS,</div><div>that should only focus on a = presentational = interpretation.</div></div></blockquote><div><br></div><div>That=92s the = discussion point. Since there are zero use cases of the annotation = pairing other than layout as of today, and the algorithm is complex = enough to require several revisions until stabilized (maybe you have = different view on this point,) developing this algorithm across two WG = has more risk than the hypothetical violation you mentioned. I think the = violation is reasonable given the risk, and it=92s somewhat similar to = what we=92ve already done with the white-space = property.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"> <div>On the other hand, if my proposal posted in</div><div>[<a = href=3D"http://lists.w3.org/Archives/Public/www-style/2014Mar/0392.html">h= ttp://lists.w3.org/Archives/Public/www-style/2014Mar/0392.html</a>] = is</div> <div>incorporated into CSS Ruby, then I believe that it safely = complements</div><div>current HTML5 CR ruby segmentation and = categorisation algorithm, so</div><div>that current denotational and = algorithmic specification to can be</div> <div>unnecessary.</div></div></blockquote><div><br></div><div>I don=92t = understand this logic. Let=92s discuss on our next offline = conversation.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>As = of it, my opinion on my proposal is that,</div><div><br></div><div>as = soon as [www-style/2014Mar/0392.html] is incorporated into = CSS</div><div>Ruby, make HTML5 Ruby spec to only explain the semantic = interpretation of</div> <div>ruby in basic mannar (and optional, as non-supported = browser</div><div>still be able to dsiplay it properly with <rp> = tags), and refer CSS</div><div>Ruby for strict interpretation. In this = way, all ruby-related</div> <div>non-parser tests will become a part of CSS tests, but not HTML = tests.</div><div>This will make implementation of brower much = easier.</div></div></blockquote><div><br></div><div>I think the order = should be opposite; i.e., we should resolve the latter first. Since the = latter could affect the former, we should not work much on the former = until that was agreed and resolved.</div><div><br></div><div>If there = were any reasons the former should be done first, can you please = elaborate?</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>Robin,= Fantasai, Ihii-san, and Ishida-san, if possible, can we discuss</div> <div>on this issue in telephone meeting? My main concern is to = make</div><div>implementation of HTML5 ruby much easier to browser = vendors while</div><div>pertaining its = abilities.</div></div></blockquote><br></div><div>That sounds like a = good plan. Are you facilitating this?</div><div><br></div><div>Anyone = else who wants to joint he offline conversation, please let us = know.</div><div><br></div><div>/koji</div><div><br></div><br></body></html= >= --Apple-Mail=_B7C77A56-C269-4D91-8ACB-23874E324560--
Received on Saturday, 3 May 2014 15:46:01 UTC