{"id":85,"date":"2012-02-23T19:06:33","date_gmt":"2012-02-23T19:06:33","guid":{"rendered":"http:\/\/www.w3.org\/community\/respimg\/?p=85"},"modified":"2012-02-23T21:10:19","modified_gmt":"2012-02-23T21:10:19","slug":"picture-for-existing-browsers","status":"publish","type":"post","link":"https:\/\/www.w3.org\/community\/respimg\/2012\/02\/23\/picture-for-existing-browsers\/","title":{"rendered":"&lt;picture&gt; respecting conventions."},"content":{"rendered":"<p>After checking out the <a title=\"\" href=\"https:\/\/etherpad.mozilla.org\/responsive-assets\" target=\"_blank\" rel=\"nofollow\">etherpad with brainstorming<\/a>, asking <a title=\"\" href=\"http:\/\/www.w3.org\/community\/respimg\/2012\/02\/20\/14\/#comment-39\">some questions in this group<\/a> and seeing what <a title=\"\" href=\"http:\/\/www.w3.org\/community\/respimg\/2012\/02\/21\/a-sample-picture-implementation\/\">Scott has done<\/a> with the proposed markup using <code>&lt;picture&gt;<\/code> , I like the way we go. Now I clearly see the reasons why we can not re-use <code>&lt;img&gt;<\/code> . I see why some other proposed solutions don&#8217;t deliver what we need and how <code>&lt;picture&gt;<\/code> solution tries to solve some of those concerns.<\/p>\n<p>But today, after the <a title=\"\" href=\"http:\/\/www.w3.org\/community\/respimg\/2012\/02\/22\/right-click-save-image-as\/\">Matt&#8217;s post<\/a> I realized that there is something more we should keep in mind. There are certain ways people used to interact with the images on the web. There are certain conventions. Saving images to a user&#8217;s hard-drive, maybe referencing an image in a visual editor&#8217;s &#8220;Add Image&#8221; drawer to name a couple.<\/p>\n<p>I gave another though to the <code>&lt;picture&gt;<\/code> element on how we can deliver the responsiveness and, at the same time, let the conventions work still. Here is what I came up with:<\/p>\n<pre><code>&lt;picture&gt;\r\n    &lt;source query=\"(min-width:420px) and (max-width: 767px)\"&gt;\r\n        &lt;img src=\"http:\/\/dev.null\/small.jpg\" alt=\"Alternative text for capable browsers wider than 420 but narrower than 768px\" \/&gt;\r\n    &lt;\/source&gt;\r\n    &lt;source query=\"(min-width:768px)\"&gt;\r\n        &lt;img src=\"http:\/\/dev.null\/large.jpg\" alt=\"Alternative text for capable browsers wider than 768px\" \/&gt;\r\n    &lt;\/source&gt;\r\n    &lt;img src=\"http:\/\/dev.null\" alt=\"Alternative text for browsers not understanding CSS media queries or screens smaller than 420px\" \/&gt;\r\n&lt;\/picture&gt;<\/code><\/pre>\n<p>So, as in the original proposal, we have <code>&lt;img&gt;<\/code> fallback for the browsers not supporting CSS media queries. The same <code>&lt;img&gt;<\/code> fallback is used for capable browsers in case none of the media queries is true. We have a set of <code>&lt;source&gt;<\/code> elements to reference different versions of the image. The differece is that I intend <code>&lt;source&gt;<\/code> to contain real <code>&lt;img&gt;<\/code> tag. Any browser knows how to deal with it and it is clear for any user what to expect from it. Additional advantage is the flexibility we get in supplying more information than just an image for different media queries. For example a caption for an image or alike (though it starts smelling like <code>&lt;figure&gt;<\/code> already).<\/p>\n<h2>What I like about this solution.<\/h2>\n<ul>\n<li>This can be re-used for anything, not images only. If we decide to let wider usage of this pattern, we might just easily drop <code>&lt;picture&gt;<\/code> and leave those <code>&lt;source&gt;<\/code> elements with <code><em>query<\/em><\/code> attributes standalone. Imagine using this for different navigational elements depending on the screen size, supplying a screenshot instead of full-size video on the smaller screens and so on.<\/li>\n<li>No need to duplicate browsers&#8217; functionality reserved for <code>&lt;img&gt;<\/code> tag.<\/li>\n<li>Not breaking conventions users got used to when dealing with images on the web.<\/li>\n<\/ul>\n<h2>What I don&#8217;t like about this solution.<\/h2>\n<ul>\n<li>Duplication of the <code><em>alt<\/em><\/code> attribute for the images. Though it might be an advantage. You might need to supply completely different image for smaller screens (consider complex chart on a wide screen that is significantly simplified for the smaller ones) where <code><em>alt<\/em><\/code> text should be different for different screens.<\/li>\n<li>Mixing presentation with markup by using CSS media queries. Though, pretty much any solution we came up with until now had this flaw.<\/li>\n<li>Use of the new element ( <code>&lt;picture&gt;<\/code> ). But, as mentioned above, we can ditch it and leave standalone <code>&lt;source&gt;<\/code> elements instead. <code>&lt;source&gt;<\/code> is an existing tag. Though <code><em>query<\/em><\/code> attribute has to be implemented yet.<\/li>\n<li>Not very elegant markup.<\/li>\n<li>Maybe a little bit too much flexibility \u2014 some people can go nuts supplying different content for different resolutions. This can easily break usability of the sites.<\/li>\n<li><strong>UPDATE<\/strong> I don&#8217;t like that this doesn&#8217;t work in the browsers just now even if one tries to polyfill it.<br \/>\nBrowsers should implement a mechanism to not download an <code>&lt;img&gt;<\/code> if it is within <code>&lt;source&gt;<\/code><\/li>\n<li><strong>UPDATE<\/strong> This pattern is new and does not correspond to the existing usage of <code>&lt;source&gt;<\/code><\/li>\n<\/ul>\n<p>What do you think?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>After checking out the etherpad with brainstorming, asking some questions in this group and seeing what Scott has done with the proposed markup using &lt;picture&gt; , I like the way we go. Now I clearly see the reasons why we &hellip; <a href=\"https:\/\/www.w3.org\/community\/respimg\/2012\/02\/23\/picture-for-existing-browsers\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1288,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_s2mail":"yes","footnotes":""},"categories":[4],"tags":[13,12,11],"class_list":["post-85","post","type-post","status-publish","format-standard","hentry","category-responsive-web-design","tag-convention","tag-img","tag-picture"],"_links":{"self":[{"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/posts\/85","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/users\/1288"}],"replies":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/comments?post=85"}],"version-history":[{"count":11,"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/posts\/85\/revisions"}],"predecessor-version":[{"id":95,"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/posts\/85\/revisions\/95"}],"wp:attachment":[{"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/media?parent=85"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/categories?post=85"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.w3.org\/community\/respimg\/wp-json\/wp\/v2\/tags?post=85"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}