- 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