Subscribed unsubscribe Subscribe Subscribe

Responsive imagesのための-webkit-image-set()


なにかというと、Retina displayやらPCとデバイスピクセル比が違うディスプレイに対して、違う画像を出し分ける、いわゆるResponsive imagesと呼ばれてるやつのための仕組み。


selector {
  background: -webkit-image-set( url(foo-lowres.png)  1x,
                                 url(foo-highres.png) 2x ) center;



出し分けるとなるとメディアクエリーとどう違うんだという話になる。この機能を提案したAppleのEdward O'Connorにはこういう考えがあるらしい。

Here are just a few of the problems with the current situation:

  • Bugs due to non-locality: One developer fixes a bug in the selector, but only in the low-resolution case. Another developer changes an image reference to refer to a different icon, but only in the high-resolution case.
  • Both assets may be loaded by the browser, which may degrade performance in a constrained bandwidth environment.
  • Authors can't specify both assets inside a style="" attribute.



Why a scale factor and not a full-blown media query?

Media queries are a claim about the state of the UA, whereas here we're making a claim about (the relationship between) the image assets themselves. It would be confusing to use similar syntax for such different things. Also, UAs should have the ability to choose between the given variants based on a variety of factors. For instance, a UA could use the lower res asset when a user has zoomed out. No existing media query distinguishes between the page being zoomed-out and being zoomed in. And even if such a media query existed, UAs should be free to choose between variant assets regardless of which media queries happen to match.


ズームインとかを考えると、たしかにmedia featureとは言いづらいかもね。

The problem of stylesheet verbosity when using media queries isn't limited to image assets. Shouldn't we have a general mechanism for keeping media-specific property values together in rule sets?

In talking with content producers here, we've found that the non-locality of asset references is a real source of Web author pain. I think a focused feature to help with that pain is sensible. That said, we should also explore how to help authors avoid selector repetition and the other pains of @media in general.


Why not enhance the image() function instead of inventing a new function?

Unlike image(), these image specifiers are unordered. This isn't about fallback. There is no preferred variant. UAs are free to use whichever image it believes would be best. For instance, consider the page zoom example I mentioned earlier. Authors could even use image() and image-set() together to handle more exotic cases, e.g.:

image(image-set(url(foo.png) 1x, url(foo@2x.png) 2x) rtl,
      image-set(url(bar.png) 1x, url(bar@2x.png) 2x) ltr);





というわけでcss3-imagesのEditorのTab先生とちょっと議論している。ただ読む限り、Ted (Edward)はあくまでimage()はフォールバックのためとしておきたいという気持ちが強いようで。Tabがそのあと、image()のリスト中にスラッシュを入れて、それをimage-set()の代わりにしてはどうだという提案をしているけれど、とくに返信もなくという状態。こっちのが好きかなあ。


実装されたのはさっきだけれど、やっぱり裏にはRetina display対応が絡んでるんだろう。今WebCoreに入れば、Safari 5.2の正式版に反映されてもおかしくないタイミングだし、iOSの次のバージョンにも取り込まれることは間違いない。

LionでHiDPIモードが進んでたのもあるし、OSXでもそのうちRetina display搭載のデバイスが出るんだろう。そこで多分使ってくるんだろうねえ。

そうなると、気になるのがHTML側ではどうするかということ。CSSではimage-set()ができたけど、HTMLにはそれが無いので、The new iPad™なページはXHRで2xな画像に差し替えてるなんてことをしている。


What about content images?

First off, this is www-style, so the design of an HTML feature for responsive <img>es is out of scope. :) That said, I can imagine the image-set() microsyntax being used in an attribute like so:

<img alt="A description of foo"
     set="foo-lowres.png 1x, foo-highres.png 2x">

I'll post something to the whatwg thread referencing this proposal.

とまあ、www-styleだからって提案ではないとしときながら、<img src=... set=...>と、属性を追加するかたちで提案している。後方互換性を考えると、srcの拡張は現実的ではないし、ズームイン/アウトのユースケースを考えると別の属性にしかならないだろう。<object>は禁句。

WHATWGになんかポストするとあるけれど、現時点ではとくにそんなメッセージはない。ただ今週あたまにCanvas APIにデバイスピクセル比やら高解像度用のImageDataやらが欲しいという提案をしている。