[css3-fonts] font-variant-* Minor Comments I

http://dev.w3.org/csswg/css-fonts/#font-kerning-prop

It would be helpful for people quickly looking things up
if the value definitions ("The value ‘normal’ ... text
script.") were put into a <dl> instead of inlined into
the introductory paragraph.

   # The value ‘normal’ implies that kerning is applied while
   # the value ‘none’ implies that kerning is not applied when
   # rendering text.

s/implies/specifies/g;

   # and to vary that default based on the underlying text script.

Are there other reasons the UA can vary the default, or
are they only allowed
   a) on by default
   b) off by default
   c) depends on text script
?

   # data contained in a ‘kern’ font table

Use <code> instead of single quotes, as this is not a CSS property
or descriptor.

   # Authors may prefer to disable kerning in situations
   # where performance is more important that precise appearance.

This sentence seems really out-of-place in this paragraph.

   # default spacing, letter spacing

s/,/;/

http://dev.w3.org/csswg/css-fonts/#font-variant-ligatures-prop

   #  A value of ‘normal’ implies that ...
   # A value of ‘none’ ... text rendering.

This should be part of the value definition <dl>, not part of
the intro paragraph for the property. This makes it easier to
see what values are allowed in the property.

Also, s/implies/specifies/g

   # type designer so authors

Insert comma before so.

http://dev.w3.org/csswg/css-fonts/#font-variant-position-prop

It would be helpful for people quickly looking things up
if the value definitions ("The values 'sub' and 'super'...
substituted.") were put into a <dl> instead of inlined into
a paragraph.

   # This is done to avoid

s/done/done per run/ to clarify what we're justifying here

   # In the case of OpenType fonts that lack subscript or

This sentence would fit better merged into the previous
paragraph than standing on its own, since, like the previous
paragraph, it's explaining the synthesis of these glyphs.

Figure 22 (alt glyph, synthesized glyphs, mix) would be
better placed immediately after this paragraph (which it
is directly illustrating) than two paragraphs away.

   # While subscript and superscript glyphs are often available

This sentence is illustrating the previous sentence, so I
would suggest prepending "For example" to link it as such.

   # This property is not cumulative, applying it to subelements

Run-on. Break the sentence at the comma. s/subelements/elements/
as there's no such "thing" as a subelement, and you already
have "within" to denote containment of the element.

   # Because of these limitations, font-variant-position
   # is not recommended

'font-variant-position'

   # Authors should use it in cases where subscripts or
   # superscripts will only contain the narrow range of
   # characters supported by the fonts specified.

Given that we are synthesizing characters not in that
range, why are we recommending this? Isn't it better
to synthesize (if necessary) via font-variant-position
than to have the author manually synthesize it via
'vertical-align' and sizing?

   #     vertical-align: inherit;

You really don't want to do that. Use 'baseline'.

http://dev.w3.org/csswg/css-fonts/#font-variant-caps-prop

   # This property allows the selection of alternate glyphs
   # ... resized to fit this purpose.

This is a *great* introduction. Suggest replacing the current
5-word intro with this paragraph instead of hiding it down
here.

   # When casing transforms are used to simulate small
   # capitals, the casing transformations should match
   # those used for the ‘text-transform’ property.

Is there a reason for this to be 'should' rather than 'must'?

   # As a last resort, unscaled uppercase letter glyphs
   # in a normal font may replace glyphs in a small-caps
   # font so that the text appears in all uppercase letters.

What has to fail for us to get to this point? I'm missing
that context.

http://dev.w3.org/csswg/css-fonts/#font-variant-numeric-prop

   # Enables display of forms used with ordinal numbers

You've got really great illustrations for all the other
features in this section, please add one for this too!

   # The example below shows how these different properties
   # can be combined to influence the rendering of tabular
   # data with fonts that support these features.

I suggest shifting this just above the value definitions.
For one, it shows off what the first four values mean so
you can have that vision in your head while you read the
value descriptions. For two, it also avoids splitting the
value list in half, which is somewhat awkward imho.

   # A simple flank steak marinade recipe, rendered with
   # automatic fractions and old-style numerals:

You took some effort to wrap the amounts in spans and
only style those, rather than the whole list. If there's
a good reason for that, I suggest explaining it. (If not,
then just apply the rule to the <ul>.)

http://dev.w3.org/csswg/css-fonts/#font-variant-alternates-prop

There's only one non-font-specific value, 'historical-forms'.
I suggest putting this either first or last, rather than
partway through the list.

   # salt <feature-value-name>

I believe, from inspecting the other values here, that
you meant <feature-index> instead of <feature-value-name>.

   # In cases where multiple alternates are possible,
   # [...]

I find that this paragraph isn't really doing a good job
of explaining what's going on here. Maybe something like

   | Except for 'historical-forms', multiple alternates are
   | possible. Because nature of these alternates is font-
   | specific, the ''@font-feature-values'' at-rule is used
   | to define values for a specific font family or set of
   | families. Using this rule, authors can associate a
   | font-specific numeric <feature-index> with a custom
   | <font-feature-name>, which is then used in this
   | property to select a specific set of alternates.
   | When a particular value has not been defined [...]

   # Values that behave this way are marked as font specific.

This instance of "font specific" should be wrapped in <dfn>.

   # swsh <feature-index>, cswh <feature-index>

Are both enabled simultaneously? One or the other depending
on some particular situation? It's unclear to me what this
means.

   # to select the desired glyph using <feature-value-name>.

   | to select the desired glyph using ''ornaments()''

Because <feature-value-name> is generic to the whole section,
but 'ornaments()' indicates you're recommending they use ornm.

~fantasai

Received on Thursday, 23 May 2013 11:21:59 UTC