- From: Yoav Weiss <yoav@yoav.ws>
- Date: Thu, 14 Feb 2013 12:08:51 +0100
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: W3C CSS Mailing List <www-style@w3.org>
- Message-ID: <CACj=BEgJxpE=AvXjO7djfsDvRzsBn=eUb0BR89sAmL8HFyzpAg@mail.gmail.com>
+1 for the format() solution, which IMO is the cleanest one, and will be familiar to developers, since they already know it from font-face. Introduction of new formats may require to extend the spec. Since it is not highly frequent, it may not be an issue. Browsers can simply ignore resources with unknown type. Looking at the extension is a heuristic solution at best, since extensions are often inaccurate. This issue has been bothering me for a while now, making the image format fallback practically unusable. I'd love to see it fixed. Yoav On Thu, Feb 14, 2013 at 11:40 AM, Jake Archibald <jaffathecake@gmail.com>wrote: > The problem: image('whatever.webp', 'whatever.png') > > If the browser doesn't support webp it will still download 'whatever.webp' > and attempt a decode before it'll fallback to the png. It could exit early > when it gets the content-type header, but that's still more network > activity than ideal. > > Solution: Introduce format(), from @font-face > > https://gist.github.com/jakearchibald/2f6baeeefd0eee59d9ec > > The browser wouldn't bother with the webp if it doesn't understand it. > Like fonts, format isn't limited to mime types, allowing for > format('webp-progressive'), if webp ever gets a progressive format. > > The formats would be defined by the spec, as with fonts. > > Alternative solution: format fragment > > > https://gist.github.com/jakearchibald/2f6baeeefd0eee59d9ec#file-gistfile1-css-L12 > > We already use the fragment for media fragments, could use it for format > too. However, this creates repetition in image-set. Meh. > > Another alternative: Look at the 'extension' > > Could look at the suffix of the url. This has repetition in image-set as > above, but also feels clunky, especially for format sub-types, eg > whatever.webp-progressive. >
Received on Thursday, 14 February 2013 11:17:42 UTC