- From: Koji Ishii <kojiishi@gmail.com>
- Date: Wed, 12 Nov 2014 23:34:43 +0900
- To: Xidorn Quan <quanxunzhen@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, kawabata taichi <kawabata.taichi@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAN9ydbXic_OowTpYQ39hViLSN7VnhD+145xb=Sc0RnUc9Npghg@mail.gmail.com>
Sorry I guess I was a bit late to respond, but there are use cases for spanning; it's not for an error handling. How often/rare is hard to explain, less often than normal ruby, but probably more than one might imagine. One thing that may help this discussion is that, spanning and line breaking within a ruby element (mostly for light novels[1]) are for different use cases, and they're almost never used together, so it's ok to disable line breaking when spanning occurs. Does that help complexity? If not, well, it's apparently better to have Ruby without spanning than not to have, or than to wait for months to years, but it'd be the best if we could find a way to help complexities without losing spanning. Another note regarding JLREQ is that, it was said repeatedly so most people here might know but, in the policy h of 1.3[2], JLREQ states that its coverage is limited to "common books". The term "common books" is not clearly defined, but you could read it as "novels". In such "common books", not only spanning but also double sided ruby is really really rare, but in other markets such as educational materials, double sided ruby is a required feature. Another example is use of double quotes; JLREQ states one way and the other way is completely wrong and rare, while that the other way is the rule for other markets such as closed captions or often used in magazines. What I wanted to say here is that, when you want to determine if a feature is common or rare, you should think about which markets you want to target to, and depends on that, sometimes JLREQ may not help to determine that. The primary purpose of JLREQ is to define rules used in Japanese "common books", not to provide data of how common a feature is used in the whole Japanese documents. [1] http://en.wikipedia.org/wiki/Light_novel [2] http://www.w3.org/TR/jlreq/#basic_principles_for_development_of_this_document /koji On Wed, Nov 12, 2014 at 12:19 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote: > On Wed, Nov 12, 2014 at 1:16 PM, fantasai <fantasai.lists@inkedblade.net> > wrote: > >> On 11/11/2014 09:01 PM, Xidorn Quan wrote: >> >>> >>> I don't agree with that model as well, but I don't think HTML5 model is >>> perfect either. Back to spanning, IMHO, it introduces much complexity >>> with nearly no benefits, hence I suggest that we should get rid of it. >>> >> >> The benefit is consistency of the markup model for double-sided ruby, >> regardless of whether you need spanning or not. See explanation at: >> http://fantasai.inkedblade.net/weblog/2011/ruby/ >> >> Without it, you'd need to switch between nested ruby or <rtc> markup >> depending on whether that particular word in the second level required >> spanning or broke at the same boundary as the first level. > > > Do we really have use cases that authors may sometimes need span but > sometimes not in the same level? > > AFAICS, we have two main use cases for double-sided ruby: one is the > Japanese two pronouncation case, the other is making annotation in other > language. For the first case, kun'yomi always spans the kanjis, while > on'yomi are always separate. For the second case, I don't think most > languages can be aligned with each other in sub-word level. > > Hence, it won't cause any inconsistency to require nested markup for > spanning. Whether a level needs spanning or not doesn't change among words. > > - Xidorn >
Received on Friday, 14 November 2014 08:40:06 UTC