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

31–40 of 79 posts

Re: First draft of HTML img srcset for responsive images

#31

Post by ars »

alexchamberlain wrote: post #29
ars wrote: post #19

Earlier quoted context omitted.

No, this won't work in the wild. It breaks caching completely. It requires scripting just to serve an image. The same url can have different data - imagine if you resume downloading a file, only to suddenly have a different file.

I disagree. Caches would have to be intelligent. Remember they already have to pay attention to language headers etc. URLs represent a conceptual resource, rather than a single file.

Caches (proxies) already exist. You don't have the option of reprogramming them for this new header.

Re: First draft of HTML img srcset for responsive images

#32

Post by hoppipolla »

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…

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 are easy to implement in a bug-free way are generally preferred over designs that are complex and likely to lead to interoperability issues. After all, having to fight implementation differences is a rather common complaint about the web platform.

It also hasn't been clearly demonstrated that multiple elements are easier to work with. They are more familiar, but significantly more verbose. I don't know how that plays out in practice.

Re: First draft of HTML img srcset for responsive images

#33

Post by hoppipolla »

necolas wrote: post #28
othermaciej wrote: post #21

Earlier quoted context omitted.

The approach also has a sort of solution for degrading gracefully in older browsers. You can nest an in your . Newer browsers are supposed to ignore it, older browsers would ignore the surrounding element instead. I think there are other good reasons to prefer the srcset approach, but not this one. The email here provides motivation: http://lists.w3.org/Archives/Public/public-whatwg-archive/20... ;

Unfortunately, at the time when Ian didn't seem to care about the issue of responsive images, I asked him about the possibility of using the existing ` ` element and he said it was pointless to try and modify existing image parsing. Forget it. Now, he decides that actually this is the way to go. Frustrating. For reference, in the email linked above, Ian Hickson said: > So why not just give the UA the characteristics…

This doesn't modify parsing. Modifying parsing would be something like allowing to have child elements. Adding extra attributes to an element requires no changes to the parser.

Re: First draft of HTML img srcset for responsive images

#34

Post by ZenPsycho »

hoppipolla wrote: post #32
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…

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?

Re: First draft of HTML img srcset for responsive images

#35

Post by ZenPsycho »

hoppipolla wrote: post #32
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…

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…

And even if what you say about nesting is true- It's already a part of the standards for video, audio, and objects. It's not like we can change our minds about those. So we make the whole language inconsistent just because?

Re: First draft of HTML img srcset for responsive images

#36

Post by andybak »

I don't care if the syntax is a bit unsightly. Let's just get this into shipping browsers as soon as possible. It's a major requirement for responsive design and this has good fallback behaviour. We can all just stick to 'mobile first' design and a .js polyfill shouldn't be hard.

Re: First draft of HTML img srcset for responsive images

#37

Post by ZenPsycho »

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 of jpeg images. Similar things could be done with png. No modifications to any standards need to take place.

Re: First draft of HTML img srcset for responsive images

#38

Post by woodall »

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?

Re: First draft of HTML img srcset for responsive images

#39

Post by kennu »

tferris wrote: post #16

Better than this specification hassle is this solution: The browser should send the density of the screen in ppi (calculated by the screen resolution and the screen information provided by the OS) together with all the other standard stuff like OS, screen resolution, etc. With this information the server can decide which images to send.

Web servers shouldn't need to rely on any other information than the URL in order to serve the right content. This keeps the simple use cases simple, as the URL directly translates to a file on the server. Otherwise every web werver in the world would need some special new logic for choosing different files.

Re: First draft of HTML img srcset for responsive images

#40

Post by bobsy »

Looks like a horrible solution which will add bloat and complexity to a webpage.

I would rather see a solution implemented with CSS or even a meta tag.

The above example is exactly the same information as in this link. However it is expressed in one place and thus is far simpler. The only reason to do this per image would be if you different naming conventions for individual images.. which would just be silly.

You could then have a nosrcset attribute which you can add to images which do not have high-res versions. This would save an http request.

Post reply on HN