- From: Jonathan Kew <jfkthame@googlemail.com>
- Date: Fri, 24 May 2013 18:32:25 +0800
- To: www-style list <www-style@w3.org>
A few copy-editing issues that caught my eye on reading through the
Editor's Draft today, plus some issues where I think the text could use
clarification.
JK
- - - - - - - - - -
(Status)
# This is a public copy of the editors' draft.
s/editors'/editor's/
- - - - - - - - - -
(3.1)
# Font family names must either be given quoted as strings, or unquoted
as a sequence of one or more identifiers.
This seems a little confusing: just above this, you say that
<generic-family> names, being keywords, must not be quoted; but then
this section says that font family names (of which <generic-family> is
one type) can be given "quoted as strings".
- - - - - - - - - -
(3.1)
# monospace
# The sole criterion of a monospace font is that all glyphs have the
same fixed width. This is often used to render samples of computer code.
Is this intended to exclude fonts that support any combining diacritics
(having zero width) from being considered "monospace"?
- - - - - - - - - -
(4.4)
# User agents that implement synthetic bolding and obliqueing
s/obliqueing/obliquing/
- - - - - - - - - -
(4.5)
# Wildcard ranges specified with ‘?’ that lack an initial digit (e.g.
"U+???") are valid and equivalent to a wildcard range with an initial
zero digit (e.g. "U+0???" = "U+0000-0FFF"). Wildcard ranges that extend
beyond the range of valid Unicode codepoints are invalid. Because of
this, the maximum number of trailing ‘?’ wildcard characters is four,
even though the UNICODE-RANGE token accepts six.
Why?
This does not make it clear (to me, at least) whether a range "U+?????"
(or equivalently "U+0?????") would be valid (it doesn't "extend beyond
the range of valid Unicode codepoints") or invalid ("the maximum number
of trailing ‘?’ wildcard characters is four").
- - - - - - - - - -
(4.8)
# The @font-face rule is designed to allow lazy loading of fonts, fonts
are only downloaded...
s/fonts, fonts/fonts: font resources/
- - - - - - - - - -
(5.1)
# For authors this means that font family names are matched case
insensitively, whether or not those names exist in a platform font or in
the @font-face rules contained in a stylesheet.
s/whether or not/whether/
- - - - - - - - - -
(5.2)
# If the desired weight is 500, 400 is checked first and then the rule
for desired weights less than 400 is used.
Looks copy-pasted from the preceding rule; I think you mean s/less than
400/greater than 500/ in this case.
- - - - - - - - - -
(6.3)
# Authors may prefer to disable kerning in situations where performance
is more important that precise appearance.
s/that/than/
- - - - - - - - - -
(6.6)
In Figure 24: Caseless characters with small-caps, all-small-caps
enabled, it's not clear why there's a difference between the serif and
sans-serif examples (i.e. the glyphs highlighted in red). I assume this
is simply because the two fonts used happen to support 'smcp' and 'c2sc'
variants for different repertoires of glyphs, but I think it'd be worth
pointing this out explicitly.
- - - - - - - - - -
(6.12)
# This means that explicitly disabling the kern feature will not affect
the application of kerning data found in the ‘kern’ table (as opposed to
kerning data associated with the kern feature in the ‘GPOS’ table).
This sounds like it was describing a now-obsolete state of the
implementation in Firefox. For UAs that rely on HarfBuzz for text
shaping, this is not currently true: if the UA asks HarfBuzz to disable
the kern feature, this will disable *both* the kern feature in the
‘GPOS’ table *and* the application of the ‘kern’ table data.
The connection between ‘GPOS’ and ‘kern’ table kerning is a low-level
implementation detail; I'm not sure CSS Fonts needs to deal with this,
but the current text does not describe what actually happens - at least
for Gecko, but likely for other UAs as well if they use the HarfBuzz
shaping engine.
- - - - - - - - - -
(6.12)
# For boolean features, a value of 1 enables the feature.
What does a value greater than 1 do for boolean features?
Received on Friday, 24 May 2013 10:32:59 UTC