[css3-fonts] Font Matching Algorithm: Comments I

http://dev.w3.org/csswg/css-fonts/#font-style-matching

Overall, I think it would be helpful if each step in this
section had a typographically distinct summarizing point
up front, like we did in the Flexbox algorithm:
   http://dev.w3.org/csswg/css-flexbox/#layout-algorithm
This makes it easier to scan, to get a sense of how all
the steps fit together before digging into the details,
and to have in mind the goal of each step as you are
reading through those details.

I'm also thinking it might be easier to understand the
algorithm if we split it into two parts:
   - Finding the ordered set of faces that are available
     to be used (matching faces)
   - Iterating over that list to find the font that is
     used for a particular character/cluster
     (matched face containing the right glyph)
Right now the spec uses "match" in both senses, so it's
unclear. Also this makes each procedure shorter and more
focused, so it's easier to grasp what's happening when
you're not trying to hold the entire algorithm and all
of its intersecting intricacies in your head. :)
(Granted this might not be the most efficient way to
implement things, but for spec work I prefer clarity
and understandability over performance.)

   # The procedure for choosing fonts consists of iterating
   # over the font families determined by the font-family
   # property, selecting a font face with the appropriate
   # style based on other font properties and then determining
   # whether a glyph exists for a given character.

This sentence seems like a rather incorrect summary of the
algorithm: it's missing the bit where you loop back if the
glyph is missing for that character, which is a pretty key
bit imo. IIRC, most systems in the 90s didn't have this
feature--you'd just get missing glyphs--so this is a
distinctive feature of how CSS font-matching works.

   # iterating over the font families determined by the
   # font-family property

s/determined/named/ to link us to the idea that this is
matching against the font name.

Also, put font-family in single quotes so it gets autolinked.

   # For this procedure, the <dfn>default face</dfn> for a given
   # font family is defined to be the face that would be selected
   # if all font style properties were set to their initial value.

Since this term is only used in step 5, please move this
definition there.

   # 1. Using the computed font property values for a given
   # element, the user agent starts with the first family
   # name in the fontlist specified by the ‘font-family’
   # property.

The first bit ("Using ... given element") is general to
the entire algorithm, not just this step. So I suggest
pulling it out and putting it at the top.

s/in the fontlist//

   # User agents may choose the generic font family to
   # use based on the language of the containing element
   # or the Unicode range of the character.

Do we want to allow the UA to choose the font based on
the language or of the document or the paragraph, and not
just of the element? It's good to avoid switching fonts
a lot, right? Ideally I'd pick Meiryo over Arial for a
Japanese document with English quotes, and use it
consistently throughout, if I'm smart enough to do that.

   # If the family name is unquoted and is a generic family
   # name [...]
   # For other family names [...]

These are really two forks of the same step, so probably
should be put together. Notice that the section below
that says the "previous two steps" points into only the
"For other family names" section, when it actually needs
to allow for both these possibilities.

Also,
s/is unquoted and is a generic family name/is a generic family keyword/
since we should to avoid making a distinction between
quoted and unquoted names at this level -- that's a
syntactic distinction that should already be handled
by the time we're dealing with computed values.

   # matching names with a case-insensitive comparison
   # as outlined _in the section above_.

Change to
   | matching names with a _case-insensitive comparison_
   | (as defined in the section below).
so that meaningful text is hyperlinked. This improves both
scannability and accessibility.

   # this is not required, they may treat all italic or
   # oblique faces as italic faces.

s/,/:/

   # ‘font-weight’ is matched next, it will always reduce
   # the matching set to a single font face.

s/, it/. It/

Also, this statement is, I believe, untrue, given that
'font-style' might result in multiple faces, and those
faces might all have the same weight.

   # If bolder/lighter relative weights are used, the effective
   # weight is calculated based on the inherited weight value,
   # as described in the definition of the ‘font-weight’ property.

Remove this sentence. We're dealing with computed values,
and as of the changes you requested and got several years
ago, the computed font-weight is always an absolute weight. :)

   # ‘font-size’ must be matched within a UA-dependent
   # margin of tolerance.

And what if that margin of tolerance is not satisfied?

   # The only exception is that user agents may optionally
   # substitute a synthetic version of the default face if
   # that face supports a given glyph (e.g. a synthetic
   # italic version of the regular face may be used if the
   # italic face doesn't support glyphs for Arabic).

This section doesn't reference 'font-synthesis'. Is that
property ignored here?

Also, it's not 100% clear to me whether this synthesis is
allowed only if Arial has an italic face already (but that
face is missing certain glyphs) or if it can be used to
synthesize italics even when italic Arial is not present
on the system. The phrase "the italic face" presumes the
italic face exists, but this is a rather subtle distinction.

   # While the download occurs, the user agent can either
   # wait until the font is downloaded or render once with
   # substituted font metrics and render again once the
   # font is downloaded.

There's some additional details on this procedure in the
section dedicated to it. This section should somehow
refer to those details, otherwise one might interpret a
conflict in the spec.

~fantasai

Received on Wednesday, 22 May 2013 05:50:38 UTC