- From: Kenji Baheux <kenjibaheux@chromium.org>
- Date: Fri, 28 Nov 2014 14:30:31 +0900
- To: www-style@w3.org
- Message-ID: <CADWWn7Wn2tzLr+5wCXkDHryv2aCfQPjr+UpwetsdK1P79nks_Q@mail.gmail.com>
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