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

On Tue, Nov 12, 2013 at 10:17 AM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> On Tuesday, November 12, 2013 6:50 PM, Adam Barth 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>
>>
>> All the information is there.
>
> Except if there are other, external stylesheets that might overwrite these
> definitions

The preloader is just heuristic.  There are many cases where it loads
resources that aren't needed by the page.

>> We just need to teach the preload
>> scanner to parse a subset of CSS and match a subset of selectors.  If
>> you stay within the "preloadable" subset, then your images will be
>> loaded by the preload scanner.  Otherwise, they'll just be loaded
>> normally.
>>
>> 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.
>
> I see a number of other problems with this approach as well. E.g., how would
> this work for videos?

That sounds like a separate problem that we can solve separately.
Neither srcset nor src-N nor <picture> address videos.

> What about browsers not supporting media queries (or
> CSS for that matter)?

The web site will likely need to do something different to support
those browsers.  That's likely the case already if the web site wants
to support browsers that don't implement CSS.

> With this solution you need to replace all img tags
> with meaningless divs. Right clicking to save an image would break as well.

It's extremely common practice to use background-image to supply
images today.  Perhaps we should solve the
right-click-to-save-a-CSS-background-image problem in a way that works
for all these uses.

On Tue, Nov 12, 2013 at 10:23 AM, matmarquis.com <mat@matmarquis.com> wrote:
> This is possible using a set of proposals already underway, last I checked in on them: http://nicolasgallagher.com/responsive-images-using-css3/ Considering the delay involved in skipping the preparser and waiting for CSS to download (as well as the fact that the `src` *will* be prefetched, resulting in a double-request), this really leaves us in the same position as any number of script-based solutions—we’re just creating a responsive images “engine” in CSS, rather than in JavaScript or inside an SVG.

Please read my proposal.  I'm suggesting that we teach the preload
scanner how to understand a subset of CSS large enough to cover these
use cases.  It doesn't involve any futuristic CSS technology.  It just
requires adding smarts to existing implementations of existing
standards.  You point about prefetching the src attribute is also
incorrect because there is no src attribute in my proposal.  Fallback
isn't handled by src.  It's handled by CSS.

> This subject has come up a number of times on the respimg list, and it always plays out largely the same way: an optimization like this would be beneficial for sure (and I’m in favor of one myself), but in this context we’re looking at creating an entire variable syntax specific to images.

My proposal did not include any new syntax.  Please read my proposal
before trying to shoot it down.  :)

> Obviously there’s a huge amount of implementation overhead involved in something like this, and making it a requirement in any proposal would create a *huge* barrier to implementation vs. getting a simple *extendable* markup pattern in place and building on that. Once we have a solution in place for responsive images, it makes sense that it would become a consideration in larger discussions such as http://lists.w3.org/Archives/Public/www-style/2013May/0638.html

Given that I'm an implementor and you don't appear to be an
implementor, I'd like to ask you to believe me when I say that my
proposal is a smaller implementation burden than <picture> or src-N.

> We don’t want the search for the all-time-perfect responsive image solution to stand in the way of setting up the foundation for one, and we definitely don’t want to create a set of solutions to larger problems that can only ever apply to image sources.

My proposal doesn't involve inventing anything.  It's just a proposal
to optimize a subset of CSS.  These optimizations will benefit folks
interested in responsive images.  They will also benefit existing
content that happens to fall into the subset without caring about
responsive images.

Adam

Received on Tuesday, 12 November 2013 18:40:57 UTC