Re: Picture Element Explanation.

Hi Paul,

I see a whole other issue than the double download issue you mention.
Editor experience.

In the real world, there's usually an editor that works with a website in
some sort of CMS. The content this editor produces is usually evaluated
server side, and renders a bunch of markup.

How would you successfully implement a pure responsive image CSS-solution,
in cases where images are content and not presentation? Especially in these
pre-processing times, this proves to be a challenge.
Art direction is a decisive factor I think.

Cheers,

Mads

On Thu, Mar 5, 2015 at 4:06 PM, Paul Deschamps <pdescham49@gmail.com> wrote:

> :) Thank you for your reply Jason,
>
> To be honest I am not really interested in a JS solution. As a purest I
> would prefer to have the markup completely free of any styling logic and
> rules. Clearly to have the HTML 100% separation from presentation would
> require to have the IMG tag fee of any src attributes at all and drive the
> ALL of the img resources requested from the CSS; That would be the cleanest
> solution - but as you stated "Welcome to the web" and yes I've been here
> for quite some time and I've also had the pleasure of watching it mature to
> what it is now from the 20 years ago when I started.
>
> Though that is all a pipe dream I recognize. But it was a dream long ago
> with sites like http://www.csszengarden.com/ and sadly this picture
> element breaks the concept entirely :(
>
> Paul.
>
>
>
>
>
> On Thu, Mar 5, 2015 at 9:54 AM, Jason Day <jbday@llbean.com> wrote:
>
>>  Hi Paul,
>>
>>
>>
>> I think it’s important to call out that you can address your concerns
>> with Javascript & CSS, but as Jason calls out, this standard was conceived
>> due to the limitations inherit in the technology.
>>
>>
>>
>> Welcome to the web. That isn’t meant to be snarky, but in that web
>> technologies provide the scaffolding which doesn’t address every use case
>> we throw at it. When you meet that limitation, you have other tools at your
>> disposal. I liken this to the dichotomy between CSS and preprocessors -
>> preprocessors add another dimension to CSS that isn’t available in the
>> spec.
>>
>>
>>
>> If you’re interested in a javascript solution, there are many out there,
>> but based on your dialog BBC News’ Imager might be a good solution:
>>
>> https://github.com/BBC-News/Imager.js/
>>
>>
>>
>>
>>
>> Jason Day
>>
>> User Experience Engineer
>>
>> jbday@llbean.com | 207.552.7084
>>
>>
>>
>> L.L.Bean
>>
>> 15 Casco Street | Freeport, Maine 04032
>>
>>
>>
>> *From:* Jason Grigsby [mailto:jason@cloudfour.com]
>> *Sent:* Thursday, March 05, 2015 9:39 AM
>> *To:* Paul Deschamps
>> *Cc:* public-respimg@w3.org
>> *Subject:* Re: Picture Element Explanation.
>>
>>
>>
>> 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
>>
>> [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> 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> 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>
>> 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 o | +1 (503) 502-7211 m | http://cloudfour.com
>>
>
>


-- 
*Mvh. Mads Østergaard*
Frontendudvikler

Telefon: +45 2255 8600

Web: *http://www.madsmads.dk <http://www.madsmads.dk>*
LinkedIn: /in/madsmadsdk/ <http://dk.linkedin.com/in/madsmadsdk/>