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: Sun, 17 Apr 2011 00:17:06 +0200
Message-ID: <19882.5474.707541.480676@gargle.gargle.HOWL>
To: Koji Ishii <kojiishi@gluesoft.co.jp>
Cc: www-style@w3.org
Also sprach Koji Ishii:

 > > Therefore, I suggest removing 'text-trim' from this
 > > specification and consider addressing the functionality
 > > nearby to the 'font-kerning' property.
 > Precisely speaking, the 'text-trim' property is not "kerning".
 > Kerning information is created by font designer and stored in font
 > files, so it makes sense to have it in font specification. This
 > feature is not stored in font file, but is algorithmic spacing
 > control between two character classes, which may add or remove
 > inter-character spaces, so I think here right after
 > 'letter-spacing' is the right place.

Kerning information is often stored in the font, but the term
"kerning" is more general. For example, some software provides
auto-kerning based on the shapes of the glyphs. This seems similar to
the algorithmic spacing control that you refer to.

 > > 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 list includes East Asian code points only because the feature
 > is needed only for them.

I'd like to avoid introducing features that are tied to specific
scripts. It seems that the feature in question is close enough to
kerning that we can make it more generally useful. And if it's not in
common use today, some designer may find creative use for it tomorrow.

Also, UAs will encounter combinations that have not been in common use
in the past, and the spec should define what the behavior is.

 > > 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 is it worth introducing the interdependency?
 > It's a nature of 'justify' where alignment for the last line and
 > for the rest are different. I you think about regular justified
 > paragraphs, all lines except the last one should be justified. So,
 > when 'text-align' is 'justify', 'text-align-last' must be 'start'.

Would it make more sense to introduce a :last-line pseudo-element,
similar to first-line? Then we can keep properties simpler, it seems.

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

 > Your example doesn't make sense since you're using the value for
 > clustered scripts such as Thai against Chinese, which is not a
 > clustered script.

Indeed, it doesn't make sense. But UAs will be facing code like this
and they must deal with it somehow.

 > > It seems more natural to describe "justification opportunities"
 > > between various types of characters.
 > Hmm...I was thinking this feature defines "justification
 > opportunities" between various types of characters. What did I
 > miss?

You're right that the value indicates justification opportunities, but
it closes more opportunities than it opens. For example, the defintion
of 'inter-cluster':

  Justification primarily changes spacing at word separators and at
  grapheme cluster boundaries in clustered scripts. This value is
  typically used for Southeast Asian scripts such as Thai.

So, when this value is encounterd, most of the justification (80%?
90%?) happens "at word separators and at grapheme cluster boundaries
in clustered scripts". It seems that it discourages justification by
way of microtypography -- is this intentional. 

Also, if some (say) Japanese text is interleaved in (say) Thai, should
UAs not use what they know about justification in Japanese? If yes, I
don't understand why not. 

I also find the description ambigous. Does it mean to say this?:

  Justification primarily changes spacing at word separators in all
  scripts and at grapheme cluster boundaries in clustered scripts.

 > > 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> 候选
 > Close, but no. It's not about English and Chinese, it's about Latin
 > characters within East Asian languages.

Sure. (The "say" indicated that English and Chinese were only examples.)

 > It's not necessarily English, just proper nouns or room numbers. I
 > don't expect East Asian authors to mark every Latin characters as
 > lang="en".

They don't have to mark the language (which would not make much sense
for numbers). But, if they expect special formatting to apply, is it
too much to ask that (e.g.) a <span> element is added? 

The 'text-autospace' property is like a hard-coded content selector:


If we are to have these, I'd rather have a generic mechanism.

 > >  - does the 'force-end' value really force stops/commas to hang? So,
 > >   unless the comma appears at the content edge, it is moved there?
 > Yes to the first sentence. I'm not sure if I understand 2nd
 > sentence correctly; if stops/comma appears at the line end, it
 > hangs, even when the line can be formatted/justified without doing
 > so. This is one of the style variations used in East Asia. I
 > haven't seen this style used in Latin script.

Could you show a picture of this?


              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Saturday, 16 April 2011 22:17:42 UTC

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