W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: Feedback on hyphenation properties

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 05 Aug 2010 12:19:45 -0700
Message-ID: <4C5B0ED1.8060209@inkedblade.net>
To: Simon Fraser <smfr@me.com>
CC: Håkon Wium Lie <howcome@opera.com>, "www-style@w3.org list" <www-style@w3.org>
On 08/05/2010 11:59 AM, Simon Fraser wrote:
> Another reason the current names are confusing is because it's easy
> to interpret them in reverse. An author seeing "hyphenate-before" may
> assume it means that it's OK to split the word N characters *before the
> end* (and, likewise for hyphenate-after, N characters *after the beginning*).

We changed them from the XSL versions because few people could make
sense of the XSL names.

>> The language issue can be avoided by setting different resources for
>> different languages, no?
>>   :lang(fr) { hyphenate-resource: url(foo), url(bar) }
>>   :lang(en) { hyphenate-resource: url(foobar), url(barfoo) }
> Sure, if this is understood by the author. But, as we know, authors don't
> really understand these things, and may just string a whole bunch of
> dictionaries from different languages together.

Put some examples in the spec. There's a decent chance tutorial
authors will copy from those examples.

> Its also unlikely that we'll support this format in WebKit on Mac, since
> we rely on an underlying framework for hyphenation, and it has its
> own dictionaries supplied with the OS.

It might make sense for hyphenate-resource to be optional for implementations.

>> This would remove an incentive to start using the 'lang' attribute. If
>> we want to encode such information in CSS (I'm not sure we do)
> One reason we see a need for this is that we have to hyphenate content
> that lacks "lang" attributes, but for which there is out-of-band data about
> the language (e.g. EPUB). Another reason is that we may be able to deduce
> something about the language from analysis of the content, and thus need
> to propagate the results of that analysis to the hyphenation system somehow.

If you have out-of-band data about the language, then certainly you should
use that. (And if you have that information, :lang() should match accordingly
as well. :lang() is not limited to matching the lang='' attribute.)

>> it may be better to offer a property that can also be used outside of
>> hyphenation, no? E.g.:
>>   body { locale: 'en' }
> This is a reasonable suggestion. Knowledge about the language is also
> used for collation (e.g. for "find" algorithms), and for font substitution, so it seems
> reasonable to have a property independent of hyphenation for those things as well.

But it doesn't make sense to have that property in CSS. CSS is about styling
the content, not declaring metadata about it.

Received on Thursday, 5 August 2010 19:20:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:49 UTC