Re: [css-fonts] Font family selection

Since the proposed change would still ultimately select a family from the
font-family list, that should still produce results that should be acceptable
to the page author. Is that the sort of brokenness you were talking about?
Could you perhaps provide some examples that I might not have considered?


On Wed, Aug 31, 2016 at 1:11 PM, Myles C. Maxfield <mmaxfield@apple.com> wrote:
> 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>
> 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> 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 Tuesday, 6 September 2016 17:08:10 UTC