Re: [css-font-loading] load, check and testing for character coverage

On Fri, Apr 1, 2016 at 1:29 PM, Edward O'Connor <eoconnor@apple.com> wrote:
> Hi Tab,
>
> You wrote:
>
>> I have not so far heard *any* justification for why calling .check()
>> with a font that *does not exist* is something that an author would
>> want to do on purpose[…]
>
> But earlier in the thread, John provided you with justification. You wrote:
>
>>> The third case is that the search for matching font faces returns
>>> nothing, indicating that some of your sample characters can't be
>>> rendered by *any* of the fonts in the list. This is an error
>>> condition; either you misspelled your font names, or you're planning
>>> on using some characters that nothing can render. Either way, we
>>> definitely shouldn't return "true" (using that font string won't
>>> render like you expected), and probably shouldn't return "false"
>>> either (.load() won't do anything). This is why, near the end of the
>>> f2f, I suggested throwing in this case instead.
>
> And John replied:
>
>> It's not correct to say that it's an "error". Fontlists may or may not
>> cover the range of characters used. Look at the localization links at
>> the bottom of the Facebook landing page (www.facebook.com) for which
>> the fontlist is always 'arial, helvetica, lucida grande, sans-serif'.
>> For some of the items in the list, system font fallback will occur.
>> That's not an "error", that's the nature of fontlists in CSS.
>>
>> The check() method is there simply to allow users to determine whether
>> all fonts that might need to be loaded have actually been loaded[…]
>
> I find John's example to be a pretty compelling one.

That is a list composed solely of local fonts.  Why one would be
invoking any piece of the Font Loading API at all in that circumstance
is beyond me.

That said, assuming that at least one of those fonts exists (and
sans-serif *always* exists), that list will return true both in the
current spec and in the "no throwing" proposal.  It's not relevant to
the discussion.

On Mon, Apr 4, 2016 at 5:54 PM, Alan Stearns <stearns@adobe.com> wrote:
> On 4/3/16, 3:44 PM, "Geoffrey Sneddon" <me@gsnedders.com> wrote:
>>On Fri, Apr 1, 2016 at 9:56 PM, Simon Fraser <smfr@me.com> wrote:
>>> I think part of the problem here is that check() is a terrible name for a function, since
>>> it’s hard to know what the return value means. Currently, it means “font is available or
>>> additional loads won’t do anything”, but flipping this around allows the return value to mean
>>> “additional load is required”, so the function could be better named as:
>>>
>>> document.fonts.requiresLoad(…)
>>>
>>> or
>>>
>>> document.fonts.requiresAdditionalLoad(...)
>>>
>>> These make it clearer that no additional loads are going to help for a garbage font name.
>>
>>Very strongly agree that the name is a large part of the trouble, as
>>what is it checking? I'd guess whether fonts already loaded have all
>>characters in "text" (it's second arg) from the general behaviour,
>>which tends towards returning false when no font is loaded.
>>
>>I presume the ship has long since sailed for renaming it, though… :(
>
> Has it? Could we deprecate check() in favor of a better-named function? Would anyone who already has check() implemented object to this?

Theoretically, sure. But we try to avoid littering the platform with
deprecated names if possible.

I significantly rewrote the informative intro to explain what the
function does much more clearly - does that help?

~TJ

Received on Wednesday, 6 April 2016 00:05:41 UTC