-
Notifications
You must be signed in to change notification settings - Fork 9
/
index.html
1045 lines (1029 loc) · 49.5 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>
Use Cases and Requirements for Standardizing Responsive Images
</title>
<style>
.stretchy{width: 100%;}
@media all and (max-width: 960px){
html{
margin-left: -2.5em;
}
}
@media print{
#participantslist{
display: none;
}
a:link,a:visited{
text-decoration: none;
color: inherit;
}
}
</style>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' async=""
class='remove'>
</script>
<script class='remove'>
var respecConfig = {
//additionalCopyrightHolders: "Copyright © the Contributors to this Specification, published by the <a href='http://www.w3.org/community/respimg/'>Responsive Images Community Group</a> under the <a href= 'https://www.w3.org/community/about/agreements/cla/'>W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href= 'http://www.w3.org/community/about/agreements/cla-deed/'>summary</a> is available.",
//license: "cc-by",
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "WG-NOTE",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "respimg-usecases",
// if your specification has a subtitle that goes below the main
// formal title, define it here
//subtitle: "Living Document",
// if you wish the publication date to be other than the last modification, set this
publishDate: "2013-11-05",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
previousPublishDate: "2013-02-26",
previousMaturity: "FPWD",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://usecases.responsiveimages.org",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [{
name: "Marcos Cáceres",
url: "https://marcosc.com/",
company: "Mozilla",
companyURL: "https://mozilla.com"
}, {
name: "Mat Marquis",
url: "http://matmarquis.com/"
}, {
name: "Yoav Weiss",
url: "http://blog.yoav.ws/"
}, {
name: "David Newton",
url: "http://davidnewton.ca/"
}],
// name of the WG
wg: "HTML Working Group",
// URI of the public WG page
wgURI: "https://www.w3.org/html/wg/",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-respimg",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/40318/status",
// !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
otherLinks: [{
key: "Version history",
data: [{
value: "Commit History",
href: "https://github.com/ResponsiveImagesCG/ri-usecases/commits/gh-pages"
}, {
value: "Github commits on Twitter",
href: "https://twitter.com/respimg_commits"
}]
}, {
key: "Participate",
data: [{
value: "Join the Responsive Images Community Group",
href: "http://w3c.responsiveimages.org"
}, {
value: "Public mailing list",
href: "http://list.responsiveimages.org"
}, {
value: "IRC: #respimg on W3C's IRC",
href: "irc://irc.w3.org:6665/#respimg"
}, {
value: "Twitter",
href: "https://twitter.com/respimg"
}, {
value: "Github",
href: "https://github.com/ResponsiveImagesCG/ri-usecases",
}]
}]
};
</script>
</head>
<body>
<p>
<a href="http://responsiveimages.org"><img style=
"position: absolute; top: 1em; right: 1em;" src=
"images/RICG_logo_small.png" alt="Responsive Images Community Group"></a>
</p>
<section id="abstract">
<p>
This document captures the use cases and requirements for standardizing
a solution for responsive images. The <a>use cases</a> and
<a>requirements</a> were gathered with consultation with the <a href=
"http://w3c.org/">HTML Working Group</a> and <a href=
"http://whatwg.org">WHATWG</a> participants, <a href=
"http://www.w3.org/community/respimg/"><abbr title=
"Responsive Images Community Group">RICG</abbr></a> group members, and
the general public.
</p>
<p id="welcome" class="now3c">
Found a bug, typo, or issue? Please <a href=
"https://github.com/ResponsiveImagesCG/ri-usecases/issues?state=open">file
a bug on github</a> or <a href="mailto:public-respimg@w3.org">email
us</a>!
</p>
</section>
<section id="sotd"></section>
<section>
<h2>
Introduction
</h2>
<p>
In <a data-cite="HTML">HTML</a>, a user agent's
<dfn>environmental conditions</dfn> are primarily expressed as CSS
<dfn>media features</dfn> (e.g., pixel-density, orientation, max-width,
etc.) and CSS media types (e.g., print, screen, etc.). A
<dfn>responsive image</dfn> is an image that adapts in response to
different <a>environmental conditions</a>: adaptations can include, but
are not limited to, changing the dimensions, crop, or even the source
of an image.
</p>
<p>
Many <a href="http://www.w3.org/TR/css3-mediaqueries/#media1">media
features</a> are dynamic in nature (e.g., a browser window is re-sized,
a device is rotated from portrait to landscape, and so on), thus a user
agent constantly responds to events that change the properties of media
features. As a document's layout adapts to changes in media features
and media type, an image's ability to communicate effectively can be
significantly reduced (e.g., images start to show compression artifacts
as they are scaled to match the quality of media or some media
feature). When this happens, developers rely on various <a href=
"http://css-tricks.com/which-responsive-images-solution-should-you-use/">
client/server-side solutions</a> to present images at different
resolutions, or even in different formats. Swapping images provides a
means to continue communicating effectively as the features of media
change dynamically.
</p>
<p>
Furthermore, as the <a href=
"https://github.com/ResponsiveImagesCG/picture-element/wiki/Display-technologies:-beyond-Retina">
number and varieties of high-density screens has increased</a> (both on
mobile and desktop devices), web developers have had to create custom
techniques for serving images that best match a browser's
<a>environmental conditions</a>. For a list of examples of the range of
<dfn>techniques</dfn> in use in 2012, see Chris Coyier's article
"<a href=
"http://css-tricks.com/which-responsive-images-solution-should-you-use/">Which
responsive images solution should you use?</a>". These techniques have
a number of limitations, discussed below, which serve as the motivation
to standardize a solution through the <a href="http://w3.org">W3C</a>
and <a href="http://whatwg.org">WHATWG</a>).
</p>
<p>
In formulating the requirements, this document tries to be
<em>neutral</em> - it is not predicated on any solution. The document
only tries to describe the use cases and what the <a href=
"http://www.w3.org/community/respimg/"><abbr title=
"Responsive Images Community Group">RICG</abbr></a> understands, from
<a href=
"https://github.com/ResponsiveImagesCG/picture-element/wiki/Relevant-resources#articles">
practice</a>, would be needed to address the use cases in the form of
<a>requirements</a>. The <a href=
"http://www.w3.org/community/respimg/"><abbr title=
"Responsive Images Community Group">RICG</abbr></a> expects that a
technical specification can be created to formally address each of the
<a>requirements</a> (i.e., the <dfn>solution</dfn>).
</p>
<section>
<h3>
Proposed Solutions
</h3>
<p>
To date, three such specifications are currently under development,
described below, one more has been abandoned. The three proposed, active solutions are not mutually
exclusive: together they address the set of <cite><a href=
"http://usecases.responsiveimages.org">Use Cases and Requirements for
Responsive Images</a></cite>.
</p>
<dl>
<dt>
<cite><a data-cite="HTML/embedded-content.html#dom-source-srcset">The `srcset`
attribute</a></cite>
</dt>
<dd>
<p>
Allows authors to define various image resources and “hints” that
assist a user agent to determine the most appropriate image
source to display. Given a set of image resources, the user agent
has the option of either following or overriding the author’s
declarations to optimize the user experience based on criteria
such as display density, connection type, user preferences, and
so on.
</p>
</dd>
<dt>
<cite><a href="http://picture.responsiveimages.org">The `picture`
element</a></cite>
</dt>
<dd>
<p>
Building on <a data-cite="HTML/embedded-content.html#dom-source-srcset">srcset</a>,
this specification defines a declarative solution for grouping
multiple versions of an image based on different characteristics
(e.g., format, resolution, orientation, etc.). This allows the
user agent to select the optimum image to present to an end-user
based on the user agent's <a>environmental conditions</a>, while
also providing the ability to "<a data-lt="art direction">art
direct</a>" images.
</p>
</dd>
<dt>
<cite><a href=
"http://tools.ietf.org/html/draft-grigorik-http-client-hints">HTTP
Client Hints</a></cite>
</dt>
<dd>
<p>
Defines a set of HTTP headers that allow browsers to indicate a
list of device and agent specific preferences. Servers can then
use these "client hints" to assist in content negotiation,
ideally resulting in content being served that best matches the
<a>environmental conditions</a> of the client for the resource
being requested.
</p>
</dd>
</dl>
<h3>Abandoned Proposed Solutions:</h3>
<dl>
<dt>
<cite><a href=
"http://tabatkins.github.io/specs/respimg/Overview.html">The `src-N` approach</a></cite>
</dt>
<dd>
<p>
The <cite>RespImg Syntax</cite> introduces a new
"<code>src-n</code>" attribute set on the <code>img</code>
element that accepts a small set of microsyntaxes. These
microsyntaxes address the viewport-based selection,
device-pixel-ratio-based selection, and art direction use cases
described in this document. The proposal claims to avoid the
implementor concerns associated with the `picture` element
proposal.
</p>
</dd>
</dl>
</section>
</section>
<section>
<h2>
Limitations of current techniques
</h2>
<p>
As currently there are no standardized solutions implemented in
mainstream browsers, web developers are relying on various <a href=
"http://css-tricks.com/which-responsive-images-solution-should-you-use/">
techniques</a> to use responsive images in their applications.
Unfortunately, there are significant <dfn>limitations</dfn> with these
<a href=
"http://css-tricks.com/which-responsive-images-solution-should-you-use/">
techniques</a>:
</p>
<dl>
<dt>
Reliance on semantically neutral elements and CSS backgrounds:
</dt>
<dd>
<p>
Large images incur unnecessary download and processing time,
slowing the experience for users. To work around this problem, web
developers specify multiple sources of the same image at different
resolutions and then pick the image of the correct size based on
the viewport size. As web developers lack the markup to achieve
what they need, they end up relying on semantically neutral
elements, <a href=
"http://dev.w3.org/csswg/css-backgrounds/#background-image">CSS
background images</a>, and JavaScript libraries. In other words,
developers are being forced to willfully violate the authoring
requirements of <a data-cite="HTML">HTML</a>.
</p>
</dd>
<dt>
Bypass preload scanner
</dt>
<dd>
<p>
The reliance on semantically neutral elements (e.g., the
<code>div</code> and <code>span</code> elements), instead of
semantically meaningful elements such as <code>img</code>, prevents
browsers from loading the image resources until after the DOM has
(at least partially) loaded and scripts have run. This directly
hinders the performance work browser engineers have done over the
years to optimize resource loading (e.g., WebKit's <a href=
"https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/parser/HTMLPreloadScanner.cpp">
HTMLPreloadScanner</a>). Unnecessarily bypassing things like the
preload scanner can have measurable performance impact when loading
documents. See, for example, <cite><a href=
"http://gent.ilcore.com/2011/01/webkit-preloadscanner.html">The
WebKit PreloadScanner</a></cite> by Tony Gentilcore for a small
study that demonstrates an up to 20% impact in load time when
WebKit's PreloadScanner is disabled. More recent <a href=
"https://plus.google.com/+IlyaGrigorik/posts/8AwRUE7wqAE">performance
tests</a> yield similar results. For more information, see
<cite><a href=
"http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/">
How the Browser Pre-loader Makes Pages Load Faster</a></cite> by
Andy Davies.
</p>
</dd>
<dt>
Reliance on scripts and server-side processing:
</dt>
<dd>
<p>
The <a href=
"http://css-tricks.com/which-responsive-images-solution-should-you-use/">
techniques</a> rely on either JavaScript or a server-side solution
(or both), which adds complexity and redundant HTTP requests to the
development process. Furthermore, the script-based solutions are
unavailable to users who have turned off JavaScript.
</p>
</dd>
</dl>
<p>
The <abbr title="Responsive Images Community Group">RICG</abbr>
believes standardization of a browser-based solution can overcome these
<a>limitations</a>.
</p>
</section>
<section>
<h2>
Use cases
</h2>
<p>
The following <dfn>use cases</dfn> represent usage scenarios commonly
seen "in the wild".
</p>
<section>
<h3>
Resolution-based selection
</h3>
<p>
Developers generally want to provide the same image in multiple
resolutions, so that high-res devices can get the optimum image for a
given resolution, while low-resolution devices can avoid wasting time
and bandwidth downloading overly-large files.
</p>
<figure>
<img src="images/resolution_selection.jpg" alt=
"Screens have a range of resolutions. Both real and virtual." style=
"max-width: 415px" class="stretchy">
<figcaption>
<p>
Figure shows screens that having different resolutions. These
resolutions can be either physical (matching physical pixels) or
virtual (matching css pixels).
</p>
</figcaption>
</figure>
</section>
<section>
<h3>
Viewport-based selection
</h3>
<p>
Image dimensions in responsive layouts tend to vary according to the
size of the viewport. This often results in images with large
dimensions (e.g., 2x or more times the size of the viewport) being
sent to browsers with narrow viewports, which are then resized by the
browser to fit the design (see, for example, <cite><a href=
"http://blog.netvlies.nl/design-interactie/retina-revolution">Retina
Revolution</a></cite> by Daan Jobsis and the <cite><a href=
"http://filamentgroup.com/lab/rwd_img_compression/">compressive
images</a></cite> technique). Ideally, developers would like to serve
images that match the user's viewport dimensions. Without a means to
do this, they sometimes need to send more data to the user than they
would otherwise need to.
</p>
<p>
For example, a 1000px wide image might be appropriate as a 1x image
when used to fill the background of the page, but it’s far too large
to use for the same purpose on a 320px wide screen. On a screen that
small, it’s more like a 2x or 3x image. In other words, the same
image might be applicable to multiple viewport sizes, but at
different effective resolutions.
</p>
<figure>
<img src="images/viewport_selection.jpg" alt=
"3 different viewport layouts, where the size of images differs based on the viewport."
class="stretchy" style="max-width: 415px">
<figcaption>
<p>
To avoid sending excess data, developers will send images that
more closely match the size of the viewport.
</p>
</figcaption>
</figure>
</section>
<section>
<h3>
Device-pixel-ratio-based selection
</h3>
<p>
To display images in a way that reduces perceptible artifacts (i.e.,
so the images look "crisp"), devices with different screen densities
require images with different minimal resolutions. Thus, the higher
the pixel density, the more pixels an image needs to have to look
good. This also applies to icons, where completely different images
may need to be used for different device-pixel-ratios (see
<cite><a href=
"http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes">All the
sizes of iOS app icons</a></cite>, by Neven Mrgan).
</p>
<figure>
<img src="images/dpr_selection.jpg" class="stretchy" style=
"max-width: 415px" alt=
"three devices, each having a unique device pixel ratio of 1x, 1.5, and 3x respectively.">
<figcaption>
<p>
On a device with a device-pixel-ratio greater than 1, higher
image resolutions are required to reduce visual artifacts
resulting from compression.
</p>
</figcaption>
</figure>
</section>
<section>
<h3>
<dfn>Art direction</dfn>
</h3>
<p>
In a responsive design, it is typical to change an image so it can be
targeted towards the features of a particular display (or set of
displays). Sometimes this means cropping an image. Other times, it
can mean a different image altogether that may have different
proportions or may be changed in other ways to communicate more
effectively in a layout. This means, for example:
</p>
<ul>
<li>On a large screen, a large image with plenty of details can be
shown (e.g., an object with a broad background).
</li>
<li>On a smaller screen, shrinking the same image can reduce its
relevance, usefulness, and legibility. Thus, by "art directing", a
web developer can better control communication by explicitly
dictating which image should be shown at which size (or when some
<a data-lt="environmental conditions">environmental condition</a> is
met).
</li>
</ul>
<p>
This is illustrated in the figure below.
</p>
<figure>
<img src="images/art_direction.jpg" style="max-width:400px" class=
"stretchy" alt="four devices showing art directed crops of a dog.">
<figcaption>
<p>
Using different images that have been cropped to fit a particular
screen's features can help in communicating a message
effectively.
</p>
</figcaption>
</figure>
<p>
A related use case is when orientation determines:
</p>
<ul>
<li>the source of the image,
</li>
<li>the crop,
</li>
<li>and how text flows around the image based on the size of the
viewport.
</li>
</ul>
<p>
For example, on the Nokia Lumia site where it describes the <a href=
"http://browser.nokia.com/smartphones.html">Meego browser</a>, the
Nokia Lumia is shown horizontally on wide screens. As the screen
narrows, the Nokia Lumia is then shown vertically and cropped. Bryan
and Stephanie Rieger, the designers of the site, explained that on a
wide screen, showing the full phone horizontally showed the browser
best; but on small screens, changing the image to vertical made more
sense because it allowed the reader to still make out the features of
the browser in the image.
</p>
<figure>
<video controls="" poster="videos/screenrmx1.jpg" class="stretchy"
style="max-width: 652px" onclick=
"if(/Android/.test(navigator.userAgent))this.play();">
<source src="videos/screenrmx1.m4v" type="video/mp4">
<source src="videos/screenrmx1.webm" type="video/webm">
<source src="videos/screenrmx1.ogv" type="video/ogg">
<source src="videos/screenrmx1.mp4"><object type=
"application/x-shockwave-flash" data="videos/flashfox.swf" width=
"652" height="389" style="position:relative;">
<param name="movie" value="videos/flashfox.swf">
<param name="allowFullScreen" value="true">
<param name="flashVars" value=
"autoplay=false&controls=true&fullScreenEnabled=true&loop=false&poster=videos/screenrmx1.jpg&src=screenrmx1.m4v">
<embed src="videos/flashfox.swf" width="652" height="389" style=
"position:relative;" flashvars=
"autoplay=false&controls=true&fullScreenEnabled=true&loop=false&poster=videos/screenrmx1.jpg&src=screenrmx1.m4v"
allowfullscreen="true" wmode="transparent" type=
"application/x-shockwave-flash" pluginspage=
"http://www.adobe.com/go/getflashplayer_en"> <img alt=
"Responsive images on Meego website" src="videos/screenrmx1.jpg"
style="position:absolute;left:0;" width="652" height="389" title=
"Video playback is not supported by your browser">
</object></video>
<figcaption>
<p>
Video showing art direction used on Nokia's Meego Website.
</p>
</figcaption>
</figure>
</section>
<section>
<h3>
Design breakpoints
</h3>
<p>
In Web development, a <dfn data-lt="breakpoints">breakpoint</dfn> is one of a series of
<a href="http://www.w3.org/TR/css3-mediaqueries/">CSS Media
Queries</a>, which can update the styles of a page based on matching
of <a>media features</a>. A single breakpoint represents a rule (or
set of rules) that determines the point at which the contents of that
media query are applied to a page’s layout. For example:
</p>
<pre class="example" style="overflow:auto">
@media screen and (max-width: 16em) { ... }
@media screen and (max-width: 32em) { ... }
@media screen and (max-width: 41em) { ... }
</pre>
<p>
Developers currently match specific <a title=
"breakpoint">breakpoints</a> for images to the breakpoints that they
have defined in the <a href=
"http://www.w3.org/Style/CSS/Overview.en.html">CSS</a> for their
applications. Being able to match the breakpoints ensures that images
are operating under the same rules that define the layout of a
design. It also helps developers verify their approach by ensuring
that the same viewport measurement tests are being used in both
<a data-cite="HTML">HTML</a> and <a href=
"http://www.w3.org/Style/CSS/Overview.en.html">CSS</a>. If the
developer cannot specify breakpoints for images in the same manner
that they are defined for the design, developers will need to convert
the breakpoints back to the values specified in the layout in order
to verify that they match. This increases authoring time and the
likelihood of human-error on the part of developers.
</p>
<p>
For example, if a <a>breakpoint</a> is specified as "<code>max-width:
41em</code>", then web developers would like to define a similar
breakpoint for images at a <code>max-width</code> of
<code>41em</code>. Otherwise they are forced to transform
measurements into another unit, like pixels, which is tedious and
potentially error-prone.
</p>
</section>
<section>
<h3>
Matching media features and media types
</h3>
<p>
According to <cite>Wikipedia's</cite> article on "<a href=
"http://en.wikipedia.org/wiki/Dots_per_inch">dots per inch</a>":
</p>
<blockquote>
<p>
"An inkjet printer … is typically capable of 300-600 DPI.
A laser printer … [prints] in the range of 600 to
1,800 DPI."
</p>
</blockquote>
<p>
As printers generally have the ability to pack more points per inch
than a device's screen, printers have to compensate for the lack of
pixel data by applying <a href=
"http://en.wikipedia.org/wiki/Reprographic" title=
"Reprographic">reprographic</a> techniques, such as <a href=
"http://en.wikipedia.org/wiki/Halftone">half toning</a>, to
simulate <a href="http://en.wikipedia.org/wiki/Continuous_tone"
title="Continuous tone">continuous tone</a> in imagery. As
illustrated below, applying such techniques can cause images to look
blurry and low-quality when compared to text.
</p>
<figure>
<img src="images/printed_image.jpg" class="stretchy" style=
"max-width:403px" alt="image comparison between screen and print.">
<figcaption>
<p>
Example of a 48px by 48px image and text printed at 1,200 DPI.
Because of the lack of image data, the printer compensates by
using the <a href=
"http://en.wikipedia.org/wiki/Halftone">halftone</a> <a href=
"http://en.wikipedia.org/wiki/Reprographic" title=
"Reprographic">reprographic</a> technique. Note that the text
stays crisp and is printed at the full 1,200 DPI.
</p>
</figcaption>
</figure>
<p>
Allowing developers to reference images at different resolutions
could allow user agents to choose an image that best matches the
capabilities of the printer. For example, a photo sharing site could
provide a bandwidth-optimized image for display on screen, but a
high-resolution image for print. The same technique could also be
used for e-book formats, such as <a href=
"http://idpf.org/epub">EPUB</a>.
</p>
<p>
However, displaying a color image on monochrome media (e.g., paper
and e-ink displays) can be problematic: different colors with similar
luminosity are impossible to distinguish on monochrome media. This
problem is illustrated in the figure below, where it becomes nearly
impossible to associate slices of a pie chart with corresponding
labels. This is a well-known accessibility problem, as described in
<a href=
"http://www.w3.org/TR/WCAG20/#visual-audio-contrast-without-color">WCAG
2.0</a>. A solution that affords developers the ability to
discriminate on media type could potentially increase the
accessibility of image content.
</p>
<figure>
<img class="stretchy" src="images/color_and_bw_graph.png" style=
"max-width: 560px" alt="a color and a black and white graph">
<figcaption>
<p>
Two pie charts, one in color and one in black and white, which
demonstrate the problem with switching from color to monochrome
media. In the black and white graph, it is extremely difficult to
know which slice relates to which label (except in the case of
"commute", which is a lighter shade).
</p>
</figcaption>
</figure>
<p>
Currently, server-side solutions exist to adapt web content to e-ink
displays (e.g., <a href="http://kinstant.com/">kinstant</a>), but
such services only work on text and layout and not on images. As
interpreting the meaning of images is a problem of <a href=
"http://en.wikipedia.org/wiki/Semiotics">semiotics</a>, it is
infeasible that this problem can ever be computationally solved. The
only feasible solution is for authors to provide alternative image
content that communicates effectively in monochrome media.
</p>
<p>
Lastly, through the <a href=
"http://www.w3.org/TR/css3-mediaqueries/">CSS Media Queries
specifications</a>, the <a href="http://www.w3.org/Style/CSS/">CSS
Working Group</a> continues to add media features to the Web
platform. New media features in <a href=
"http://dev.w3.org/csswg/mediaqueries4/">CSS Media Queries level
4</a> include <a href=
"http://dev.w3.org/csswg/mediaqueries4/#script">script</a>, <a href=
"http://dev.w3.org/csswg/mediaqueries4/#pointer">pointer</a>,
<a href="http://dev.w3.org/csswg/mediaqueries4/#hover">hover</a>, and
<a href=
"http://dev.w3.org/csswg/mediaqueries4/#luminosity">luminosity</a>.
The lack of a declarative mechanism to associate image content with
media features means that developers cannot use them without relying
on the aforementioned <a data-lt="limitations">limited</a>
<a>techniques</a>.
</p>
</section>
<section>
<h3>
Relative units
</h3>
<p>
A common practice in creating flexible layouts is to specify the size
values in media queries as relative units (e.g., <code>em</code>s).
This approach allows layouts to match the users’ default font size
(based on zoom level), and it avoid cases where the layout breaks on
devices who set a default font-size is set to something other than
the usual 16px.
</p>
<p>
If art-directed images are not specified in relative units, they can
either break the layout or become distorted when faced with a
uncommon default font-size (e.g., Amazon's Kindle defaults to 20px
instead of the usual 16px).
</p>
</section>
<section>
<h3>
Image formats
</h3>
<p>
Developers rely on the different capabilities of a range of image
formats to communicate effectively. These capabilities include, but
are not limited to, alpha transparency, animation, high-color depth
support, or better compression ratios for certain image categories.
For example, JPEG offers developers good optimization between image
quality and file size, but lacks alpha transparency or animation. So,
in cases where alpha transparency or animation is needed, developers
may instead rely on PNG, GIF, and emerging formats like WebP.
</p>
<p>
In a responsive design, images need to be displayed at different
sizes and device pixel ratios. When possible, a vector format such as
SVG might be most appropriate. There have also been proposals for new
responsive image formats (see, for example, <a href=
"http://www.netmagazine.com/opinions/need-responsive-image-format">Christopher
Schmitt's .net article</a>).
</p>
<p>
Although a web developer may want to use a specific image format, new
or otherwise, the browser may not always support it. Currently,
developers are forced to abandon the most suitable image format in
favor of one that has ubiquitous support across user agents.
</p>
</section>
<section>
<h3>
User control over sources
</h3>
<p>
In situations where the user knows their bandwidth is limited or
expensive (e.g., while roaming), the browser could assist users by:
</p>
<ul>
<li>Giving users an option to only download images in the quality
they desire - or disable images all together.
</li>
<li>Automatically select the most suitable image for the browsing
environment.
</li>
</ul>
<p>
There are browsers already catering for these kinds of situations.
For example, Opera Mini provides users with a choice of image quality
(but those images are compressed on the server). Amazon's Silk
browser also compresses images "in the cloud" (i.e., through their
own proxy servers) before serving those images to a user's device.
Google Chrome also allows users to disable images altogether through
"site preferences".
</p>
</section>
<section>
<h3>
Managing source swapping between breakpoints
</h3>
<p>
When a new image is loaded via <source> after hitting a new
breakpoint, there is a delay while the image is loaded. Any CSS which
matches the breakpoint applies itself. However, the previous image
still displays while the new one loads. This can result in blurry
imagery, or a larger image being scaled down in place of a smaller
one. Developers need means to control that flash of poor quality
imagery in these cases.
</p>
</section>
</section>
<section>
<h2>
Requirements
</h2>
<p>
The <a>use cases</a> give rise to the following
<dfn>requirements</dfn>:
</p>
<ol>
<li>
<p>
To allow for art direction, the <a>solution</a> MUST afford
developers the ability to match image sources with particular media
features and/or media types - and the user agent SHOULD update the
source of an image as the media features and media types of the
browser environment change dynamically.
</p>
</li>
<li>
<p>
The <a>solution</a> MUST support selection based on viewport
dimensions, screen resolution, and device-pixel-ratio (DPR).
Sending the right image for the given dimension and DPR avoids
delaying the page load, wasting bandwidth, and potentially reduces
the impact on battery life (as the device's antenna can be powered
off more quickly and smaller images are faster to process and
display). It can also potentially save users money by not
downloading redundant image data.
</p>
</li>
<li>
<p>
The <a>solution</a> MUST degrade gracefully on legacy user agents
by, for example, relying on HTML's built-in fallback mechanisms and
legacy elements.
</p>
</li>
<li>
<p>
The <a>solution</a> MUST afford developers with the ability to
include content that is accessible to assistive technologies.
</p>
</li>
<li>
<p>
The <a>solution</a> MUST NOT require server-side processing to
work. However, if required, server-side adaptation can still occur
through <a href=
"http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html">content
negotiation</a> or similar techniques (i.e., they are not mutually
exclusive).
</p>
</li>
<li>
<p>
The <a>solution</a> MUST afford developers the ability to define
the breakpoints for images as either minimum values (mobile first)
or maximum values (desktop first) to match the media queries used
in their design.
</p>
</li>
<li>
<p>
The <a>solution</a> SHOULD allow developers to specify images in
different formats (or specify the format of a set of image
sources).
</p>
</li>
<li>
<p>
To provide compatibility with legacy user agents, it SHOULD be
possible for developers to <a href=
"http://remysharp.com/2010/10/08/what-is-a-polyfill/">polyfill</a>
the <a>solution</a>. See the <a href=
"https://github.com/w3ctag/extending-html-responsibly/blob/master/RICG-recs/ricg.md">
W3C's TAG's recommendations to the RICG.</a>
</p>
</li>
<li>
<p>
The <a>solution</a> SHOULD afford user agents with the ability to
provide a user-settable preference for controlling which source of
an image they prefer. For example, preference options
could include: "always lowest resolution", "always high
resolution", "download high resolution as bandwidth permits", and
so on. To be clear, user agents are not required to provide such a
user-settable preference, but the <a>solution</a> needs to be
designed in such a way that it could be done.
</p>
</li>
<li>
<p>
In order to avoid introducing delays to the page load, the solution
MUST integrate well with existing performance optimization provided
by browsers (e.g., the solution would work well with the browser's
preload scanner). Specifically, the solution needs to result in
faster page loads than the current <a href=
"http://css-tricks.com/which-responsive-images-solution-should-you-use/">
techniques</a> are providing.
</p>
</li>
</ol>
</section>
<section class="appendix">
<h2>
Open issues
</h2>
<p>
We are tracking <dfn>open issues</dfn> on Github. <a href=
"https://github.com/ResponsiveImagesCG/ri-usecases/issues">Please help
us close them</a>!
</p>
<h2>
Changes history
</h2>
<p>
A <a href=
"https://github.com/ResponsiveImagesCG/ri-usecases/commits/gh-pages">complete
history of changes</a> is available on Github.
</p>
<p>
You can also see <a href=
"https://github.com/ResponsiveImagesCG/ri-usecases/issues?state=closed">
all the closed issues</a> relating to this document.
</p>
</section>
<section class="appendix">
<h2 id="acknowledgements">
Acknowledgements
</h2>
<p>
This document is composed of contributions from participants of the
responsive images community group.
</p>
<p>
The editors would like to thank the following people for reviewing this
document: Mike Taylor, Doug Shults, Barbara Barbosa Neves, Eileen Webb,
and Anselm Hannemann.
</p>
<p>
This document reproduces text from <a href=
"http://www.xanthir.com/contact/">Tab Atkin</a>'s <cite>Proposal for
RespImg Syntax</cite>, as permitted by its C0 license.
</p>
<p>
The figure in the viewport-based selection section is a derivative work
from <cite><a href=
"http://24ways.org/2012/responsive-images-what-we-thought-we-needed/"
rel="bookmark">Responsive Images: What We Thought We Needed</a></cite>,
by <a href="http://paulrobertlloyd.com/">Paul Robert Lloyd</a>.
</p>
<p id="participantslist">
<!--
To get the participant's list, go to
http://www.w3.org/community/respimg/participants
var all = document.querySelectorAll("td>h3"),
each = [];
for(var i = 0; i < all.length; i++){
each.push(all.item(i).textContent);
}
console.log(each.join(", "))
-->
<dfn>Participants</dfn> of the <a href=
"http://w3c.responsiveimages.org">Responsive Images Community Group</a>
at the time of publication were: Barry Atimer, Daniel Abril, George
Adamson, Heide Alexander, Marie Alhomme, John Allan, Joshua Allen,
Angely Alvarez, Agustin Amenabar, Aaryn Anderson, Philip Andrews,
Ritchie Anesco, Phil Archer, Tony Atayi, Tom Atkins, Justin Avery,
Mohsen Azimi, Phillip Baker, Raymond Baker, Michael Balensiefer, Toni
Barrett, Bruno Barros, Paul Barton, Adrian Bateman, Jesse Renée Beach,
Robin Berjon, Seth Bertalotto, Anirban Bhattacharya, Nicolaas Bijvoet,
Barna Bitai, Nathan Bleigh, Andreas Bovens, J. Albert Bowden, Adam
Bradley, Rodrigo Brancher, Gordon Brander, Paul Bridgestock, Aaron
Brosey, Brandon Brown, Cory Brown, mairead buchan, Kris Bulman, Ariel
Burone, Mathias Bynens, Marcos Caceres, Rusty Calder, Ben Callahan,
Loïc Calvy, Welch Canavan, Chuck Carpenter, Brandon Carroll, Frederico
Cerdeira, Daniel Chamberlin, Adi Chikara, David Clements, Geri Coady,
Anne-Gaelle Colom, Cyril Concolato, Jessica Constantine, Greg Cota,
Geoff Cowan, Andy Crum, David D'Amico, Jason Daihl, Francois Daoust,
Kevin Davies, Robert Dawson, Jacques de Klerk, Timothy de Paris, Ryan
DeBeasi, Anna Debenham, Darryl deHaan, David Demaree, George DeMet, Ian
Devlin, Alex DiLiberto, peter droogmans, Ronni Dyrholm Chidekel,
simpson eddie, Sylvia Egger, Dominic Fee, Ève Février, Maximiliano
Firtman, Ben Fonarov, Harry Fozzard, Marlene Frykman, Dennis Gaebel,
Igor Gajosinskas, Nicolas Gallagher, Miguel Garcia, Rafael Garcia
Lepper, Larry Garfield, Peter Gasston, George GeorgeHaeger, David Goss,
Chris Grant, Petra Gregorova, Ilya Grigorik, Jason Grigsby, Aaron
Grogg, Antoine Guergnon, Jeff Guntle, Aaron Gustafson, Jason Haag,
Jordan Haines, Cristina Hanes, Patrick Haney, Anselm Hannemann, chris
hardy, Vincent Hardy, Bridget Harrison, Duncan Hawthorne, Dominique
Hazaël-Massieux, Chris Hilditch, Jon Hill, Nathan Hinshaw, Sean Hintz,
John Holt Ripley, Enrico Hösel, Peter Hrynkow, Kym Huang, Shane Hudson,
Vinicius Ianni, Tomomi Imura, Philip Ingrey, Bryn Jackson, Rihnna
Jakosalem, Brett Jankord, Scott Jehl, Dave Johnson, Nathanael Jones,
Danny Jongerius, Michael Jovel, Chao Ju, Tim Kadlec, Raj Kaimal, Kevin
Joe Kanger, Frédéric Kayser, Serge K. Keller, Arthur Khachatryan, Jin
Kim, Andreas Klein, Peter Klein, John Kleinschmidt, Daniel Konopacki,
Darius Kruythoff, Zoran Kurtin, Vitaliy Kuzmin, Gerardo Lagger, Adam