Skip to toolbar

Community & Business Groups

Move on!

As of today we now seem do have discussed nearly every different angle of responsive images with its problems.

We recently figured out that

Then we have the second important point we recently figured out: A responsive file-format. This is what people think would be a great approach to work with responsive images. Unfortunately this is not easy and it is not our primary goal that we care about this. Nevertheless I would like to see some people pinging the right people (e.g. WebP-team) so they might be aware of the problem.

So we have all this solutions and thoughts written and discussed. When we have discussed and solved the outstanding issues, we need to start writing a specification for our picture-element I think.
If I have not missed a very important point here, let’s do this.

And don’t hesitate to maintain our Wiki please. This is the place where all our summarizing thoughts should be – not here in this blog-system.

18 Responses to Move on!

  • The only point that I feel is vitally important, but I think is being seen as a “phase two” aspect, is the efficiency of authoring problem.

    I’ve got no other objections and I’m happy to see Picture go ahead, but I will not use it in production until there’s a way to centralise and abstract the media queries that trigger the break points in each picture element. So I’d love to see discussion about that, whether now or after the current proposal is “shipped”.

    Here’s a video I did a while back explaining my issues with picture in this regard: (relevant point starts at 44min 22sec), and my first stab at how we might go about fixing it:


  • Aaron Gustafson

    Yeah, I’m with Matt here. We do need a more efficient way of managing breakpoints.

    It would also be great if we could float the notion of accessing the Network Information API via media queries. That would help with determining whether it is advisable to load high resolution images for high density displays as opposed to simply telling us—simply—that we can.


    • Anselm Hannemann

      Aaron, that is totally true. Can we discuss this in separate posts? I would really love to see network information API and a tpl-way for breakpoints in the spec. Let’s figure out how this could work.


    • I’ve floated that idea before, though I can’t remember whether it was here or in one of the W3C mailing lists. Didn’t get much response.


      • Anselm Hannemann

        I think it was only mentioned in a comment on another topic here in group. I am totally voting for your approach and if no one else can say something against it, we should implement it to the spec.
        Or do you need more feedback?


        • I don’t really know what we want or need to get a bit more traction to be honest. Or how to go about implementing it into the spec – anyone have any idea’s how to do that?

          There seems to have been a die-off in this group and the people who were leading it seem to have vanished. If the job is to report back to the W3C with a realistic well thought out proposal; who’s doing that and managing this process?


          • Anselm Hannemann

            As far as I understand we’re now only a community group and we need a working group now with maximum of 15 participants. Within that we should be able to write a first draft of the spec.
            But I am not entirely sure about this…

  • I’m convinced that for bandwidth-related and screen-density-related breakpoints having UA make the decision is the right solution.

    Authors shouldn’t be repeating and re-inventing the obvious over and over again.

    The need to “centralize” media queries just proves they’re unoriginal repetitive boilerplate. UA needs to have this code.


    • But the author also needs to be able to adapt explicitly.

      The UA offers fully automated selection, which is good to a point. We still need semi-automatic (as in centralised media queries), and we still need full manual (the existing picture tag).

      They all do slightly different things in slightly different ways, no author will thank you for taking control out of his hands entirely, and no author will thank you for making them do all of the work all of the time.


    • Anselm Hannemann

      One thing is that a browser should be able to determine bandwidth. This is what Opera already does with Opera Speed. But the other thing is that a developer should be able to define how the browser should handle specific elements when he detects the bandwidth. And that is why we need this in our element.
      The same for MQ tpls.


  • The picture element should have the option to control breakpoints in the markup and/or in CSS, but preferably in CSS. Manually writing breakpoints and exact filenames for every element is the equivalent of using inline CSS throughout a site. If the picture element became the standard then sloppy code would commonly have copy/paste mistakes by forgetting to replace values.

    Also, we shouldn’t believe that our only option is to centralize media queries (-webkit-image-set() CSS is already being worked on for background-images: If authors get accustomed to using image-set for background images, they should use the same syntax for content images.

    Modifying image-set() to work with content images would drastically cut down on markup and centralize HOW files can be found, not WHAT files should be loaded.

    Options should stay open to put exact filenames and breakpoints within the markup, but ideally this task should be left to declarative CSS.


  • Dylan Pitchford

    I think i’m going to have to disagree with the statement “every different angle of responsive images with its problems”.

    I’m sure that a lot of angles have been *brought up*, but a discussion on each, this has not happened. There may have been some back and forth but to truly have a discussion on each angle one would think there would multiple proposals aside from the current picture element.

    Personally I don’t think picture element is at a stage where it’s garnered the approval of most of the community, and have read about thoughts and ideas not covered already, which are much smarter solutions to this issue.
    Granted most of these ideas are brought up within comments to other posts, on different blogs etc. and are generally stated *off the cuff*, but good ideas should never be brushed aside because *there is already consensus on a new element*. (i’ll try to compile some ideas i’ve read about and post, should have been doing it already)
    I’ve also noticed the longer people are sitting with ‘picture’, the more people are agreeing it is not the solution.

    Within my dev circle(s), which includes Content managers and producers at large media organizations, the consensus is the *hope* that the new picture element is *not* approved. It’s a maintenance nightmare waiting to happen, bloated markup, less cost effective, and the fact it’s based on the video/audio elements does not give me confidence. Why base something new on something old, which has issues? Not the smartest play in my books and is only asking for issues down the line. It’s easier as the work’s already been done on those elements? Wrong answer.
    I also have not heard anything about the business costs of ‘picture’, purely from a bottom line perspective. I can outline some of those if people are willing.

    An analogy if you please…
    There is a boat.

    The boat currently has a hole in it and we as a community have been trying to plug this hole in various fashions over the last little while, none of which has worked 100%. These are currently set up as stop gap measures to ensure we won’t get our feet too wet as we’re bailing out the water that’s already accumulated.

    There has been a proposal for a patch to plug the hole and stop the water (and even a working prototype), which is great. Unfortunately this prototype is time consuming to implement, not user friendly, cumbersome and has flaws, but it’ll do the job – it’s based on a working plug already built so it can’t be all bad right?
    The fisherman who originally bought this plug from a well respected Yachting company loved it at first but has now figured out it didn’t quite work and his boat has been taking on water, as a trickle ever since. He’s frustrated because he’s locked in and can’t upgrade to a new plug because the installation part of this plug is permanent. There may be patches to this plug down the line but as of right now he’s stuck.

    Unfortunately there isn’t a lot of talk about rowing back to shore, taking the boat out of the water and patching the hole properly.

    There has been some murmuring at one end of the boat about this, but they haven’t really been heard and are being passed off as overcomplicating things. Why do all that work when we have a patch right here ready to go?!! We’ve already done all this work, why throw all that away?
    There is a multitude of reasons why the prototype should be smashed with a hammer and the plans filed away as not good enough.
    Granted it’s time consuming to row all the way back to shore, source out materials, get into a garage, on a lift etc. but what’s the alternative? Spending just as much time, energy and resources (if not more) trying to plug the hole with a *fix* rather than a solution?

    In my experience it’s always best to row back to shore and pull the boat out of the water. Despite the drawbacks in the end you’ll have a boat you never have to worry about getting you feet wet in again.

    Personally i’m not ready to “Move on”, and I don’t think everyone else is yet either.

    *end my opinion.


    • Here’s the thing I keep going back to when thinking about this:

      Currently, most CMSes (CMSii? CMS’s?) are built to produce dynamic content on the HTML side, but not the CSS side.

      Using a CSS based solution then forces a shift in that paradigm to having to now make your CSS (or at least pieces of it) also be dynamic.

      This has many consequences beyond just ‘it makes it harder’. It then either becomes impossible to CDN your CSS (if you use dynamic CSS for your whole file to limit requests) or you add another request and generation/process cycle.

      Maybe the actual answer is: both.

      We use the element to handle images inside of dynamic HTML content, used mainly by CMS driven sites. And then we have the css based image-set (or another solution) for layout based responsive images.

      This solves the issue on many fronts, as it relieves the additional technical considerations and complications for pre-built CMSs, but enables the vast majority of responsive pieces to be handled in the CSS, where they rightfully belong.

      In my mind, it makes perfect sense for the header image to be controlled by an image-set or something in the CSS (please not with conditional backgrounds, that’s just wrong on so many levels), while the photo of a pineapple I use to make an example of something would be done in a element because that would be easily encapsulated within the content part of the CMS.

      It also feels more semantically correct to me, as then anything consuming only that content only has to consume the content, as opposed to grabbing and consuming related CSS files to make sure there’s no surprises there.


Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.