[css3-text] script-specific functionality

In today's telcon I took an action point to suggest wording for an
issue to be added to css3-text:

  http://dev.w3.org/csswg/css3-text/
  http://www.w3.org/TR/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
  specifications.

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
    synthesizing?

      http://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms#In_Unicode

  - 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.

      http://en.wikipedia.org/wiki/Letter_case

    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:

      http://www.w3.org/TR/2007/WD-css3-gcpm-20070504/#named2
      http://dev.w3.org/csswg/css3-lists/#counter-style

  - 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
    else.

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

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
    families

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.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Wednesday, 6 April 2011 20:31:07 UTC