Hi John,
> This is a good improvement I think but maybe it would be better to just
> add a string value to the possible values of <urange>.
That's a good idea. The definitive source for Unicode block names would
be the Blocks.txt file, eg. for Unicode 5.1:
http://unicode.org/Public/UNIDATA/Blocks.txt
It also includes some rules about matching block names, stating that
casting, whitespace, hyphens, and underscores are all ignored, which
seems reasonable.
> You could probably come up with rules to reduce possible ambiguity but I
> think the complexity here would outweigh the potential convenience.
> With the named ranges you describe above I think you would cover most of
> the use cases for shorthand notation like this.
Good point, the single character syntax doesn't seem worth it.
> I understand the problem you're considering here, it occurs in many
> languages that share a common script, but I'm unclear if there's a
> possible solution here. One way to use the above notation might be to
> select different faces within a family for a given Unicode range based
> on which language matches the language of the page. The default value
> would be 'all' and if the current page language didn't match a language
> in the list, another face would be selected?
More or less yes, although the language might be for a subset of the
page, eg. a paragraph or a quote with a lang attribute:
<p>
In simplified Chinese the character for bone has a stroke on the left:
<q lang="zh-Hans">骨</q> while the traditional character has a stroke on
the right: <q lang="zh-Hant">骨</q>.
</p>
This use case can be handled with regular language selectors:
q:lang(zh-Hans) { font-family: AR PL KaitiM GB }
q:lang(zh-Hant) { font-family: AR PL KaitiM Big5 }
However it is a useful abstraction to be able to define unified fonts in
CSS that cover multiple languages as well as scripts, which requires a
language descriptor in @font-face rules. Without this one can end up
with an increased number of styling rules, eg. the product of the number
of fonts (heading, body text, sidenote) with the number of languages:
h1 { font-family: MyHeadingFont }
h1 *:lang(zh) { font-family: MyChineseHeadingFont }
p { font-family: MyTextFont }
p *:lang(zh) { font-family: MyChineseTextFont }
In this example it would be convenient to create unified fonts for
headings and body text that supported multiple languages.
If this isn't sufficient justification, we would be happy implementing
it as a vendor-specific property, which we would use to support the
definition of the default "serif" and "sans-serif" font families in our
default style sheets, which should support all scripts and languages.
Cheers,
Michael
--
Print XML with Prince!
http://www.princexml.com