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

Re: [css3-text] script-specific functionality

From: Håkon Wium Lie <howcome@opera.com>
Date: Thu, 7 Apr 2011 19:59:32 +0200
Message-ID: <19869.64388.258620.51232@gargle.gargle.HOWL>
To: www-style@w3.org
I wrote:

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

Here's more.

Overall comment: The draft goes into a great level of detail in some
specific areas for some specific scripts, while more general
functionality -- which could be useful for more scripts -- is not

For example, the draft adds functionality for kerning fullwidth
punctuation characters (the 'text-trim' property), while the more
general issue of kerning is not addressed. I'd rather start by
addressing the more general issue of kerning, like css3-fonts does.


Therefore, I suggest removing 'text-trim' from this specification and
consider addressing the functionality nearby to the 'font-kerning'


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 in for other languages other
than leaving it to the UA. The specification must be more precise if we
want interoperable results.


The use case for the 'text-align: match-parent' should be made in the


This line needs some explanation:

  ‘auto’ is equivalent to the value of the ‘text-align’ property
  except when ‘text-align’ is set to ‘justify’, in which case it is
  ‘justify’ when ‘text-justify’ is ‘distribute’ and ‘start’ otherwise.

What's the use case and and is it worth introducing the


The specification adds this functionality to better control

  text-justify: auto none inter-word inter-ideograph inter-cluster distribute kashida
  word-spacing: 2 new values describing minimum maximum spacing
  letter-spacing: 2 new values describing minimum maximum spacing

However, microtypography is not mentioned. 


In particular, changing the widths of glyphs is how many current
publications improve justification. Perpaps CSS can play a role by
setting optimum/maximum/minimum constraints on microtypography? It may
be that this is compatible with extending 'word-spacing' and
'letter-spacing', but I'd rather not extend these properties until we
see the whole picture.

Do we know what knobs (say) InDesign offers in this field? Do they
offer values comparable to 'inter-ideograph' and 'inter-cluster'. Or
perhaps they offer something like 'inter-letter'? I'm not convinced it
makes sense to set these types of values in a style sheet. For
example, what does it mean to say:

  <p style="text-justify: inter-cluster">候选</p>

It seems more natural to describe "justification opportunities"
between various types of characters.

The 'kashida' value seems specific to Arabic. However, elongation is
also used in other languages, though, and I suspec we will see more of
it with OpenType features. If we want this value, I suggest we use an
English name for it, e.g. "elongation" or "expand".

In conclusion, I suggest we try to get the overview of the
microtypography situation before adding/extending text-justify,
word-spacing, and letter-spacing.


It seems that the purpose of 'text-autospace' is to magically add
space around (say) English text inside Chinese? Without there being
space characters or markup in the text? I suggest we rather encourage
the use of markup as this also allows the specification of the
language. E.g.:

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

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

Alternatively, OpenType features should be able to handle this, no?


What's a typical use case for 'each-line'?


'hanging' may be useful, but the name doens't sound right to me -- the
result isn't always a hanginge first line. Isn't 'invert' better?


About the 'hanging-puctuation' property:

  - it seems that an ending quote cannot hang?

  - does the 'force-end' value really force stops/commas to hang? So,
    unless the comma appears at the content edge, it is moved there?


Emphasis marks seem to have much in common with rubies. I suggest it
is moved to a ruby-centric spec.


I suggest we remove the 'text-outline' property -- 'text-shadow'
should cover it.


I suggest Elika adds her (impressive list of) affiliations to the
draft somewhere.


              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Thursday, 7 April 2011 18:00:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:58 UTC