- From: John Daggett <jdaggett@mozilla.com>
- Date: Mon, 23 Mar 2015 15:32:55 +0900
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CALYZoVNNbDFs27ggi34UPkhwixROFkYxPzDYSGNNsXc=410UXQ@mail.gmail.com>
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? > 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]? 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. 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. Regards, John Daggett Mozilla Japan [1] Santa Clara F2F discussion https://lists.w3.org/Archives/Public/www-style/2014Oct/0434.html [2] Original www-style posting proposing 'font-rendering': https://lists.w3.org/Archives/Public/www-style/2014Oct/0434.html https://github.com/igrigorik/css-font-timeout/blob/patch-1/README.md [3] Zach's font prefetch hint proposal https://lists.w3.org/Archives/Public/www-style/2014Oct/0515.html [4] Resource hints editor's draft http://w3c.github.io/resource-hints/
Received on Monday, 23 March 2015 06:33:24 UTC