W3C home > Mailing lists > Public > www-style@w3.org > February 2013

[text-decor-3] Emphasis marks and ruby

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 01 Feb 2013 17:19:21 -0800
Message-ID: <510C6999.9050000@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>, MURAKAMI Shinyu <murakami@antenna.co.jp>, CJK discussion <public-i18n-cjk@w3.org>, 'WWW International' <www-international@w3.org>

   # If emphasis marks are drawn for characters for which ruby is drawn
   # in the same position as the emphasis mark, the ruby should be
   # stacked between the emphasis marks and the base text. In this case,
   # the position of the emphasis marks for a given element should be
   # determined as if all characters have ruby boxes of the same height
   # as the highest ruby box in the element. If the UA is not capable of
   # drawing ruby and emphasis marks on the same side, the UA may hide
   # ruby and draw only emphasis marks.

See illustration at

It's clear that when ruby and emphasis marks are drawn together, the
ruby is closer to the base text. The interesting thing is what happens
when a run of text is emphasized, but only some characters have ruby.
The spec currently says that you place the emphasis dots at a consistent
position, so if some of it has ruby then you position it accommodating
the ruby. There are two problems with this:

   * text-emphasis is inherited, so technically you don't know which
     element is the one setting the emphasis. (Practically speaking,
     this is not a problem: you just look up the ancestor chain to
     find the highest element with text emphasis set. Emphasis marks
     generally don't--and in CSS actually cannot--stack.)

   * Koji has found examples where the dots are instead placed as
     close as possible to the base text, so immediately above base
     characters without ruby, above the ruby for characters that have it.

So, it's possible to implement the behavior in the spec right now
and have that be reasonable, but it's possible that publications
might want the as-close-as-possible behavior, and that's probably
also easier to implement.

What should we have the spec say? What it currently says, with
clarification of where to look for the "emphasizing element"?
Or spec as-close-as-possible positioning? Or leave it undefined?

Received on Saturday, 2 February 2013 01:19:59 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:24 UTC