W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)

From: Yoav Weiss <yoav@yoav.ws>
Date: Fri, 15 Nov 2013 09:55:24 +0000
Message-ID: <CACj=BEhD_6nQM7D5M1WJx9dw0gO7rwbE5YnhxzKedPcN=WQ8Ww@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
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 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?
Received on Friday, 15 November 2013 09:55:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC