Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First draft of HTML img srcset for responsive images

whatwg.org

Post reply on HN
Print view View original

41–50 of 79 posts

Re: First draft of HTML img srcset for responsive images

#41

Post by ZenPsycho »

woodall wrote: post #38
ZenPsycho wrote: post #37

Or, here's just a crazy out there thought. What if we save our images in high res progressive format, and program the browsers to stop downloading the images as soon as they've acquired enough resolution? Caching can be done with http range requests. Older user agents just end up downloading larger images than they wanted. Javascript and server script can use the JPEGtran library to retrieve lossless low res versions…

Is there a way this can take place entirely server side?

sure, it would be simple enough to copy what was done with the server side image maps thing, and define some query parameters that get requested along with the image. So each different size gets its own url and proxies and caches are happy. servers that don't support it just serve a normal image. a tiny bit of javascript can polyfill it in now. today.

Re: First draft of HTML img srcset for responsive images

#42

Post by mcobrien »

ZenPsycho wrote: post #27

This is silly and makes things way more complicated than they need to be. We have HTML tags, to which we can apply attributes directly via blah=blah syntax Or we can add attributes by making a style attribute, and using css syntax inside of it. Or we can have a space separated list of class names, and have attributes applied to an element externally by a CSS stylesheet. Or we can have an ID, and apply attributes usin…

Using CSS means you have to specify image locations in two places, with potentially different base URLs.

Using Javascript means you have to load scripts before the img tag, which can hurt performance.

Using http headers or a special URL format makes working with CDNs more difficult.

This is actually a tricky problem to solve and it looks like the authors have considered some of the above problems.

(I still hope they change it. Nested elements might be a way to go.)

Re: First draft of HTML img srcset for responsive images

#43

Post by hoppipolla »

ZenPsycho wrote: post #34
hoppipolla wrote: post #32

Earlier quoted context omitted.

From an implementation point of view, putting everything in a single attribute is way simpler; the design of is quite problematic. The reason is that with a single attribute everything can be processed atomically. With a design based on multiple elements things can happen between elements being processed, creating many more edge cases. Although in general things that make authoring easier are preferred, designs that…

I gave you a whole list of options but you only focus on these two. why?

Because I was making a specific point about the implementation complexity of things that depend on attributes vs things that depend on many elements.

Re: First draft of HTML img srcset for responsive images

#44

Post by user24 »

annevk wrote: post #24
user24 wrote: post #18

Earlier quoted context omitted.

> the syntax feels awkward, clunky and very specific Yeah, stuff like "2x 100w" looks a bit like magic numbers[1] Also there's potential for confusion in 'x' - does it mean X as in a co-ordinate i.e. width, or zoom? I'd rather see something more verbose like this: Yes it's more wordy to write, but you read code more than you write it so it makes sense to optimise for readability over byte-shaving. [1] http://catb.org…

We cannot change the way is parsed. See e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/ for the tree you get with that markup. It's not what you expect.

Fair enough, but that is a technical limitation which is trivial to get around:
Always be wary of allowing arguments that hinge on "it's not technically possible" to shut down good ideas.

Re: First draft of HTML img srcset for responsive images

#45

Post by ZenPsycho »

mcobrien wrote: post #42
ZenPsycho wrote: post #27

This is silly and makes things way more complicated than they need to be. We have HTML tags, to which we can apply attributes directly via blah=blah syntax Or we can add attributes by making a style attribute, and using css syntax inside of it. Or we can have a space separated list of class names, and have attributes applied to an element externally by a CSS stylesheet. Or we can have an ID, and apply attributes usin…

Using CSS means you have to specify image locations in two places, with potentially different base URLs. Using Javascript means you have to load scripts before the img tag, which can hurt performance. Using http headers or a special URL format makes working with CDNs more difficult. This is actually a tricky problem to solve and it looks like the authors have considered some of the above problems. (I still hope they…

wait hold on how does having a query string in a url make CDN's more difficult?

Re: First draft of HTML img srcset for responsive images

#47

Post by fiznool »

An alternative, completely server-side implementation: http://adaptive-images.com/

It takes the approach of setting a cookie when the page first loads with the viewport size, determined through media queries. Every request to the server then includes this cookie.

When an img is requested (as an tag or through CSS background-image) the cookie is read to determine the viewport size of the client. The PHP script then serves up the most appropriate image size to the client.

The only thing you really need to do is add the .htaccess rule (to intercept image requests and route them through the PHP script), the php script itself and the highest resolution you need for each image. The script takes care of scaling down the image for smaller screens, caching them for later use.

I like the way this requires nothing on the client side, other than a cookie being set. All the heavy lifting is done on the server.

Re: First draft of HTML img srcset for responsive images

#48

Post by hoppipolla »

ZenPsycho wrote: post #41
woodall wrote: post #38

Earlier quoted context omitted.

Is there a way this can take place entirely server side?

sure, it would be simple enough to copy what was done with the server side image maps thing, and define some query parameters that get requested along with the image. So each different size gets its own url and proxies and caches are happy. servers that don't support it just serve a normal image. a tiny bit of javascript can polyfill it in now. today.

That is a very appealing design, but sadly it doesn't address all the use cases. In particular one thing that people want to be able to do is to display a different image depending on the viewport dimensions, for example a closer crop on a small screen compared to that shown on a larger screen.

Re: First draft of HTML img srcset for responsive images

#49

Post by ZenPsycho »

hoppipolla wrote: post #48
ZenPsycho wrote: post #41

Earlier quoted context omitted.

sure, it would be simple enough to copy what was done with the server side image maps thing, and define some query parameters that get requested along with the image. So each different size gets its own url and proxies and caches are happy. servers that don't support it just serve a normal image. a tiny bit of javascript can polyfill it in now. today.

That is a very appealing design, but sadly it doesn't address all the use cases. In particular one thing that people want to be able to do is to display a different image depending on the viewport dimensions, for example a closer crop on a small screen compared to that shown on a larger screen.

what is stopping this approach from addressing that use case?

Re: First draft of HTML img srcset for responsive images

#50

Post by Kilimanjaro »

user24 wrote: post #44
annevk wrote: post #24

Earlier quoted context omitted.

We cannot change the way is parsed. See e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/ for the tree you get with that markup. It's not what you expect.

Fair enough, but that is a technical limitation which is trivial to get around: Always be wary of allowing arguments that hinge on "it's not technically possible" to shut down good ideas.

FTFY
Post reply on HN