W3C home > Mailing lists > Public > public-respimg@w3.org > April 2015

Re: Picture Element Explanation.

From: Nathanael Jones <nathanael.jones@gmail.com>
Date: Tue, 7 Apr 2015 09:29:22 -0400
Message-ID: <CAG3DbfV7hGZq7LG_A+z49SnsD3hJZ8n25OwvnH=Y7cTbP1cL-w@mail.gmail.com>
To: Daniel Abril <daniel.abril@gmail.com>
Cc: Paul Deschamps <pdescham49@gmail.com>, "public-respimg@w3.org" <public-respimg@w3.org>
The picture element is about much more than resolution switching.

And some of this doesn't need to be discussed in the abstract; we have
actual implementations to measure and compare.

*If you want to use CSS MQ and only care about resolution switching, you
have other options*; you just need a CDN, server, or application that
supports RIAPI (of which there are many).

Slimmage.js uses your existing media queries in order to size your
foreground images.

* Is 2.37 KB compressed
* Full continuous unit and integration testing on 33+ browsers (99% most
popular, down to IE6) and gracefully falls back to <img> on the rest, or
when javascript is disabled. Works with screen readers and search engines.
Cookie free, works on first request, CDN compatible. No duplicate requests.
* Adds ~2ms per image in javascript execution time.  Can be inlined with
minimal required CSS into page, and executed prior to any *any* additional
requests. By default, however, it delays image loading until CSS is
downloaded. You control separation of content, script, and style.


I wrote Slimmage.js prior to the <picture> element and srcset becoming

*It is fast, but it is dependent upon CSS rules, which means that your
images load after the CSS.* Slimmage.js *can easily increase load time by
15-80ms*. If you have a slow RIAPI implementation, this can be *much*

Some RIAPI implementations can decode, scale, and encode a 40 megapixel
jpeg in 150ms, or an 4MP image in 25ms. Others are 10-20x slower. These
results are typically disk or varnish cached, so this only affects first
client performance, but it must be considered.

*A native browser implementation of Slimmage.js could eliminate 15-40ms of
javascript loading/execution time, but could do nothing about the CSS
dependency or server-side image generation times, which are the real
problem. *

*Vendors invest millions in shaving off 50ms. They're not going to
implement something that could theoretically increase page load time by 33%
on a bad satellite connection. They're still kicking themselves for
permitting CSS background images.*

-Nathanael Jones

On Tue, Apr 7, 2015 at 6:22 AM, Daniel Abril <daniel.abril@gmail.com> wrote:

> Hi Paul,
> aside of all the technical reasons that have been given, the most relevant
> reason you should not use MQ for responsive images is the one Tady Walsh
> pointed out: accessibility.
> *Images are not style*, *but content*, so they have to be accessible
> without CSS or JS and they need an *alt* attribute to be fully accessible
> and an HTML tag to be semantic. And by accessible I mean not only for
> disable people, but for Search Engines too. Do you think Google is going to
> index your design images, not even knowing what is in it?
> Also they start loading before the CSS images do, as a couple of mates
> said before, and they are part of the structure and the content, both at a
> time. There are to kinds of images, the one used for styling that should be
> loaded by CSS, as you said, and a content image, that illustrates the text
> and/or in some cases represents 80% of the whole content. *How can we
> pretend to control by CSS a CMS content? Thousands of images...* is not
> an option
> Me my self as a layout designer and UX, I'm not very happy with the actual
> solution, but I agree it must be a DOM based solution, not a CSS MQ.
> People here have been working a long time to get with this solution, *we
> should try to read and understand why is it like this, how it works and
> what does it pretends*. Then, maybe, we can bring a new solution if we
> are capable too, but what we can't do is to ask to those who have been
> selflessly working hard to develop and test a solution, to work for free
> just to demonstrate us, that their solution is not wrong, just because we
> don't have the knowledge to understand it by ourselves!!
> Hope you get the point.
> best regards,
> *Daniel Abril*
> UI/UX Designer & Semantics Lover
> On Mon, Mar 2, 2015 at 5:34 PM, Paul Deschamps <pdescham49@gmail.com>
> wrote:
>> Hi all I hope this message finds you well :)
>> I have some questions / concerns about this picture element; I imagine
>> that this is not the first time someone has called out this proposed
>> implementation.
>> Some background on myself (though I don't generally like to call out my
>> area's of expertise) however as this is my introductory email to the list
>> perhaps this is a case where it is valid to do so.
>> I've been developing in the web for some twenty plus years now; building
>> everything from small static sites for private business to large scale CMS
>> / GIS web applications since NCSA Mosaic was released.
>> I've watched HTML transform from the old days of blink tags and lovely
>> "site hit counters" to Tables for layout and all the other lovely mistakes
>> that were made back then including of course the "browser wars" when I ran
>> a small business
>> built on a custom built CMS that pre-dates  Wordpress or even PHP Nuke.
>> I've built 20-30 or so GIS cross browser web applications during these
>> "Browser wars" where IE 6 was the vain of my existence.
>> Beyond being a web developer my vocational training is actually in
>> Graphic Design - of which I've been working in photoshop / Illustrator
>> since it's inception. IMHO CSS and the power of it was revealed to me with
>> sites like : http://www.csszengarden.com/ in 2003 and it was sites like
>> these that caused a revolution for the web.
>> ...
>> But that's enough about myself. :)
>> My question is as follows:
>> I am a purist and strongly feel that any "Styling / Cosmetic" decisions
>> should reside within the CSS alone and HTML should only be the "construct"
>> containing structure only. The picture element feels like it's trying to
>> accomplish
>> something in the wrong place.
>> Would it not be a cleaner solution to simply have cross browser support
>> for "*content: url()*" instead? or perhaps there is something that I am
>> missing here I would love for someone to explain to me why this approach is
>> better than a CSS solution.
>> and please not dismiss it with a simple phrase.. show me your code.
>> Perhaps it is too late but I fear that the advent of this picture element
>> will be looked at in the future just as like "Tables for layout" did in the
>> past.
>> Your comments are encouraged and greatly welcomed.
>> My fiddle is here: http://jsfiddle.net/n935nznp and supported in chrome.
>> Cheers and all the best.
>> Paul Deschamps.
Received on Tuesday, 7 April 2015 13:30:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:16 UTC