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

[Tab Atkins Jr.]

On Fri, Nov 15, 2013 at 2:39 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 15 Nov 2013, Tab Atkins Jr. wrote:
>> These examples... do not look good.
>
> I presume you mean that they don't look good in the <style> case, but
> actually, I don't know if that's accurate. Don't forget that in many cases
> the page will have multiple such images. You have to duplicated the img-*
> markup in each case. You only have to give the <style> block once.

Nope, you'll be duplicating per-image in both cases.

As I told Timothy, you *might* condense some things so that you don't
duplicate the @media declaration, but then you've separated the
sources from the <img>s, which has its own problems.

>> This is a subset of CSS, yes, but the line dividing "what you can use"
>> from "what you can't" is rather windy, rather than being clear-cut and
>> simple.  People will regularly get this wrong.
>
> That's a valid concern, I think.
>
> FWIW, my original thought in this direction (which I unsuccessfully tried
> to peddle in #whatwg) was to use a dedicated language rather than
> something backwards-compatible with CSS.
>
>
>> A further, and kinda killer, problem with this is that it *can't be
>> reasonably polyfilled*.
>
> The main idea of Adam's idea is it doesn't have to be, no?

Adam's idea (at least, the variant that uses <img>/content rather than
<div>/background-image) relies on abilities that older (and current)
browsers don't have, so it does need to be polyfilled.

Even if you use <div>/background-image, you lose the ability to
auto-size images (background images don't affect the size of the
element), and you still don't have a reasonable syntax for
variable-sized images, as those require additions to image-set().

~TJ