[css3-text] ED reviewed

Below is my review of CSS Text Level 3, Editor's Draft 23 May 2011.
Some of the comments have been posted before [1][2][3][4], but have
not been added as issues in the draft. This is probably due to the
catch-all issues in the beginning of the document:

  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.

But I suggest marking them as issues in the editor's draft as well.


3.1 Transforming Text: the ‘text-transform’ property

I suggest removing 'fullwidth' and 'fullsize-kana' from this property. 

Because:

 - the scope of these values are very different from 'uppercase' and
   'lowercase' which applies to all bicameral scripts.

 - 'font-variant-east-asian: full-width' can be used instead:

      http://dev.w3.org/csswg/css3-fonts/#font-variant-east-asian-prop

 - there are more proposals for new values on this property and I
   don't feel like sorting them into accepted and not-accepted
   bins:

      http://lists.w3.org/Archives/Public/www-style/2011Mar/0414.html

 - the references, e.g. to the "<wide>" tag is unclear. When I search
   for "wide" in that document, I don't easily find a mapping. I'm
   sure the mapping is defined in there somewhere, but the spec, as
   it currently stands, demands that implementors untangle too many
   references.

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

 - I'm told that the use of half-width characters is limited. For
   example, Japanese Macs require you to specifically enable
   half-width kana input, as it's turned off by default. This
   indicates that the use case for converting half-width to full-width
   is not strong.

If we decide we need a glyph-mapping functionality, I suggest adding
a generic mechanism instead. E.g.:

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

This would democratize the process. 


4.1 White Space Collapsing: the ‘bikeshedding’ property

Like others, I suggest renaming the 'bikeshedding' property into
something more sensible, like 'white-space-collapse'


5.1 Line Breaking Strictness: the ‘line-break’ property

The 'line-break' property lists three values without really defining
them. Some rules for Japanese and Chinese are suggested, but the spec
doesn't say how to interpret these values for other languages. The
specification must be more precise if we want interoperable results.


5.2 Word Breaking Rules: the ‘word-break’ property

This section could benefit from examples. 

Regarding this statement:

  When shaping scripts such as Arabic are allowed to break within
  words due to ‘break-all’, the characters must still be shaped as if
  the word were not broken.

I suggest defining "shaping scripts" in Appendix E.

In Latin-based languages, the words are -- typically, I believe --
considererd to be two separate words when broken. For example, when
splitting the word

  trafikkonstabel 

into 

  trafikk-
  konstabel

the spelling changes to make each word compliant. This seems different
from Arabic. The Duch IJ ligature behaves the same way, I believe.
Therefore, I'm unsure if the spec should say anything about this
unless we have -- and describe -- the full picture.


7.1 Text Wrap Settings: the ‘text-wrap’ property

I'd like to propose one more value on 'text-wrap': 

  text-wrap: balance

The 'balance' value indicates that content should be balanced across
all (or, at least across the two last) lines of an element. The idea
is to prevent headlines like this:

    Cease-Fire in Capital Breaks 
    Down

and instead have

    Cease-Fire in Capital
    Breaks Down

or perhaps:

    Cease-Fire in 
    Capital Breaks Down

The purpose is to avoid orphan words at the last line. The concept is
similar to column balancing:

    column-fill: balance



8.2 Last Line Alignment: the ‘text-align-last’ property

Instead of the proposed new 'text-align-last', I suggest using a pseudo-element:

  p:last-line {
    text-align: center;
  }

This would provide greater expressive power; one can set fonts, color etc.



8.3 Justification Method: the ‘text-justify’ property

I think 'text-justify', as proposed, is outside the scope of CSS. The
property comes close to describing a set of justification algorithms,
switchable with this property. One problem with this approach is that
existing algorithms, which may have been optimized over years (TeX
comes to mind) can no longer be used to format CSS. Another problem is
that not all "knobs" are exposed. 'word-spacing' and 'letter-spacing'
are there, but 'glyph-shaping' is not.

  http://lists.w3.org/Archives/Public/www-style/2011Apr/0200.html

The research that has been done for this property is still valuable
and I suggest publishing the table in a non-normative appendix. But I
can't really see designers setting values on this property and getting
interoperable results in return.


9.1, 9.2

These properties adds min/max settings on existing knobs. I'm unsure
of the value this provides. In order to justify text, implementations
may have to make the word-spacing wider than the maxium. So, why set a
maximum?

I'd much rather have the 'glyph-shaping' property (as per above). (It
may need min/max values. Hmm.)


9.3 Character Class Spacing: the ‘text-spacing’ property

It seems that the purpose of 'text-spacing' is to magically add space
around (say) English text inside Chinese? Without there being space
characters or markup in the text? That's wild. And it seems to go
against the priciple of markup languages: mark it up if you want
somthing to happen! E.g., we should ecourage:

    span:lang(en) { padding: 0 0.5em }

    候选<span lang="en">foo</span>候选

and not add magic to spacing to this:

    候选foo候选

There's a combinatorial explosion lurking in there, too: how do I
format a run of <script1> characters inside <script2>? 

And content-based selectors are not far off: How do I get a glowing
halo around my name in documents I read?

I therefore suggest dropping this property.


10.1 First Line Indentation: the ‘text-indent’ property

I can see the value of the proposed 'each-line' keyword. But the name
seems wrong; indentation doesn't happen on each line.

How about renaming it to "after-break"?:

  text-indent: 1em after-break

I'm unsure if the 'hanging' keyword is needed on 'text-indent', given
that negative values can be specified.



10.2 Hanging Punctuation: the ‘hanging-punctuation’ property

This property claims to describe hanging punctuation. So it does, but
it goes well beyond that: the 'force-end' value actually stretches the
content, possibly violating 'letter-spacing' and related properties?
The interaction between them seems complex.

Things could be simplified if we can limit the effect to the last line
of an element. Would that cover most use cases? This text seems to
indicate just that:

   At most one punctuation character may hang outside each edge of the
   line.

We could then specify:

  p:last-line {
    text-align: justify;
    hanging-punctuation: last;
  }

Or, alternatively:

  p {
    text-align-line: justify;
    hanging-punctuation: last;
  }

I.e., 'hanging-punctuation' would have these values:

   none | [ first || last ]

and the "forcing" would be done through the 'text-align' property.


11.2 Emphasis Marks

I suggest that Emphasis marks are moved to a future level of CSS Ruby.



11.4 Text Outlines: the ‘text-outline’ property

I suggest 'text-outline' is dropped; 'text-shadow' is rich enough.


[1] http://lists.w3.org/Archives/Public/www-style/2011Apr/0146.html
[2] http://lists.w3.org/Archives/Public/www-style/2011Apr/0168.html
[3] http://lists.w3.org/Archives/Public/www-style/2011Apr/0545.html
[4] http://lists.w3.org/Archives/Public/www-style/2011Apr/0187.html


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

Received on Tuesday, 31 May 2011 19:37:01 UTC