Right click > Save Image As…
There’s an issue with this that needs addressing. Currently there’s only ever one resource and so that’s what get’s downloaded. When we are adapting to the device’s capabilities, we’re generally doing so for performance reasons. However, when someone wants to save an asset I think it’s reasonable to ask whether they want that exact asset, or will they want the best representation of that asset?
Is this more of a browser behaviour issue or something we should tackle as HTML?
Very good point, Matt!
It does work fine in Scott’s “A sample picture implementation” but, because he is using the real IMG tag anyway even if wrapped with PICTURE. I think that a new element when rendered should behave exactly as the IMG tag does now, so that people would know what to expect from it. And “Right click > Save Image As…” should be an essential part of it.
Moreover people should be able to drag an image (presented as PICTURE in our case) to their Desktop for example. What do they get in this case? I would say that they have to get a real JPG or some other format, but it has to be an image they can use in their editors, for example.
What I would like to see on my device when I visit a page and want to download an image marked up with the new responsive element is a selection/dropdown list for selecting the source file.
In my view this is a browser behavior since it is related to how the content is accessed by the user.
If I take Scott Jehl’s as an example for the markup we have the following:
For consistency we should look at a unified way of describing the different source files, like “Small – 0x0 to 350×350”, “Medium 350×350 to 800×800” and “Large 800×800 to ..” in a download dialog.
It seems to me like this is an implementation detail, but perhaps something that ought to be in the standard nonetheless. I’m thinking of the details of required player attributes for video and audio elements – pieces which can be styled or replaced as the designer pleases, but which the browser is nonetheless responsible to provide. Perhaps something similar ought to be the case for images: the browser could be required to provide access to various resolutions in some way. I concur with Denys’ point about dragging an image to desktop. There needs to be a clearly defined default behavior in that instance; I would lean toward grabbing the highest resolution of the image.
I think there are ways this could be solved really cleverly on the UA-side—like Kenneth said, a dialog giving the size options would be especially cool.
I think for our part, there’s no harm in defaulting to saving down the currently displayed source. I feel like “I get what I’m seeing” is the most predictable possible outcome. If UA vendors can build on that to provide more options unobtrusively? Awesome.
That’s my current thinking too. Dragging to the desktop should deposit what you’re seeing onto the desktop as this is more of a physical seeming interaction “take THIS and put it THERE”.
Right Click > Save As is a good place to disclose any additional versions of the resource (remembering that they may be different images, not simply re-scaled adaptions).
Thanks for the feedback all 🙂
Pingback: <picture> for existing browsers. | Responsive Images Community Group
Confirm with that although I’m late into discussion. By default the displayed image should be downloaded or better the one that is the default image in the tag, too.
Other things like a select-box in save-dialog is up to the UAs.
@Mat, I agree that the browser should save at the size in which the image is viewed. Also, I think getting browser vendors to modify their current file download UI is going to be harder than what’s being envisioned.