Hacker News Reader

Comment by hcarvalhoalves | Hacker News Reader

They are creating their own little DSL inside a tag attribute? This "1x", "2x" stuff in the markup looks awful.

I can see from here the compatibility and complexity trainwreck we're going to have down the line.

Think I agree. I feel like we would expect to see a resolution is either normal or double in dimensions. But currently with media attributes we are able to set the image property in CSS by itself and it gives us much more control. Particularly useful in instances where our images aren't exactly normal or double in dimensions but are resized.

Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?

Media query syntax has been proposed:

   <picture><source media="min-resolution: 2ppx"></picture>

but mere query doesn't affect intrinsic size of the image, so you'd also need to specify exact dimensions in the markup or something like:

   <picture>
   <source media="min-resolution: 2dppx" style="image-resolution: 2dppx">
   </picture>

which is rather verbose and error-prone compared to srcset.

> Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?

I don't think so (meaning of "1x" gradually changed from 72dpi to 100-130dpi, so I expect "2x" similarly gradually increase) and I proposed that new image embedding methods default to @2x, but that idea hasn't gained support from CSS/HTML WGs.

It could assume you are defining image dimensions in the stylesheet the way that normal image tags do. Or it can default to the image scaled down to 2ppx as defined in the media query. Your example looks similar to current audio tags.

  <audio controls>
    <source src="horse.ogg" type="audio/ogg">
    <source src="horse.mp3" type="audio/mpeg">
  Your browser does not support the audio element.
  </audio>

The elephant in the room is, what "normal" and "double" even mean? It could be negotiating content based on something actually meaningful, like viewport size, DPI, even connection speed. This spec is broken as soon as we have to worry about something other than retina displays.

You can see they are basically getting this very vendor-specific hack they already had and calling it a standard. That's heresy.

Exactly. They should be reporting the resolution of each image in pixels, and leave the client to figure out what they want to download based on variables like connection speed, screen PPI, user settings etc. Trying to specify a scale just doesn't make sense, because the UA might be any resolution or multiple resolutions, might degrade for edge connections etc - the UA is best-placed to decide which images it wants, and that should be on the basis of source image resolution in pixels, not some arbitrary scale. Using 2x, 4x, 1280w is tied to the conventions of our current devices, which will change many times in the future, and doesn't provide useful information about the src image itself. Why do this?

They've done the same thing with resolution independence on iOS - instead of some sensible system of scaling and caching, we've ended up with a situation where images and icons are saved in several different versions by the developer just to cope with all the different possible resolutions/ratios using this sort of @2x naming scheme, and all based off arbitrary resolutions of screens which are going to change. It's a mess.

I think they'd be better with something like this:

    <picture>
       <source src="myjpg.jpg" width=100 height=100>   
       <source src="myjpglrg.jpg" width=1000 height=1000>
       <img src="myjpg.jpg" alt="fallback img tag or text">
    </picture>

We already have this scheme of source elements for audio and video, and this is the perfect moment to introduce something a bit more sane for images too. There's no need for the specification of arbitrary resolution intents if you give the src sizes. This would also let us transparently handle new file formats with fallback to older ones with type attributes, as with audio and video tags. For example you might start introducing SVG versions of many images, but leave a png source in there for older browsers.

The above proposal already displays perfectly fine in older browsers if you use an img tag within the <picture> tags for backwards compatibility, and could easily be dealt with in older IE with workarounds if necessary, though I think the img tag would display fine.

CSS can then be used to control the intended display size.

Not addressing anything else you raised but width and height are insufficient for making network performance and network budget decisions. Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression.

Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression.

Yes, that's true, though generally pixel size does relate quite well to file size for different versions of a given image on the web, and a picture element could just have sources in order of preference of use (regardless of size), so basically quality order - I think that's what the video element does (though for formats, not sizes)? The browser could choose different images depending on quality/bandwidth/resolution concerns, so it wouldn't always have to use the first. If not a quality attribute or something similar would be easy enough to add. I think the basic idea of the audio and video/source elements is fine, and should be extended to images as it could cover lots of use cases - don't really mind about the details as I'm sure they could be worked out.

The best way to get good retina images I've found so far is simply to oversize and compress heavily, which gives surprisingly good results and small files even for large images - I'd love to use something like the new picture element for multiple resolutions so that I could also provide a smaller version for lower bandwidth uses, but frustratingly webkit authors seem to see the picture element as somehow superseded by srcset, even though it doesn't do what a picture element would do, and introduces yet more headaches. I wouldn't consider using srcset for the reasons given above and because I've already experienced this solution in iOS dev, and it was equally broken there.

The UA can do whatever it wants; the information given in srcset is for giving the UA the clues it needs to make the right decision. [0]

> From the available options, the user agent then picks the most appropriate image.

So if you are zoomed in, the UA can decide that a higher-res image is the most appropriate one.

[0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

It's not providing the right information for a decision, it's trying to prejudge that decision based on one factor (screen resolution).

On top of that the syntax is awful and appears to have been chosen to make browser vendors' lives slightly easier - I went and had a look at the links you gave to hixie's reasoning, and it's all based on minor difficulties browsers had parsing audio/video, but they've already done that work, why introduce yet another sub format within an attribute?

The "2x" describes the image, not a property of the device that image is being viewed on.

If I have an image meant to be displayed in a 250x250 area of layout, a 500x500 "retina-ready" image will not fit. The browser must be told that the image is meant to be displayed "@2x" (as Apple puts it). This is what the "2x" is for. The browser is allowed to use any or none of that information in its decision making.

The syntax of srcset="" was chosen to match CSS's image-set syntax. The <audio>/<video> pattern wasn't great for anyone.

"You can see they are basically getting this very vendor-specific hack they already had and calling it a standard. That's heresy."

No, that's HTML5.

It's also a total mischaracterisation of what happened here. This was not a case where someone implemented the feature and we were forced to go with they syntax for compatibility reasons. There was extensive discussion about the use cases, best approach, and so on. It turns out to be a much harder problem than you might have thought. For just one example of a subtlety, browser vendors find <picture><source> type syntaxes harder because they can't be processed atomically; for example: <picture> <source src="foo"> <script>document.getElementsByTagname("source")[0].src = "bar"</script> [...]

is complexity that simply can't happen with srcset. Similarly one needs to consider the behaviour of preloaders in extant UAs; if existing browsers will start to download all the images that will create a much worse user experience in the short term.

I don't remember what all the considerations were here, but this is a much harder problem than many people give credit for, and certainly isn't a case where a single vendor controlled the whole process.

With respect, making life easier for browser makers is the worst possible reason to choose a feature which will be used by millions of documents (or not, in the case of srcset) over another with a better syntax. I'm not even clear why onload on an img tag would not also invalidate your img example above, but that doesn't even matter. Hacks for performance may be fine in browser or server code in some circumstances, but are absolutely not fine in a public document format like HTML.

Is the picture element containing source elements (like video and audio) still under consideration, or is srcset supposed to replace it somehow?

The multipliers refer to the ratio of device pixels to software pixels ("CSS pixels"). Content can be negotiated via viewport size, it's just that Webkit doesn't support that part yet. [0] The pixel ratio is better information than DPI, and connection speed is a difficult and unreliable metric.

[0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

Original blog post: https://www.webkit.org/blog/2910/improved-support-for-high-r...

> Note that at the moment WebKit only supports the resolution modifiers (e.g. 1x, 2x, 3x).

The official [draft] specification: http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/

The dimensions in the srcset attribute are the maximum (viewport) dimensions that an image is intended for. e.g.:

    <img src="pear-mobile.jpeg" srcset="pear-mobile.jpeg 720w, pear-tablet.jpeg 1280w, pear-desktop.jpeg 1x" alt="The pear is juicy.">

I disagree. It looks like the future of the web. Have you seen Web Components?

Reply on news.ycombinator.com