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