- 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