> > > > On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak <[email protected]> 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?
