Preserve ordering of font-* properties that follow a font shorthand

[samizdatco]

This PR prevents non-shorthand font-* properties being reordered to precede a shorthand font rule.

Existing behavior

As described in #1207, the FontHandler currently watches for all the properties that could be combined into a shorthand (e.g., font-family, font-weight, font-style, etc.), but will immediately emit any unrecognized font properties such as font-variant or font-kerning while deferring the font shorthand.

For example (playground):

.foo{
  font: 12px serif;
  font-variant-numeric: oldstyle-nums;
  font-kerning: none;
}

will be minified to:

.foo{font-variant-numeric:oldstyle-nums;font-kerning:none;font:12px serif}

This is a problem because placing the font shorthand at the end has the side-effect of resetting all prior font-* properties to their defaults, which is clearly not the intent of the original css.

Changes

I added a new match branch to FontHandler’s handle_property method to catch any Property::Custom that begins with "font-" (but has not already been caught as a property that could be merged into the shorthand) and trigger a flush of the pending shorthand before emitting the newly encountered longhand.

Initially I applied this to just the font-variant-* properties (cd12e58), but I believe this behavior is actually desirable for all non-shorthand font properties so I extended it to the whole font-* prefix.

Fixes #1207

Questions

I'm not quite clear on the distinction between Property::Custom and Property::Unparsed; maybe this needs to check Unparsed properties to see if they match the font-* prefix as well?

I added an optimization that discards the cached longhand properties when a shorthand font declaration is encountered (since they'll all be reset to their defaults anyway). Are there any negative consequences to doing this? [reverted: see discussion below]

[stof]

I added an optimization that discards the cached longhand properties when a shorthand font declaration is encountered (since they'll all be reset to their defaults anyway). Are there any negative consequences to doing this?

the downside is that this assumes that the shorthand will be parsed successfully by all browsers.
If the shorthand uses a syntax that is not supported by the browser, it would be discarded and would not reset all the longhands.

[samizdatco]

the downside is that this assumes that the shorthand will be parsed successfully by all browsers. If the shorthand uses a syntax that is not supported by the browser, it would be discarded and would not reset all the longhands.

Good point. So in that case, maybe the better solution is the one in the previous commit where the appearance of a longhand property triggers any pending shorthand to be flushed first (i.e., it prevents reordering but doesn't discard potentially-reset longhands)?