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

--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 &lt;rp&gt; =
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:00 UTC