-
Notifications
You must be signed in to change notification settings - Fork 45
/
article.htm
405 lines (335 loc) · 28.5 KB
/
article.htm
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
<h1>Clown Car Technique</h1>
<h2>Solving for Adaptive Images in Responsive Web Design</h2>
<p>Adaptive images are the current hot topic in the Adaptive Design
and Responsive Web Design conversations. Why? Because no one likes any of the solutions. </p>
<p>New elements and attributes are being discussed as a solution for what is, for most of us, a big headache that's almost as big as the problem: providing users with one image optimized for their display size and resolution without wasting time, memory or bandwidth with a client side solutions.</p>
<p >We have foreground and background images. We have large displays
and small displays. We have regular resolution and high resolution displays. We
have good bandwidth and low bandwidth connections. We have portrait and
landscape orientations.</p>
<p>Some choose to "waste bandwidth" (and memory) by sending
high-resolution images to all devices. Others send regular resolution images to
all devices which look less crisp on high resolution displays. </p>
<p>What we really want to do is find what we call the “holy grail”: The one solution that sends the most appropriate size and resolution image based on the browser and device making the request.</p>
<p>The Clown Car Technique is the closest thing to a “holy grail”: leveraging well supported @media queries, SVG and <object> to serve responsive images with a single request. It's not a perfect solution yet, but we're getting close.</p>
<h2>Background Images and Media Queries</h2>
<p> We've solved adaptive images when it comes to background images. Media queries make it simple to send the right size and resolution images based on the device pixel ratio, viewport size and even the orientation of the screen. </p>
<p>By using media queries with our background image styles, we can ensure only the images we will be using are downloaded from the server. We can limit the downloads to the assets that are most appropriate, saving bandwidth, memory and HTTP requests. </p>
<p>Unfortunately, there has historically been no solution for foreground images. Until now. The technology has been available for a long time. CCT is just a new technique leveraging existent technology.</p>
<h1>Proposed solutions with new technology</h1>
<h2>New Elements and Attributes</h2>
<p>With inline or <em>content images</em>, it's a bit more difficult to have the browser download and display only the appropriate foreground image. Most believe that there is no mechanism for the <code><img></code> tag to download the right size and resolution image. To that end, <a href="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/scottjehl/picturefill">polyfills</a> have been created and <a href="https://sencha.com/products.io">services</a> have been formed.</p>
<p>The '<a
href="https://www.w3.org/TR/html-picture-element/#the-picture-element"><picture>'</a> element, leveraging the semantics of the HTML5 '<video>' elements with
its support of media queries to swap in different source files was proposed:</p>
<pre><<b>picture</b> alt="responsive image">
<source src="large.jpg" media="(min-width:1600px),
(min-resolution: 136dpi) and (min-width:800px)">
<source src="medium.jpg" media="(min-width:800px),
(min-resolution: 136dpi) and (min-width:400px)">
<source src="small.jpg">
<!-- fallback -->
<img src="small.jpg" alt="responsive image">
</picture>
</pre>
<p>Another method, using a <a href="https://www.w3.org/html/wg/drafts/srcset/w3c-srcset/"><code> srcset</code> attribute</a> on the <code><img></code> element, has also been proposed. The above <code><picture></code> element would be written as: </p>
<pre><img
alt="responsive image"
src="small.jpg"
srcset="large.jpg 1600w,
large.jpg 800w 1.95x,
medium.jpg 800w,
medium.jpg 400w 1.95x"></pre>
<p>Both solutions have benefits and drawbacks. It's hard to pick which one. So hard, in fact, that you don't have to anymore. They've joined the two solutions into called <a href="https://www.w3.org/community/respimg/2012/06/18/florians-compromise/">Florian's Compromise</a>. Though the <a href="https://www.brucelawson.co.uk/2013/responsive-images-intrerim-report/">traction isn't quite there</a> yet on either method.</p>
<p>Google has proposed <a href="https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/edit?pli=1#slide=id.p19">client hints</a> as part of http headers to enable the right image to be served server side.</p>
<h2>SVG as an Out of the Box Solution</h2>
<p>What many people don't realize is we already have the technology to create and serve responsive images.</p>
<p>SVG has supported media queries for a long time, and <a href="https://caniuse.com/#search=svg">browsers have supported SVG</a> for ... well, a long enough time too. Most browsers support SVG media queries in SVG (<a href="https://jeremie.patonnier.net/experiences/svg/media-queries/test.html">Test your browser</a>). When it comes to browsers that need responsive images, the only browser in the mobile space that doesn't support SVG is old versions of the Android browser. (Android support for SVG began with Android 3.0.)</p>
<p>We can leverage browser support for SVG <em>and</em> SVG support for both media queries <em>and</em> raster images to create responsive images, using media queries within SVG to serve up the <em>right</em> image. </p>
<p>My original experiment should theoretically work, and does work in IE10 and Opera: when you mark up your HTML, you add a single call to an SVG file.</p>
<pre><img src="<strong>awesomefile.svg</strong>" alt="responsive image"></pre>
<p>Now isn't that code simple? </p>
<p>SVGs support raster images included with the <code><image></code> element and with the CSS <code>background-image</code> property. In our responsive SVG, we include all the images that we may need to
serve and show only the appropriate image based on media queries.</p>
<h2>Download single raster image</h2>
<p>My first SVG attempt used <code><image></code> with @media queries hiding them with <code>display: none;</code>. </p>
<p>While the SVG works perfectly in terms of being responsive, it has several issues. Unfortunately, <code>display: none;</code> on an
<code><image></code> in SVG, similar to <code><img></code> in HTML, does not prevent the
resource from being downloaded. If you <a
href="https://estelle.github.io/clowncar/local.svg">open the <code><image></code> SVG in your
browser</a>,
all 4 PNGs are retrieved from the server, making 4 http requests,
wasting bandwidth and memory.</p>
<p>We know from CSS background images it is indeed possible to only download needed images. Similarly, to prevent the SVG from downloading all the included images
we use CSS background images instead of foreground images in our SVG
file:</p>
<pre><svg xmlns="https://www.w3.org/2000/svg"
<strong>viewBox</strong>="0 0 300 329" <strong>preserveAspectRatio</strong>="xMidYMid meet">
<title>Clown Car Technique</title>
<style>
svg {
background-size: 100% 100%;
background-repeat: no-repeat;
}
@media screen and (max-width: 400px) {
svg {
background-image: url(images/small.png");
}
}
@media screen and (min-width: 401px) and (max-width: 700px) {
svg {
background-image: url(images/medium.png);
}
}
@media screen and (min-width: 701px) and (max-width: 1000px) {
svg {
background-image: url(images/big.png);
}
}
@media screen and (min-width: 1001px) {
svg {
background-image: url(images/huge.png);
}
}
</style>
</svg></pre>
<p>If you're familiar with media queries and CSS, most of the above
should make sense. The clown car technique uses the same @media queries as you would use elsewhere in your adaptive site.</p>
<p>To preserve the aspect ratio of the containing element and ensure that is
scales uniformly, we include the <code><strong>viewbox</strong></code>
and <code><strong>preserveAspectRatio</strong></code> attributes.</p>
<p>The value of the <code>viewBox</code> attribute is a list of four
space or comma separated
numbers <code>min-x</code>, <code>min-y</code>, <code>width</code> and <code>height</code>. By defining
the width and the height of our viewbox we define the aspect ratio of the
SVG image. The values we set for the <a
href="https://developer.mozilla.org/en-US/docs/SVG/Attribute/preserveAspectRatio">preserveAspectRatio</a> attribute -- 300x329 --
ensures the aspect ratio defined in <code>viewbox</code> is preserved.</p>
<p>When you<a href="https://estelle.github.io/clowncar/jpeg/jpeg/svg.svg"> open
the SVG file with just background images</a> defined, the raster image
will take up the entire viewport. While the <code><image></code> version may look better
as a stand-alone file because it is maintaining it's aspect ratio, and the background-image
version is filling up the viewport, when you include the SVG as a separate
document pulled into your HTML, the aspect ratio is by default preserved.</p>
<p>The CSS background-image property solves the http request issue. <a
href="https://estelle.github.io/clowncar/object/bgonly.svg">Open the SVG file
with just PNG background images</a> (or <a href="https://estelle.github.io/clowncar/jpeg/jpeg/svg.svg"> the JPEG version</a>) and look at the resources tab in your
developer tools and you'll see the SVG has only made 2 http requests rather
than 5. If you are on a large monitor, the browser will have downloaded
a small .svg file (676 bytes) and huge.png or huge.jpg.</p>
<p>Our first issue -- downloading all the different image file sizes,
even those that aren't needed -- has been resolved. This background-image
version downloads only the image required, thereby solving the multi-HTTP and
waste of bandwidth concerns. </p>
<p>The magic happens when we include SVG in a flexible layout. You'll note the first time you resize the image, there may be
flickers of white as the browser requests the next required PNG -- this is because it
doesn't automatically download all the assets. Rather, it downloads only the asset it needs.</p>
<p>We still have the SVG file itself which requires
an http request. We'll solve that issue third.</p>
<h2>Content Security Issues</h2>
<p>In the Opera browser or Windows 9 or 10, open the <a
href="https://estelle.github.io/clowncar/imagetag/">HTML file containing a SVG raster image</a> linked to with the
<code><img> tag.</code> Note in the resources panel of your developer tools that only one jpeg or png is being downloaded. Resize your browser. Note that the <img> is responsive. Additional JPEGs or PNGs (we could also have used GIFs or WebP) are only downloaded if needed.</p>
<p>If you opened the <a
href="https://estelle.github.io/clowncar/imagetag/">HTML file containing a SVG raster image</a> in Firefox
or WebKit, you'll likely saw no image. The SVG works in all modern browsers, but the <img> calling in an SVG pulling in raster images only works in Opera and IE 9+. </p>
<p>We'll first cover how it works in IE and Opera, then we'll cover the issues with WebKit and Firefox.</p>
<p>The code is simply: </p>
<pre><img src="awesomefile.svg" alt="responsive image"> </pre>
<p>When you include the SVG in your HTML <code><img></code> with a flexible
width, such as 70% of viewport, as you grow and shrink the container by changing the window size or changing the CSS, the image
responds to the changes. </p>
<p>The "width" media query in the SVG is based on the
parent element in which the SVG is contained -- the <img> in this case -- not the viewport width. </p>
<p>As the window grows and shrinks the image display by the SVG
changes. In the SVG file, the images are defined as being 100% of the height
and width or the parent, which in the above case, when we opened
the SVG directly, was the viewport. Now the container is the <code><img></code> element.
Because we included the <code><strong>viewbox</strong></code> and <code><strong>preserveAspectRatio</strong></code> attributes, whatever the image size, as long as only one length is defined, the SVG will grow or shrink to fit that length
maintaining the declared aspect ratio in the SVG.</p>
<p>These foreground images work perfectly in Opera and Internet Explorer 9+ (the versions found on mobile devices). In Chrome
and Safari, if you open the SVG file first, caching it, the HTML file
containing the foreground SVG image may work as well. </p>
<p> While we previously saw that the browser can indeed render the SVG, if the SVG is included in our document via the <code><img></code> tag, this specific type of SVG fails to render. </p>
<p>Why? To prevent cross-domain scripting attacks, most browsers have content security policies in place to keep SVG from importing media or scripts in case they're malicious in nature.</p>
<p>Blocking SVGs from importing scripts and
images does make sense: to prevent cross-domain scripting attacks you don't
want a file to be pulling in potentially malicious content. SVG is supported. In the case of WebKit and
FireFox, it is just being prevented from pulling
in external raster images. I submitted a <a
href="https://code.google.com/p/chromium/issues/detail?id=234082">Chrome bug
report</a> to get the ban on importing raster image in SVG lifted. </p>
<p>In Firefox, the responsive SVG also works on its own. Firefox fully supports SVG. However, for security reasons, Firefox blocks
the importing of external raster images, even if those images are same domain.
The rationale is if visitors are allowed to upload images, and the site
displays those images and scripts as part of an SVG, it's a security
risk. I would argue that if a site uses unsecure user generated content, they're already doing it wrong.</p>
<p>For right now the simple line:</p>
<pre><img src="awesomefile.svg" alt="responsive image"> </pre>
<p>is blocked in some browsers, and therefore isn't a
solution.</p>
<p>Browsers all support SVG media queries. They all support SVG as
foreground or content images. They all support SVG as background images. The
support just isn't all the same because of browser security policies. </p>
<p>All
browsers do support the <object> tag. Without making changes to the browser security policy, <img>
alone won't work. yet. We need to leverage the <object> tag.</p>
<h3>With <object> tag</h3>
<p>The <b> <object></b> element allows an
external resource to be treated as an image. <object> can take care of
the browser security drawbacks we see with <img> disallowing the
importing of images or script into an <img> file. <object> allows
both.</p>
<p>The code isn't that much more complex:</p>
<pre><object data="awesomefile.svg" type="image/svg+xml"></object></pre>
<p>By default, the <object> will be as wide as the parent
element. However, similar to images, we can declare a width or height with
the <code>width</code> and <code>height</code> attributes or with the CSS <code>width</code> and <code>height</code> properties.
For the Clown Car Technique to maintain the declared aspect ratio, simply declare just one length value.. </p>
<p>Because of the viewbox and preserveAspectRatio declarations in our
SVG file, the <object> will by default maintain the declared aspect
ratio. You can overwrite this with HTML or CSS attributes. </p>
<p>As noted earlier, the media queries in the SVG match the SVG's
container, not the viewport. The matched media queries in the SVG file will
reflect the parent of the <object> tag rather than the viewport.</p>
<p>If you take a look at an <a
href="https://estelle.github.io/clowncar/object/bgonly.html">SVG being pulled in
as the <object> data</a>, you'll see it works in all browsers that
support SVG.</p>
<h3>Fallback f or IE</h3>
<p>We have a few drawbacks with this method: </p>
<p><object> is supported in all browsers, even mobile browsers.
But this technique only works if the browser supports SVG as well. Therefore, it doesn't
work in IE8 and earlier or Android 2.3 and earlier. There is a fallback for these older browsers. Also, we have two http
requests to pull in the correct image: one for the svg file and one for the
raster image we want to show -- there is a solution for this too.</p>
<p>What makes the use of <object> more interesting than
<img> is <object> is a non-empty element. If you want, you can
include the <img> tag nested in the <object> for browsers that
don't support the data type. </p>
<p>For Internet Explorer <=8 (pun intended), we include our medium size raster
image as they're generally displayed on monitors at regular DPI, :</p>
<pre><object data="awesomefile.svg" type="image/svg+xml">
<img src="medium.png" alt="responsive image">
</object></pre>
<p>Unfortunately, content nested within the <code><object></code> is
downloaded even when the object is rendered and the nested content is not
needed or rendered. This adds a download of the medium image whether or not it is needed and used.</p>
<p>To handle this issue, we can use conditional comments for IE. </p>
<pre><object data="awesomefile.svg" type="image/svg+xml">
<!--[if lte IE 8]>
<img src="medium.png" alt="Fall back for IE">
<![endif]-->
</object></pre>
<h2>Single HTTP request</h2>
<p>We've narrowed the SVG to download a single raster image. The method we've being using downloads both the image and the SVG file. We have two http requests instead of one. To prevent an additional http requests, we can create a SVG
data URI instead of calling in an external SVG file.</p>
<pre><object data="data:image/svg+xml,<svg viewBox='0 0 300 329' preserveAspectRatio='xMidYMid meet' xmlns='https://www.w3.org/2000/svg'><title>Clown Car Technique</title><style>svg{background-size:100% 100%;background-repeat:no-repeat;}@media screen and (max-width: 400px){svg{background-image:url(images/small.png);}}@media screen and (min-width: 401px) and (max-width:700px){svg{ background-image:url(images/medium.png);}}@media screen and (min-width: 701px) and (max-width:1000px){svg{background-image:url(images/big.png);}}@media screen and (min-width:1001px){svg{background-image:url(images/huge.png);}}</style></svg>" type="image/svg+xml">
<!--[if lte IE 8]>
<img src="images/medium.png" alt="Fall back for IE">
<![endif]-->
</object></pre>
<p>The above looks messy, but it's simply <code>data:image/svg+xml,</code> followed by the contents of the SVG file, minified. </p>
<p>The above works in all browsers that support SVG except Internet
Explorer. While this is frustrating, it's actually because Internet Explorer is
trying to follow the specifications to the letter. The specifications state
that the data URI must be escaped. To make all the browsers, including IE9 and
IE10 support the data URI we escape it:</p>
<pre><object data="data:image/svg+xml,%3Csvg%20viewBox='0%200%20300%20329'%20preserveAspectRatio='xMidYMid%20meet'%20xmlns='https://www.w3.org/2000/svg'%3E%3Ctitle%3EClown%20Car%20Technique%3C/title%3E%3Cstyle%3Esvg%7Bbackground-size:100%25%20100%25;background-repeat:no-repeat;%7D@media%20screen%20and%20(max-width:400px)%7Bsvg%7Bbackground-image:url(images/small.png);%7D%7D@media%20screen%20and%20(min-width:401px)%7Bsvg%7Bbackground-image:url(images/medium.png);%7D%7D@media%20screen%20and%20(min-width:701px)%7Bsvg%7Bbackground-image:url(images/big.png);%7D%7D@media%20screen%20and%20(min-width:1001px)%7Bsvg%7Bbackground-image:url(images/huge.png);%7D%7D%3C/style%3E%3C/svg%3E"
type="image/svg+xml">
<!--[if lte IE 8]>
<img src="images/medium.png" alt="Fall back for IE">
<![endif]-->
</object></pre>
<p>It's ugly markup, but it works! <a
href="https://estelle.github.io/clowncar/singlerequest.html">https://estelle.github.io/clowncar/singlerequest.html</a> and <a href="https://estelle.github.io/clowncar/index2.html">https://estelle.github.io/clowncar/index2.html</a></p>
<p>Open the above links and open up the developer tools to inspect the http requests. You'll note 2 http
requests: the html file and the png the SVG pulls in. In the inspector, there will be an entry for the SVG file as well. But note no http request is being made: the status for the
SVG is "success" and the size over the network is 0 bytes, with the size of the data URI SVG coming in at under 600
bytes.</p>
<h2>Landscape versus Portrait</h2>
<p>Generally content images
are either landscape or portrait: faces are portrait, groups of people,
products and sunsets are landscape. Some people have a huge issue with the
Clown Car Technique because the image doesn't change based on orientation
change. This isn't necessarily true. </p>
<p>The magic of CCT is
the image rendered changes based on the size of the container. You can set your
landscape foreground image to 33% or 240px or whatever, and your portrait
object width to 25% or 180px or other. The object's size is determined in the
CSS of your HTML. The raster image served is based on the media queries that
match the object's size.</p>
<p>The aspect ratio remains
the same, but you can control which raster image is served by changing the proportions of your SVG container, matching the
media queries in your HTML's CSS with your media queries in your SVG's CSS.</p>
<h2>Other Benefits</h2>
<p>Another benefit of the Clown Car Technique is all
the logic remains in the SVG file. Similar to how we separate content from
presentation from behavior, this method enables us to also separate out image logic from our content. The <code><img></code> or <code><object></code> element is part of the content, but the logic that makes it all work is separate from the content layer: the logic is in the SVG image instead of polluting our CSS and HTML.</p>
<p>CCT will enable us to neatly organize our images, separating our behavior from presentation from content from images. I can envision a responsive images file
structure being something similar to </p>
<pre> images/
clowns/
small.png
medium.png
large.png
svg.svg
cars/
small.png
medium.png
large.png
svg.svg
techniques/
small.png
medium.png
large.png
svg.svg</pre>
<p>All of our assets for a single image live in a single, separate directory. The image file names can be a constant, with the folder name being variable. We can have responsive foreground
images without littering our HTML with extra, unused code, making image management and updating a breeze.</p>
<h3>Drawbacks of the Clown Car Technique</h3>
<p>Above are the pros of the technique. The technique is still nascent, so I haven't figured out what all the issues are. I am working on solutions to some of the issues that have been found, and assume new issues will arise. </p>
<p>I am mostly concerned with ways in which the Clown Car Technique fails to behave like regular PNGs, JPEGs are GIFs. The main issues I have noticed include load order, fall back for Android 2.3.3 and earlier, accessibility, and the ability to right click on the image.</p>
<h3>Page Layout</h3>
<p>According to John Wilkins, the Clown Car technique requires full CSS layout before the image starts to load. I have not had a chance to compare loading for regular foreground images versus <object> with SVG pulling in raster images, so can not comment on the impact of this issue yet.</p>
<h3>Android up to 2.3</h3>
<p>Android up to 2.3 does not support SVG. There are two possible solutions I have found that I have yet to flush out and test. </p>
<h4>Conditional Comments</h4>
<p>The first is to include the IE conditional commenting to include a medium size fallback for IE <=8, and a small size fall back for all browsers that ignore IE conditional comments (which includes IE10): </p>
<pre> <!--[if lte IE 8]>
<img src="images/medium.png" alt="Fall back for IE">
<![endif]--><br/> <!--[if !IE]> -->
<img src="images/small.png" alt="fallback"/>
<!-- <![endif]--></pre>
<p>The above fallback will show the small png to all Android phones. Unfortunately, this will download small.png for all browsers other than IE9 and older, even though the image is not shown. While we're trying to solve for old Android, we are downloading the small PNG to most devices unnecessarily.
<h4>JavaScript feature detection</h4>
<p>The other solution is feature detection with JavaScript. Test for SVG support. Include a <code>.no-svg</code> class on the <code><html></code> element if the browser doesn't support SVG. Using a webkit prefixed media query to occlude non-WebKit browsers, target:</p> <pre>
.no-svg object[type*="svg"] {
width: 300px;
height: 329px;
background-image: url(small.png);
}</pre>
<p>The above properties add dimension and background image to the <code><object></code> object. Again, I haven't tested this out yet, and it's not inaccessible. Which brings us to the next topic:
<h3>Accessibility</h3>
<p> The benefit of <code><img></code> is that the simple <code>alt</code> attribute can make it accessible. The <code><object></code> element does not have an <code>alt</code> attribute. Ideas to make Clown Car Technique images accessible include </p>
<ul><li>an alt attribute on the fallback images, </li>
<li>a <title> and <desc> in the SVG file</li>
<li> alternative text between the opening and closing <object> tags.</li>
<li>adding ARIA <code>role="img"</code> and other ARIA attributes like <code>aria-label</code> and <code>aria-labeled-by</code>.</li>
<li>including <code>tab-index</code> property to enable the <code><object></code> to get focus</li>
</ul>
<p> Again, I have yet to test this out, and am currently working on an <a href="https://estelle.github.io/clowncar/accessibiltytest.html">accessibility testing page</a>.</p><h3>Right-click to save</h3>
<p>In your desktop browser, when you right click on the image you get a menu enabling you to save the image. On phones, a lingering touch on an image may prompt a save. This does not work with <code><object></code> or with background images, which is what our SVG is made of. </p>
<p>This "drawback" may be a "feature" for sites wary of people 'stealing' their images. In the brief time that I have contemplated this issue, I have yet to come up with a native ways of resolving this issue. It is likely resolvable with JavaScript.</p>
<p>If the inability to right click to save is your main argument against this CCT, note while users can right-click on WebP images in browsers that support WebP (only Chrome and Opera), they can't do much with those images as native applications don't support this new format. This isn't preventing us from moving forward with this bandwidth saving technique.</p>
<h2>Why "Clown Car Technique"</h2>
<p>With naming help from <a href="https://dwmgbook.com/" title="Christopher
Schmitt: Designing Web and Mobile Graphics">Christopher
Schmitt</a> and <a href="https://precisemoves.com" "Redwood City Chiropractic">Amie Gregory</a>, I called it the Clown Car technique since we are including many
large images (clowns) into a tiny single SVG image file (car).</p>
<p>We need to use the non-semantic <code><object></code> element while we encourage browsers to support raster images in SVG as an <code><img></code> source either via CORS or CSP.</p>
<p>Clown Car Technique is a solution we can use now. Detractors argue <code><picture></code> and / or <code>srcset</code> are the solution without convincing me Clown Car Technique isn't the right solution. Some argue the drawback for the clown car technique is the lack of support in Android, forgetting that Android 2.3.3 and IE8 don't support <code><picture></code> or <code>srcset</code> either.
</div>
</p>
<p>While the <code><object></code> can theoretically be made accessible, I am not fully content using the <code><object></code> tag due to the lack of semantics and the non-accessible nature. Making it accessible is my next priority. While I would like to see this work with the simpler and more semantic <img> tag, once the accessibility issue is solved, this technique will be production worthy.</p>
</body>
</html>