- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 15 Nov 2013 08:20:39 -0800
- To: Yoav Weiss <yoav@yoav.ws>
- Cc: Markus Ernst <derernst@gmx.ch>, "Tab Atkins Jr." <jackalmage@gmail.com>, Ryosuke Niwa <rniwa@apple.com>, whatwg <whatwg@lists.whatwg.org>, "Jukka K. Korpela" <jkorpela@cs.tut.fi>, Markus Lanthaler <markus.lanthaler@gmx.net>
On Fri, Nov 15, 2013 at 1:55 AM, Yoav Weiss <yoav@yoav.ws> wrote: >> On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak <mjs@apple.com> wrote: >>> Content authors can already do what is described above, and in fact often >>> do. However, a <div> with a background-image property set is not the same as >>> an <img> in practice. Here are a few differences: >>> >>> (1) There's no ready way to have an element size automatically to its >>> background-image (the way an <img> will to its src by default). >>> >>> (2) In general, browsers will not provide the same user interaction >>> operations for a background image as for a content image in an <img> element >>> (e.g. ability to drag it elsewhere, context menu items to save it, etc). >>> >>> (3) Assistive technologies will ignore background image holding divs for >>> which no textual equivalent has been provided (as opposed to <img>, where >>> they do something like reading the filename, or just indicate the presence >>> of an image without labeling it). >>> >>> (4) Software that processes content to look for images may treat content >>> images in <img> differently from images specified as backgrounds, for >>> instance by assuming background images are decorative and therefore less >>> meaningful and/or less related to search terms in text on the page. >>> >>> Some of the above may be addressable by using the 'content' property >>> instead of the 'background-image' property, though using 'content' on an >>> element as opposed to a :before or :after pseudo does not work reliably >>> cross-browser. >> >> I agree with Maceij's concerns here. >> I also think that writing inline CSS will be cumbersome in a CSP world. >> Hashes will make it easier for "static" inline CSS, but if we're going to >> write down frequently-changing, content images' resources in inline CSS, >> that'd be a lot of hash calculations. A build step can help, but it's a >> downside of this approach. > > Can any proponent of the inline-style based methods address the concerns > Maciej and myself have raised? My apologies. I thought Christian Biesinger addressed all these concerns with his proposal: On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger <cbiesinger@google.com> wrote: > For a bit more presentation, and while we're inventing new syntax > anyway, how about this: > > <style> > @media (min-width: 480px) { > .artdirected { content: replaced url(attr(src-small)); } > } > @media (min-width: 600px) { > .artdirected { content: replaced url(attr(src-medium)); } > } > @media (min-width: 800px) { > .artdirected { content: replaced url(attr(src-big)); } > } > </style> > ... > <img class="artdirected" src="foo.jpg" src-small="foo-small.jpg" > src-medium="foo-medium.jpg" src-big="foo-big.jpg"> Specifically, his approach uses an <img> element, which addresses all four of Maciej's concerns. Adam
Received on Friday, 15 November 2013 16:21:42 UTC