- From: David Hyatt <hyatt@apple.com>
- Date: Thu, 04 Nov 2010 13:26:17 -0500
- To: www-style list <www-style@w3.org>
The current writing-modes draft is completely silent on the subject of baseline alignment of vertical text. I think there is some stuff that needs clarifying. What do we do with fonts that don't have vertical metrics and therefore only have a baseline defined that is suitable for horizontal text? If you use such a font with English text on a line with Japanese text, the English text really should be treated as though its baseline runs through the middle of the text (e.g., like vertical-align:middle). The question I have is, what should the rule be for this behavior? I can think of three possibilities: (1) Just assume that all inline non-replaced elements in vertical writing modes have "vertical-align:middle" as the default instead of "vertical-align:baseline". This is Internet Explorer's behavior. On the one hand, it's easy to implement. On the other hand, it feels odd to have a line with nothing on it but English text and have it defaulting to vertical-align:middle instead of vertical-align:baseline. I would expect rotated English text to continue to baseline align rather than middle align. (2) Make the centering a language-based choice. The heuristic could be based off the specified language. If it's CJK, then you could apply the rule of (1) above. (3) Make the centering a font-based choice. This is my preferred option. If the line contains a used font that has vertical metrics, then all fonts that don't have vertical metrics should be treated as though they have vertical-align:middle set (or alternatively just synthesize a baseline that is halfway through the text while still keeping the vertical-align value the same). Note that there is a similar issue with underline text decorations, and the options are also similar, i.e., always draw underneath the glyphs (1), make the underlining language-based (2), or make the underlining font-based (3). Again my preference is for (3). Dave (hyatt@apple.com)
Received on Thursday, 4 November 2010 18:26:55 UTC