[css3-fonts] @font-feature-values editorial

http://dev.w3.org/csswg/css-fonts/#font-feature-values

   # labeled as "font specific".

Since the other cases of "font specific" use italics rather
than quotes, keep with that habit here as well.

   # to define named-values

named values (no hyphen)

   # In the case of the swash Q in the example
   # ...
   # given font's data.

I think this should be wrapped in <div class="example">.
Likewise for other examples in this section. It will help
break up the flow, tie the various code snippets and
paragraphs of a single example together, and allow the
normative parts to be more easily separated out from the
example text.

   # The name "flowing" is chosen by the author, the values
   # specified within a given font's data.

I'm having a hard time parsing this sentence into something
grammatical. Can you paraphrase the second half somehow?

   # Feature value blocks are treated similar to at-rules,
   # they consist of everything up to the next block or
   # semi-colon, whichever comes first.

This makes no sense. It *is* an at-rule, it isn't treated
similar to one. Also the term "Feature value block" isn't
defined anywhere. Can we start with a prose description of
the syntax instead of just spewing a grammar production
and assuming this creates the requisite vocabulary and
conceptual model?

   # Font feature values rules define a set of values

s/of values/of named values/ to be consistent with previous
use of the term

   # The values associated with a given idenitifier are
   # limited to integer values 0 or greater.

s/idenitifier/identifier/

Also this sentence should move up and be placed right after
"indices used for specific features defined for a given font."
which is what it's talking about; the paragraph it's in is
talking about other things.

   # When syntax errors occur within a feature value
   # definition, such as invalid identifiers or values,
   # the entire feature value definition must be omitted,
   # similar to the way syntax errors in style declarations
   # are handled.

s/definition/declaration/g; to make this syntactic association
clearer. I'd also move this up to the paragraph about this
topic (value declarations), right after "values of 0 or greater"
(which itself would have been moved up).

   # When the <feature-type> is invalid, the entire associated
   # feature value block must be ignored.

This sentence should be placed right after "one of the font
specific values of the font-variant-alternates property."
because it's explaining a consequence of not matching that
condition. Similarly, the following two sentences probably
should be put together:

   # The font family list uses the same syntax as that used
   # for the ‘font-family’ property.

   # If syntax errors occur within the font family list, the
   # entire rule must be ignored.


   # Only named font families are allowed for <font-family>,
   # rules that include generic or system fonts [...]

Some places you use "<font-family>", others you use "font family
list". Please pick one moniker, define it, and be consistent.

Also, s/named font families/<family-name> values/
and split the sentence at the comma.

   # For <font-variant-property-value>, only font specific
   # property value names supported by the ‘font-variant’
   # property are recognized, definitions for other value
   # names cause a syntax error and are ignored. Each property
   # value that is font specific is clearly marked as such.

font-variant-property-value is nowhere defined. I think this
prose must be left over from a prior revision; what you're
saying here is already covered in previous paragraphs.

   # Feature value names follow the rules of CSS user
   # identifiers and are case-sensitive. They are unique only
   # for a given set of font families and font-variant property
   # value; the same identifier used with a different
   # font-variant property value is treated as a separate and
   # distinct value.

These sentences should somehow associate themselves with
the definition of feature value definitions/declarations...

   # Using a commonly named value allows authors to use a
   # single style rule to cover a set of fonts for which the
   # underlying selector is different for each font. If either
   # font in the example below is found, a circled number glyph
   # will be used:

I think this example illustrates a key design point, and
might be helpful to show earlier in the section, since it
shows what's the point of this rule.

   # Most font specific font-variant property values take a
   # single value (e.g. swash). The character-variant property
   # value allows two values and styleset allows an unlimited
   # number.

s/swash/''@swash''/
s/character-variant/''@character-variant''/
s/property/feature/g

This also needs to be tightened up a bit, since you don't
actually define how many values the other ones take. Swap
the order of the sentences and s/Most/The other/; that
should fix it.

   # Values greater than 99 or equal to 0 are ignored but
   # do not generate a syntax error when parsed.

   # For OpenType fonts, values greater than 99 or equal
   # to 0 are ignored but do not generate a syntax error
   # when parsed.

These sentences say exactly the same thing for two different
features, but their wording doesn't match. I suggest adopting
the second one for both features.

   # When two value names imply different settings for the
   # same underlying feature the last setting is used.

I believe, from the vocabulary used here, that you're talking
about multiple declarations of the same name. This behavior
is generic to all the features; it's not specific to
character-variant. Therefore this sentence should not be in a
paragraph that's all about character-variant, as that implies
it only applies there. Put it somewhere more generic.

~fantasai

Received on Thursday, 23 May 2013 11:40:46 UTC