[css3-fonts] Not-quite-so-minor Comments V

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

   # If these descriptors are omitted, default values
   # are assumed.

Did you mean "initial values" or something else?

   # This allows authors to combine faces in flexible
   # combinations, even in situations where the original
   # font data was arranged differently.

I think this section would benefit from an example.
Particularly in combination with this bit:
   # If these descriptors are omitted, default values are
   # assumed.
which, assuming default=initial, means that a bold font will
not be considered font-weight: bold; unless that descriptor
is there.

   # User agents that implement synthetic bolding and
   # obliqueing must only apply synthetic styling in cases
   # where the font descriptors imply this is needed, rather
   # than based on the style attributes implied by the font
   # data.

I don't understand this. IMO synthetic bolding or obliquing
should only be applied to a downloaded font if the author
asks for a bold/oblique version and there isn't one available,
e.g.

   @font-face { font-family: foo; src: local(foo); }
   p { font-family: foo; }
   em { font-weight: bold; }
   /* em will synthesize bold, cuz we didn't have one */

vs.

   @font-face { font-family: foo; src: local(foo); }
   @font-face { font-family: foo; src: local(foo bold);
                font-weight: bold; }
   p { font-family: foo; }
   em { font-weight: bold; }
   /* em will not synthesize bold, cuz we have one */

No? Or am I totally mixing things up here?

While we're on this example, just wanted to clarify...
does the rule above mean that even if there's a foo italic
on the system, it will never be used because we defined
a font-family foo via @font-face?

http://dev.w3.org/csswg/css-fonts/#unicode-range-desc

   # <urange>

<urange> should have a proper <dfn> defining it as a type.

   # The values of <urange> are expressed using hexadecimal
   # numbers prefixed by "U+" or "u+", corresponding to Unicode
   # character code points.

This sentence should be pulled out and merged into the next
paragraph, which already says much the same thing. That
paragraph should be defining <urange>.

   # The unicode-range descriptor serves as a hint for user
   # agents when deciding whether or not to download a font
   # resource.

Since a key behavior of this descriptor is also to limit
the range of glyphs that can be used from this font, this
should also be mentioned up front.

   # Whitespace before or after commas is ignored.

This sentence is redundant with the definition of the #
multiplier, so should be removed.

   # discontinuous ranges are separated by commas.

   # Ranges can overlap but interval ranges that descend
   # (e.g. U+400-32f) are invalid and omitted rather than
   # treated as parse errors; they have no effect on other
   # ranges in a list of ranges.

   # User agents may normalize the list of ranges into a
   # list that is different but represents the same set of
   # character code points.

To focus these two paragraphs on defining <urange> syntax,
comma-separated list considerations should be pulled out
into a separate paragraph.

*** The following is a substantive issue. ***

   # Without any valid ranges, the descriptor is omitted.

I disagree with this. If there aren't any valid ranges,
the range should be the null set, not *everything*.

*** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ***

   # Ranges specified with ‘?’ that lack an initial digit
   # (e.g. "U+???") are also valid, and are treated as if
   # there was a single 0 before the question marks (thus,
   # "U+???" = "U+0???" = "U+0000-0FFF"). "U+??????" is
   # not a syntax error, even though "U+0??????" would be.

I am confused. Why do we imply a 0?

*** The following is a substantive issue. ***

Somewhere, somehow, the UNICODE-RANGE token from CSS2.1
should be mentioned here, and its syntax restrictions
reflected accordingly. For example, you don't mention that
there can be at most 6 hex digits or ? as part of the
syntax.

*** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ***

   #  A single range has three basic forms:

These descriptions could be expanded to define more
precisely the syntax allowed in each.

(Generally, the syntax section here could use some
reorganizing and tightening up.)

   # 1. The character range can be a subset of the full character
   # map of the underlying font. 2. The effective unicode-range
   # used when mapping characters to fonts is the intersection
   # of the unicode range specified and the underlying character
   # map of the font. 3. This means that authors do not need to
   # define the unicode-range of a font precisely, broad ranges
   # for which a sparse set of code points are defined in the font
   # can be used. 4. Code points outside of the defined
   # unicode-range are ignored, regardless of whether the font
   # contains a glyph for that code point or not.

The first sentence doesn't relate to the second one, but does
to the third. So the first two sentences should be swapped.
The second sentence is a general statement about how this all
works anyway, so belongs first as the topic sentence of the
paragraph.

The ordering should be
   2, 4, 1, 3
because that makes the paragraphs logic connect up properly.

Also, in sentence 3:
   s/precisely, broad/precisely: broad/
because run-on.

Lastly, I suggest shifting this paragraph up before the syntax
definition (into position 2, after the initial descriptor
description), because it explains fundamentally how it works
and is useful. (Because the syntax description is so long,
people will get lost and miss it.) Also the examples below it
are great to immediately follow the syntax description, so
such an ordering seems to be better overall.

   # Multiple @font-face rules with different unicode ranges

I think this part would benefit from a subsection heading,
e.g. "Composite Fonts and Cascading @font-face Rules" or
whatever, to help highlight it in the table of contents and
guide readers who got lost in the technical prose into paying
attention to author-relevant info again. :)

~fantasai

Received on Sunday, 19 May 2013 01:38:11 UTC