W3C home > Mailing lists > Public > www-style@w3.org > April 2011

[css3-text] script-specific functionality

From: Håkon Wium Lie <howcome@opera.com>
Date: Wed, 6 Apr 2011 22:30:36 +0200
Message-ID: <19868.52588.91982.746052@gargle.gargle.HOWL>
To: www-style@w3.org
In today's telcon I took an action point to suggest wording for an
issue to be added to css3-text:


I suggest we add this note:

  This draft describes features that are specific to certain scripts.
  There is an ongoing discussion about where these features belong: in
  existing CSS properties, in new CSS properties, or perhaps in other

To explain why this is necessary, and to continue the ongoing
discussion, I will make some remarks about the two new keyword values
on 'text-transform': "fullwidth" and "fullsize-kana". They expose
several issues:

  - 'text-transform: fullsize-kana' only applies to one script (Kana),
    and (seemingly only) to a certain context (ruby). The scope of
    this value is vastly different from 'uppercase' and 'lowercase'.

  - it's unclear what UAs that do not support the script in question
    should do when encountering these values. While it may be
    self-evident that UAs ignore 'fullsize-kana' when they don't
    support/display kana, it's not so clear what should happen when
    "text-transform: fullwidth" is set. Does 'fullwidth' refer to the
    U+FF00-FFEF block? Should a UA look for fullwidth characters in
    the font? Or try to synthesize? How wide is a 'full width' when


  - other languages may have other notions of text-transform. For
    example, Wikipedia notes that:

      Also similar to case is recent usage in Georgian, where some
      authors use isolated letters from the Asomtavruli alphabet
      within a text otherwise written in Mkhedruli in a fashion that
      is reminiscent of modern usage of letter case in the Latin,
      Greek, and Cyrillic alphabets.


    Should we add the "mkhedruli-to-asomtavruli" value? Perhaps. Or
    not. Do we discriminate against authors in Georgia if we don't?
    Perhaps. Or not. We used to have these discussions for
    'list-style-type': what level of use warrants a new keyword value?
    Then we discovered that we could add a mechanisms so that authors
    could define their own mappings:


  - there are plenty of use cases for typographic transforms. For
    example, you would want to automatically convert '«' into '"'. Or
    "'" into "’". This is another argument for finding a generic
    mechanism instead of a keyword-based approach.

  - the 'fullwidth' value doesn't feel like a text transformation to
    me. It's more like a 'font-family: monospace' no? Or something

  - adding new values to existing properties decrease
    interoperability; we can't avoid it, but other options should be

Therefore I suggest we:

  - add the proposed note/issue to the draft

  - consider adding a generic mechanism for glyph transforms. The tr///
    operator in Perl could give us inspiration without taking us all
    the way to regular expressions. For example, we could have:

       text-transform-range: "'" "’", "a-z" "\FF41-\FF5A"'

  - consider if the glyph substitutions in question can be described
    in other languages. For example, I believe that Opentype Features
    can be used to describe the mappings in question, no?

  - consider moving "fullsize-kana" to Ruby-centric specification. 

  - consider the relationship between "fullwidth" an the generic font

Other properties also have issues, I'll try to go through more.

I should also add that I think the word that has been done to prepare
this draft is worthwhile and that I strongly belive in extending the
reach of CSS and the web.


              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Wednesday, 6 April 2011 20:31:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC