W3C home > Mailing lists > Public > www-style@w3.org > August 2016

Re: [css-fonts] Font family selection

From: Myles C. Maxfield <mmaxfield@apple.com>
Date: Wed, 31 Aug 2016 13:11:40 -0700
Message-Id: <F55A7584-93F0-40B1-8F56-D0F9B7BC2741@apple.com>
Cc: www-style@w3.org
To: Ilya Kulshin <kulshin@google.com>
Sites rely on the current behavior of the interaction of font weight / style during font selection. Last time I changed something similar in WebKit, many webpages broke and I had to revert the change.

—Myles

> On Aug 31, 2016, at 1:00 PM, Ilya Kulshin <kulshin@google.com> wrote:
> 
> Can you elaborate on what you mean by web-compatible and breaking the web?
> 
> On Wed, Aug 31, 2016 at 9:11 AM, Myles C. Maxfield <mmaxfield@apple.com <mailto:mmaxfield@apple.com>> wrote:
> While this goal is noble, it is not web-compatible. Changing browsers to do this type of thing would break the web.
> 
> As a side-note, some browsers on some OSes may want to limit the set of fonts visible to the browser to only the set of preinstalled fonts on the OS in an effort to combat fingerprinting. It sounds like the use case you are describing requires user-installed fonts, so this approach may solve this problem.
> 
> —Myles
> 
> > On Aug 30, 2016, at 5:53 AM, Ilya Kulshin <kulshin@google.com <mailto:kulshin@google.com>> wrote:
> >
> > On Chromium, we've seen some instances where users end up with a font family that does not contain all of the expected styles. For example, someone might only have the bold style of Helvetica installed. When such a user views text with a style "font-family: Helvetica, sans-serif; font-weight: normal;", they would see bold text because that's the only style Helvetica can display, even though the page author clearly intended for regular text.
> >
> > Currently, the font matching algorithm requires using the first font family in the list that exists. The way the style matching is written, as long as there is any style, that family will match. I would like to propose that the algorithm should take the intended style (weight/stretch/etc) into account when matching families, and allow for matching a family specified later in the font-family rule if that family can provide a better style match.
> >
> > One possible implementation would be to assign a 'match-quality' to each family. For each family, the match-quality is evaluated and the family with the best match quality is used. One possible way is to evaluate match-quality is to assign it one of three values: good, average, or poor. A good match matches the desired style exactly or within a small tolerance (say, using a weight 300 font instead of desired weight 400). An average match matches the desired style on most characteristics but would be noticeably different. A poor match would differ noticeably on multiple criteria or have a very large difference on a single criteria (bold vs extra-light, for example). A more fine-grained scale could also be designed, if desired.
> >
> > One thing I'm not quite sure on is italic vs oblique matching. I suspect most users would not notice a significant difference between the two, but it would be good to get an opinion from someone familiar with typography.
> >
> > Any comments or concerns?
> >
> 
> 
Received on Wednesday, 31 August 2016 20:12:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 31 August 2016 20:12:10 UTC