Re: [css-fonts] Proposal for 'font-rendering' property

On Sun, Mar 22, 2015 at 11:32 PM, John Daggett <jdaggett@mozilla.com> wrote:
> Tab Atkins wrote:
>> At the last F2F, I introduced a proposal for a 'font-rendering'
>> @font-face descriptor and property, for controlling the block/swap
>> timeout behavior for downloadable fonts.
>
> I think you're referring to the discussion at the October F2F in Santa
> Clara [1]. Was there another discussion at the Sydney F2F?

Sorry, no, I was indeed referring to Santa Clara.

>> Today I wrote it up properly, at
>> <http://tabatkins.github.io/specs/css-font-rendering/>.  Please
>> review, and tell me what you think.
>
> What's different from the original posting and list discussion back in
> October [2]?

Firming up of language and tweaking of grammars.

> I think the underlying problem here is that authors want to avoid
> visually jarring in-between states shown while font resources download.
> It would make more sense I think to first attack the causes of those states
> rather than twiddling the transitions.
>
> As Zach noted back in October [3], to initiate font loads earlier I
> actually think having some form of load hint for downloadable fonts is
> much more important than twiddling timeouts. Whether this is best
> defined via a new descriptor for @font-face or via resource hints [4] is
> an open question.

No, preloading doesn't help. Or rather, it can help, but it's solving
something different.  Getting necessary fonts loaded faster is always
good, of course, but even if you trigger the font download in the very
first network packet of the response (which can potentially be done
today, with appropriate arrangement of styles/content), you still have
to deal with potentially seeing no text until 3s in, during which the
entire rest of the page could have already loaded.  So a "block or
not" control is still very useful even in a world with font
preloading.  And it's useful for things that *aren't* known ahead of
time and can't be preloaded - you can still want those things to
display immediately with a fallback font rather than have invisible
text.  Font preloading really is a completely separate issue that
doesn't impinge on this proposal.

That also doesn't address at all the "swap or leave it stable" concern
- for body text, after a fairly short period of time, it's better to
leave it with the font it has, so text doesn't jiggle around while
people are in the middle of reading.

> I'm relatively skeptical about this proposal in general, especially the
> notion of author-defined font resource timeouts. Font resource loads are
> initiated relatively late in the page load process when text is laid out
> and font matching occurs. Twiddling the behavior of *intermediate*
> rendering of pages is very dependent on how an implementation
> prioritizes resource loads and performs progressive rendering of loaded
> contents. How exactly would an author evaluate "120ms" vs. "3s" as a
> timeout, given that the impact of those parameters across
> implementations will *not* be consistent, especially in the case of mobile
> connections?
>
> As a user I'm also wary of giving authors a way to effectively override
> a user agent's ability to show fallback content to the user in
> situations where network connectivity is poor. This proposal gives
> authors a way to mandate that user agents withhold text display until
> font loads complete, rather than allowing user agents to display
> fallback text or not based on network conditions. As any iPhone user on
> a slow mobile connection can tell you, that's sometimes a complete
> annoyance.
>
> It would help to see more detailed examples of use cases for this
> proposal. I've seen people discussing polyfills for CSS Font Loading
> that try to control these transitions. It would be useful to see how
> they fit with this proposal.
>
> It would also really help the discussion to see specific use cases that
> require different *timeouts* and swapping behavior. I'm aware that some
> have proposed icon fonts as a use case for 'mandatory' but I think icon
> fonts are a special case that don't actually require 'mandatory' since
> they primarily use private-use codepoints for which fallback explicitly
> does not occur.

In the call today, we agreed to initially give the spec only the
keyword values, with an issue discussing whether or not to allow
explicit timeouts.

~TJ

Received on Wednesday, 8 April 2015 20:19:34 UTC