- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 24 Sep 2013 23:46:19 -0700 (PDT)
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- Cc: W3C Style <www-style@w3.org>
Koji Ishii wrote: >> the fallback behavior is unnecessary for CSS > > So you want to tailor UTR#50 for CSS, correct? As I've said several times already, I see no problem with what's defined in Unicode. CSS doesn't need to customize or tailor it. The Vertical Orientation property was never intended as a single, absolute definition of character orientation, merely as a good default. Which is why the default value of 'text-orientation' should base orientation upon that property. But authors will still need to use explicit markup to set the orientation in situations where the default doesn't match the needs of their content. We should not view the Vertical Orientation property as a definition of OpenType feature fallback. Unicode defines general character usage and UTR50 makes useful distinctions between sets of codepoints in the case of the Tu and Tr values. How that information is used for the web platform is the domain of CSS, not Unicode. >> Could you explain more clearly under what conditions this fallback is >> needed? > > As a CSS WG member, the whole purpose is to follow what Unicode defines. Koji, could you please explain at a practical level why it's necessary to define fallback behavior for Tr codepoints when fonts already provide vertical alternates for almost all the Tr codepoints already? You said a developer was interested in implementing this behavior. I think it's important to understand *why* they thought that was important, since I'm guessing they were motivated by a practical set of conditions. What environment, what set of content and what fonts required such fallback? Understanding this is much more important than quibbling over what the boundaries of Unicode and CSS specs. Ultimately the web platform is based on a whole slew of standards that need to work together to render text in an efficient and consistent manner. Given that fonts already provide the alternates required for displaying Tu and Tr codepoints, you're arguing for inconsistency by defining optional fallback behavior in a situation where it's not really necessary. > The purpose of Tr, as I understand, is for implementations to work > well not only with today's fonts but also with fonts decades later. > Other members may say differently though since there were several > discussions over time, but after all those discussions, UTC resolved > to keep Tr in the revision #11. Adding optional complex fallback is not forward-looking, it's adding a burden on implementations and introducing inconsistency across user agents, neither of which sounds like a good thing. Cheers, John Daggett
Received on Wednesday, 25 September 2013 06:46:50 UTC