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

> Message: 9
> Date: Tue, 12 Nov 2013 10:54:54 -0800
> From: Adam Barth <w3c@adambarth.com>
> To: John Mellor <johnme@google.com>
> Cc: "Jukka K. Korpela" <jkorpela@cs.tut.fi>, Markus Ernst
>         <derernst@gmx.ch>,      whatwg <whatwg@lists.whatwg.org>,
> Markus Lanthaler
>         <markus.lanthaler@gmx.net>, Ryosuke Niwa <rniwa@apple.com>
> Subject: Re: [whatwg] <imgset> responsive imgs proposition (Re: The
>         src-N   proposal)
> Message-ID:
>         <
> CAJE5ia_PzcEU9PrvAXfY--PqBqjH1t7+kFcAw9Fuvmk7mfrCtQ@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Nov 12, 2013 at 10:45 AM, John Mellor <johnme@google.com> wrote:
> > On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth <w3c@adambarth.com> wrote:
> >> We might even be able to make this work without inventing anything:
> >>
> >> <style type="text/css">
> >> @media (min-width: 480px) {
> >>   .artdirected {
> >>     width: 30px;
> >>     height: 30px;
> >>     background-image: image-set(url(small.png) 1x, url(small-hires.png)
> >> 2x);
> >>  }
> >> }
> >> @media (min-width: 600px) {
> >>   .artdirected {
> >>     width: 60px;
> >>     height: 60px;
> >>     background-image: image-set(url(large.png) 1x, url(large-hires.png)
> >> 2x);
> >>  }
> >> }
> >> </style>
> >> <div class="artdirected"></div>
> >
> >
> > Three downsides to that:
> > - Doesn't address viewport-switching (variable-sized images), though we
> may
> > be able to fix that by extending image-set to support src-N's
> > <viewport-urls> syntax.
>
> Why doesn't it support variable-sized images?  In example above, one
> of the cases is 30x30 and the other is 60x60.  Maybe I've
> misunderstood what you mean by variable-sized images?
>
> > - Requires you to know the intrinsic aspect ratio of the images in
> advance.
>
> That seems like something we should improve about CSS more generally.
>
> > - Slightly less semantic (can't include an alt attribute, etc).
> > - Most sites will end up just referencing all their images by #id, which
> is
> > fairly icky. Since we're inlining the presentation into the content
> anyway,
> > may as well inline it next to the relevant bit of the content.
>
> These seem like minor concerns compared to the cost of inventing new
> HTML elements, attribute, and semantics.
>

I suggest that not being able to provide an associated text alternative for
an image via a simple method is not a 'minor concern' for some.



>
> > On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth <w3c@adambarth.com> wrote:
> >> What's most attractive to me about this approach is that it doesn't
> >> require inventing anything new, which means the compatibility story
> >> for older user agents is solid.  You don't need a polyfill or anything
> >> like that.
> >
> > Except that most user agents don't support image-set yet (only Chrome and
> > Safari 6+ IIRC).
>
> No user agents support src-N or <picture>, so we're already ahead of
> the game.  :)
>
> > If we did want to split src-N up to separate presentation from content,
> > you'd probably want to put the <size-viewport-list> and <media-query>s
> into
> > inline CSS, and leave just the <size-based-urls> (which are pure
> content) in
> > the HTML. Then you'd end up with something like the following.
> >
> > If you just have viewport-switching (and dpr-switching), it'd be:
> >
> > <style>
> > .photo {
> >     image-width: 100%;
> > }
> > </style>
> >
> > <img class="photo" srcs="160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
> > 1280, 2560.jpg 2560">
> >
> > (and as in src-N, you could use more complicated <size-viewport-list>
> > expressions like "100% (30em) 50% (50em) 33%" if the image width is a
> > non-linear function of viewport width)
> >
> > If you just have dpr-switching (fixed-width images), it'd be:
> >
> > <style>
> > .photo {
> >     image-width: 128px;
> > }
> > </style>
> >
> > <img class="photo" srcs="64.jpg 64, 128.jpg 128, 256.jpg 256">
> >
> > (where the ratio between the widths of the available images, and the
> > image-width from CSS, is used to calculate the density of each available
> > image)
> >
> > If you have art direction and dpr-switching, it'd be:
> >
> > <style>
> > .photo {
> >     image-width: "small" 128px;
> > }
> > @media (min-width: 20em) {
> > .photo {
> >     image-width: "big" 400px;
> > }
> > }
> > </style>
> >
> > <img class="photo"
> >      srcs-small="s64.jpg 64, s128.jpg 128, s256.jpg 256"
> >      srcs-big="b200.jpg 200, b400.jpg 400, b800.jpg 800">
> >
> > (here the author has assigned names to each of their art direction cases
> > [optional if you only have one case], and provides an alternate list of
> > image srcs for each case)
> >
> > This actually looks pretty reasonable (and unlike earlier proposals in
> this
> > thread, covers all use cases). One nice benefit over src-N is that the
> > <size-viewport-list> -- i.e. "128px" or "100%" or "100% (30em) 50% (50em)
> > 33%" -- doesn't get repeated for every image, if there are several images
> > with the same relationship between viewport size and image size.
>
> These proposals all invent new syntax and semantics.  I'd much rather
> start with an approach that doesn't introduce new syntax or semantics
> and just makes the web faster by optimizing existing content.
>
> > My main concern is that authors won't realise that the CSS must be
> inlined;
> > I'm not sure how to make that foolproof.
>
> We'll have to write tutorials and the like.  All these proposals have
> a developer education component.  Developers won't magically know how
> to use src-N either.
>
> Adam
>
>
> ------------------------------
>
> _______________________________________________
> whatwg mailing list
> whatwg@lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
>
>
> End of whatwg Digest, Vol 116, Issue 18
> ***************************************
>

Received on Tuesday, 12 November 2013 19:26:56 UTC