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

Re: [css-fonts] font prefetch hints

From: Kenji Baheux <kenjibaheux@chromium.org>
Date: Fri, 28 Nov 2014 14:30:31 +0900
Message-ID: <CADWWn7Wn2tzLr+5wCXkDHryv2aCfQPjr+UpwetsdK1P79nks_Q@mail.gmail.com>
To: www-style@w3.org
I just caught up on the discussion and agree that the original @will-use
idea has inherent issues that makes it a poor fit for the use case.


>> - Perhaps we can extend url() to accept extra parameters? e.g.
>> url("http://...",
>> <fetch init options>?)

Does it mean that we would end up with redundant information when an
@font-face specifies multiple formats?


@font-face {
  font-family: myFont;
  src: url('myFont.eot?', <fetch init options>) format('eot'),
 url('myFont.woff' , <fetch init options>) format('woff'),
 url('myFont.ttf', <fetch init options>) format('truetype');
}


I imagine we would also want to give the same hints for the local() case:

src: local('Open Sans', <fetch init options>), [...]


In light of these redundancies, the generic "fetch-settings" attribute
approach is appealing:

@font-face {
    font-family: myFont;
    src: local('myFont'),
           url('myFont.eot?') format('eot'),
   url('myFont.woff') format('woff'),
   url('myFont.ttf') format('truetype');
    fetch-settings: preload <fetch init options>?;
}


However, the url parameter seems a much better fit for other use cases:

body {
    background-image: url("bg.png", <fetch init options>);
}

vs.

body {
    background-image: url("bg.png");
    fetch-settings: preload <fetch init options>?;
}
Received on Friday, 28 November 2014 05:31:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC