RE: Picture Element Explanation.

Hi Tommy,

Your approach & proposal is interesting, but I hesitate over using background images through CSS as full solution, as these images are not accessible. Removing them from the DOM completely, negates several benefits of having them in the HTML (SEO, accessibility, etc.).

How would you address that?

- Jason

From: Tommy Hodgins [mailto:tomhodgins@gmail.com]
Sent: Thursday, March 05, 2015 10:25 AM
To: Paul Deschamps
Cc: Tady Walsh; Jason Grigsby; public-respimg@w3.org
Subject: Re: Picture Element Explanation.

Hello Paul (and all)

I’ll take this moment to introduce myself since I haven’t written in yet, as well as propose a solution I already have working in every browser :) I have a solution that lets you set a CSS background image for a specific element based on the width or height of that element, and you can make it so CSS only loads back background image of the current width, and if you start resizing the page it THEN requests the other image and downloads it. It that what you’re looking for?

About me:

- Tinkering around with HTML since before: 2000 (Netscape Composer era, when IE was good)
- Had my own hosting, domains and sites online by: 2003 (pre-WordPress)
- Took Graphic Design in college from: 2006-2009 (around the release of the iPhone)
- Graphic design & web design work: 2009-2011 (WordPress, Joomla)
- Freelance front-end development, specializing in responsive: 2011-2015 (HTML, CSS)

I have similar concerns about the way the responsive images are implemented - it seems nobody can decide if this is a structural change to the page (HTML) or a cosmetic change (CSS). Personally, I believe swapping out image assets is the job of CSS, so I am very curious to see CSS add this ability :)

I build all my sites out of CSS, and only use images for photographic content. For that, I always supply it retina-ready for devices that support it, and let other browsers scale it down. The time I would take generating images at different sizes and adding responsive images support I just optimize that one retina-ready asset until it’s efficient to send out.

However, I am very interested in element queries, and enhancing CSS support! Here’s my proposed solution:

@element '#demo' and (min-width: 0px) and (max-width: 699px) {
  #demo {
    background: url('nebula.jpg');
  }
}

@element '#demo' and (min-width: 700px) {
  #demo {
    background: url('sm-magellanic-cloud.jpg');
  }
}

It works today, via polyfill. If you load the page and #demo is below 700px, it only loads in nebula.jpg, if you load the page and #demo is wider than 700px, is only loads sm-magellanic-cloud.jpg, and if you load it and resize it to both widths it will have pulled in both images.

Demo where you can test it out: http://staticresource.com/responsive-image.html


I hope this is an okay first contribution! I have plenty more element queries to share : )

Take care,
Tommy

On Mar 5, 2015, at 10:22 AM, Paul Deschamps <pdescham49@gmail.com<mailto:pdescham49@gmail.com>> wrote:

Hi Tady :)
I do understand that I am poking the bear so to speak on this and yes this solution is already in a few browsers so far so there is little to do to refine it's momentum currently. But are we not open to the possibilty of addressing the same solution in a couple different ways? The web is about options as well.

AND ALSO! Let's be honest here as responsive web development is relatively new in the grand scheme of things looking back. I am sure this isn't the last kick at the responsive can.
As far as accessibility goes more work needs to happen getting browser to support for the media types for “aural” and “braille” right? once that is fully supported the accessibility issues of this method would be resolved? would they not?
Can you imagine what designers would be able to do with the web if there was 100% separation from Markup -> CSS You would see a suite of tools for them to work with the imagery itself outside of any markup.
Anyhow again a dream..
Thank you for your reply.
Paul.



On Thu, Mar 5, 2015 at 10:03 AM, Tady Walsh <tadywalsh@gmail.com<mailto:tadywalsh@gmail.com>> wrote:

Hi Paul,

These are very interesting (if uncomfortable :D ) questions you are raising. Can I ask you what the accessibility implications are for the CSS method?

Cheers,

Tady
http://tady.me<http://tady.me/>
@tadywankenobi<https://twitter.com/tadywankenobi>


On 5 Mar 2015, at 15:56, Paul Deschamps <pdescham49@gmail.com<mailto:pdescham49@gmail.com>> wrote:

Thanks Jason.
What I am looking for here is a sound code example that compare's and contrast's the two methods. However I do appreciate your reply! That was if you recall my initial request.
If performance is the main concern in lieu of breaking the separation of presentation from content then let's look at that. What are the measurable gains here? Show me the code.
If it comes down to the double download issue Chrome currently supports a CSS only solution replacing the IMG src so the Double download doesn't exist there. Would it not be better to focus on that kind of a solution for the other browsers? Clearly someone else is in agreement with me here as it's already supported in Chrome.
- No SRC specified Chrome responsive technique negates the double download
http://jsfiddle.net/n935nznp/3/

- The same code showing the double download issue
http://jsfiddle.net/mv3squpn/1/


I've read the use cases some time ago; I can see very little here that is already not supported in a css media-query solution. The "only" argument for the picture element I can see is for this double download.
Cheers!
Paul.


On Thu, Mar 5, 2015 at 9:38 AM, Jason Grigsby <jason@cloudfour.com<mailto:jason@cloudfour.com>> wrote:

HI Paul,

Both Yoav and Bruce answered your main question well. The preloader downloads images long before css and js are ready. Bruce's article is excellent.

To your point of separation of presentation from content, I don't think there is a single person in this group who doesn't share your concern.

The constraints of the preloader, the use cases that responsive images need to support[1], and the fact that images on the web are fundamentally more complex than they seem at first glance led us to the current standard.

The standard wasn't created haphazardly. It took nearly four years to come up with a solution that people could agree on given the constraints we're working with.

As with anything in life, it is possible we missed some amazing solution. I'm not saying it is perfect. I would never claim that.

But what I am saying is that other possible solutions need to address the full set of constraints and use cases. So if you're interested in working on that, I recommend starting with reading up on the use cases and learning about how the preloader works and why it is important[2].

In the meantime, responsive images is part of the living HTML standard. It has shipped in Chrome and Opera. It will land in Firefox 38. We've been working on this for a long time, and we're excited to finally get responsive image solutions, imperfect as they are, in the hands of designers and developers who have been clamoring for them.

-Jason


[1] http://usecases.responsiveimages.org<http://usecases.responsiveimages.org/>
[2] http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/


On Thu, Mar 5, 2015 at 5:16 AM, Bruce Lawson <brucel@opera.com<mailto:brucel@opera.com>> wrote:
It's probably illegal to self-link, but I get asked similar questions
a lot at conferences, so wrote up "Why we can’t do real responsive
images with CSS or JavaScript"
http://www.brucelawson.co.uk/2015/why-we-cant-do-real-responsive-images-with-css-or-javascript/


bruce

On 5 March 2015 at 12:39, Yoav Weiss <yoav@yoav.ws<mailto:yoav@yoav.ws>> wrote:
> The problems with a CSS based solution such as this are:
> * It incurs a non-trivial performance regression, since the browser now has
> to wait for all CSS to come in and for layout (or style calc at the very
> least) to take place before it can start downloading the required images.
> * You leave the browser zero wiggling room for further optimizations in
> "resolution switching" case, in case the user prefers smaller images, is on
> a bas connection, etc.
> * You cannot have a reasonable fallback here without incurring a double
> download in *supporting* browsers, from now on, forever and ever.
>
>
> On Mon, Mar 2, 2015 at 5:34 PM, Paul Deschamps <pdescham49@gmail.com<mailto: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.
>>
>



--
+1 (503) 290-1090<tel:%2B1%20%28503%29%20290-1090> o | +1 (503) 502-7211<tel:%2B1%20%28503%29%20502-7211> m | http://cloudfour.com<http://cloudfour.com/>