Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

Jason Grigsby wrote:
> David Goss wrote:
>> A common sentiment here seems to be that the two proposed responsive
>> image solutions solve two different use cases:
> 
> After skyping with Mat (@wilto) last night, I think I may be the only
> one who didn’t fully grok that the mediaqueries in <picture> could be
> used to address both use cases. 
>
> It is still unclear to me if <img srcset> would address both.

Oh but they *do* solve two different use cases. Mediaqueries in
<picture> _may_ be able to address both, but <img srcset> is not, and
never will. It's simply not designed for it.

So, why then do I prefer srcset when it comes to solving the «save
bandwidth»/use correct "weight" of resource use case?


Because it's design is "browser choose" instead of "web author choose".
It puts these decisions into the browsers control.  The easiest path for
the developers, is also what will make the browser be able to be a good
agent to its user, and decide what it shall download.

The srcset attribute is also much simpler, which makes me think it'll
be used more and also in the correct way. There's strong correlation
between simple and much used.

<picture> for solving this use case is/will be over engineered, just
because it can be done, doesn't mean it should. For the other use case,
adapting the image for different content, it might be a good candidate
though. <source> inside <picture> should also get a srcset attribute
then, so that it would be possible to choose different qualities if
they exist. For relatively advanced sites, it will look like a monster
though, so that's something to be looked more into.


David Goss wrote:
> Connection speed
> As an extension of the iPad example above, it would also be
> irresponsible to serve the high res image to users that do have a high
> pixel density display but are not on a fast internet connection for
> whatever reason. So you might write:
> <picture alt="The new iPad">
> <source src="lores.jpg">
> <source src="hires.jpg" media="(min-resolution: 300dpi) and
> (min-connection-speed: 1mbps)">
> <img src="lores.jpg" alt="The new iPad">
> </picture>

As I said, this is one of my big gripes with this proposal. I don't
think this'll work satisfactorily, it puts the burden on figuring out
what is correct for that user into the page author's control. That model
skews the responsibility so that instead of only a few browser engines
having to get it right, millions of web page authors have to get it
right.

AND they have to update their sites and mediaqueries when we get
something new to optimize for. I don't think they will do that, based on
how extremely big the problem with -webkit-prefixes are.

I've seen enough of the web to be sceptical.


What if a the author doesn't write that min-connection-speed query
there? And who is the author of a page to decide such things anyway?
What about latency?  Should there be a max-latency: 10ms, there as well?
What about cost? I have a fast line, but it costs money to download
stuff, so I'd like the smaller pictures. What about if I have slow
internet connection, but I'd want to print the page, thus getting the
best version of the image? Or if I'm sitting with my new fancy hires KDE
Tablet and loading your page in a background-tab, letting it render and
be finished while I continue to read the page I'm on (the browser might
very well want to load the highres picture then, even though the
connection is slow, but with MQ, not that lucky).

> (... containing element width/height)
> As I understand it, the <img srcset> syntax would have to keep getting
> extended every time we wanted to test a different property.

No. It wouldn't, because it only describes the images, nothing more.

Given:

  <img src="hero.jpg"
        srcset="hero.jpg 800w 400h, hero-lo.jpg 200w 100h, hero-hi.jpg 2x">

Say if you're in a browser optimizing for low bandwidth usage, and some
quality at the cost of speed.  The viewport is 800x600.  In the normal
case, the browser would choose hero.jpg because it fits well with its
resource algorithm. However, since being in the special mode, it defers
the prefetch of the image and waits for layout, where it can see that
this picture lies inside a 150px wide box - so it fetches hero-lo.jpg
because it doesn't need more.

With the MediaQueries proposal, you'd need loads of advanced information
to do the same. The browser could not just infer this on its own and
change its algorithms to do it.

Bandwidth might be expensive even though it's fast, so althought they
have over 1mbit speed, they want to get low pictures. With media queries
there's just so many variables, and so much to choose from.


srcset only chooses between different *qualities* of the same image
whereas who knows what mediaqueries does? It's not possible to not do
anything the web page author hasn't told you about. That's why srcset is
so much more powerful for its use case.


The browser is in a better position to decide what quality of image it'd
like to fetch.

The content author, however, is in a better position to lay out the
different content images based on their set of mediaqueries. I can see
a few use cases there, but they are orthogonal to what we're talking
about here.  I think it's something worth solving, but doing it
inside srcset is not where.

-- 
Odin Hørthe Omdal (odinho/Velmont), Core, Opera Software

Received on Sunday, 13 May 2012 13:42:43 UTC