W3C home > Mailing lists > Public > www-style@w3.org > November 2014

Re: [css-fonts] font prefetch hints

From: Yoav Weiss <yoav@yoav.ws>
Date: Thu, 13 Nov 2014 08:51:17 +0100
Message-ID: <CACj=BEg38Fb6QUHp7iX9YizTURYe+PYT142kSyQMVfOMeQRE4A@mail.gmail.com>
To: Ilya Grigorik <ilya@igvita.com>
Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
On Thu, Nov 13, 2014 at 12:05 AM, Ilya Grigorik <ilya@igvita.com> wrote:

> On Tue, Nov 11, 2014 at 3:20 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>> Regarding the opt-in for preloading purposes, I believe (but have not
>> proved yet) that it may not be necessary, and that CSS based resources can
>> be preloaded without it, at least for the majority of cases.
> A smarter CSS preloader would be *awesome*, and if you can make it happen,
> you'll be my hero... again. :)
> That said, while a smarter preloader would definitely help many sites, it
> is also not sufficient. Simple example: a JS constructed page that builds
> up its DOM from API data, etc -- preloader wouldn't be able to do much. A
> more complicated example: section of my site is displayed on-demand and
> uses a font that is otherwise not used anywhere else, and pulls in a new
> background image. For obvious reasons, I'd like to preload those resources
> before the user triggers the display of said section, such that they are
> not forced to wait for those to download.
> Both approaches work together: we need an explicit signal, and we could
> definitely use a smarter preloader.

Fair enough. I agree that there are cases where an opt-in would be
required. So, as you suggest, we could have an opt-in signal for
"guarantied" preloading, and do our best effort to figure out if a preload
is needed in its absence.
Received on Thursday, 13 November 2014 07:51:45 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:45 UTC