Re: Picture Element Explanation.

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.

https://github.com/imazen/slimmage

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

*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*
longer.

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.
>>
>>
>