Image URL sharing #11

Closed
nwtn opened this Issue Oct 18, 2012 · 14 comments

Comments

Projects
None yet
7 participants
@nwtn
Member

nwtn commented Oct 18, 2012

Need to consider possible use cases and/or requirements and/or notes about how copying and sharing image URLs would work given multiple sources (and possibly multiple formats).

See comments from Josh Fraser @ Torbit:

The biggest problem we ran into that we didn't expect is the number of people who grab the URL of the image and share it on Facebook, Twitter, email, whatever. This of course breaks for everyone not using a browser that supports it. We can serve the images up each time from a single URL based on the User-Agent, but that's not something you can do at the browser level.

@marcoscaceres

This comment has been minimized.

Show comment Hide comment
@marcoscaceres

marcoscaceres Oct 18, 2012

Owner

Linked to this from the spec.

Owner

marcoscaceres commented Oct 18, 2012

Linked to this from the spec.

@nathanaeljones

This comment has been minimized.

Show comment Hide comment
@nathanaeljones

nathanaeljones Oct 23, 2012

I suggest that all current menu items (Like Open Image in New Tab, Copy Image Link) behave as if the current 'image' was the only URL, for clarity and obviousness.

While I DO anticipate user frustration of lack of format support in other browsers, I think that will help motivate browser vendors to follow through with implementations. To open the door to new formats, we DO have to solve first-level adoption issues through type="content/type". But this issue isn't serious enough to stall adoption, and if things are too smooth, IE will never support WebP :)

I do suggest mentioning that user agents MAY introduce a contextual menu listing "Alternate Image Versions" as source URIs, which when clicked causes the selected version to be opened in a new tab, window, or popup.

I suggest that all current menu items (Like Open Image in New Tab, Copy Image Link) behave as if the current 'image' was the only URL, for clarity and obviousness.

While I DO anticipate user frustration of lack of format support in other browsers, I think that will help motivate browser vendors to follow through with implementations. To open the door to new formats, we DO have to solve first-level adoption issues through type="content/type". But this issue isn't serious enough to stall adoption, and if things are too smooth, IE will never support WebP :)

I do suggest mentioning that user agents MAY introduce a contextual menu listing "Alternate Image Versions" as source URIs, which when clicked causes the selected version to be opened in a new tab, window, or popup.

@anselmh

This comment has been minimized.

Show comment Hide comment
@anselmh

anselmh Oct 24, 2012

Member

If img-element is provided as fallback that would be the easiest solution. Provide this URL to the user.

If not it should be the one that is actually displayed by the browser to the user. This case the user gets what he actually sees and does not have to download more sources.

Member

anselmh commented Oct 24, 2012

If img-element is provided as fallback that would be the easiest solution. Provide this URL to the user.

If not it should be the one that is actually displayed by the browser to the user. This case the user gets what he actually sees and does not have to download more sources.

@igrigorik

This comment has been minimized.

Show comment Hide comment
@igrigorik

igrigorik Oct 25, 2012

@nathanaeljones yet, the inability to have a safe fallback for WebP is exactly what prohibits more sites from adopting it. A 30% savings over JPEG is a huge deal for the mobile web.

To address the root issue, we probably need both browser UI and markup tweaks: browser UI for user sharing, and markup for bookmarklets and extensions which simply scan the DOM, looking for images.

@nathanaeljones yet, the inability to have a safe fallback for WebP is exactly what prohibits more sites from adopting it. A 30% savings over JPEG is a huge deal for the mobile web.

To address the root issue, we probably need both browser UI and markup tweaks: browser UI for user sharing, and markup for bookmarklets and extensions which simply scan the DOM, looking for images.

@anselmh

This comment has been minimized.

Show comment Hide comment
@anselmh

anselmh Oct 26, 2012

Member

Revised my thoughts and came to the result that it always should be the mobile / small version which should be shared if it actually is not a html-responsive file. That due to the fact mobile traffic is more and more limited by providers…

Member

anselmh commented Oct 26, 2012

Revised my thoughts and came to the result that it always should be the mobile / small version which should be shared if it actually is not a html-responsive file. That due to the fact mobile traffic is more and more limited by providers…

@nwtn

This comment has been minimized.

Show comment Hide comment
@nwtn

nwtn Oct 28, 2012

Member

I agree with @nathanaeljones that the ideal scenario would be for browsers to alter the context-menu options, allowing users to select which source they want to open/copy/save. That might be a tall order though, and I'm not sure how much we can push for it in our specs.

It's possible that confusion that arises out of this could, as @nathanaeljones said, push browser makers towards better/more implementations. However, it's also possible that it could push developers to abandon the whole thing to avoid this frustration.

If new context menu options aren't available, I'm not totally sure of the best approach; my thinking on this has flip-flopped a couple times. Right now I'm leaning towards the browser using the URL of the image that is currently displayed. It's the most predictable for users. If it used, as @anselmh suggests, the fallback image (or the mobile/small version), the user might end up getting a version with different art direction, or of a different size, and I think that's problematic.

Member

nwtn commented Oct 28, 2012

I agree with @nathanaeljones that the ideal scenario would be for browsers to alter the context-menu options, allowing users to select which source they want to open/copy/save. That might be a tall order though, and I'm not sure how much we can push for it in our specs.

It's possible that confusion that arises out of this could, as @nathanaeljones said, push browser makers towards better/more implementations. However, it's also possible that it could push developers to abandon the whole thing to avoid this frustration.

If new context menu options aren't available, I'm not totally sure of the best approach; my thinking on this has flip-flopped a couple times. Right now I'm leaning towards the browser using the URL of the image that is currently displayed. It's the most predictable for users. If it used, as @anselmh suggests, the fallback image (or the mobile/small version), the user might end up getting a version with different art direction, or of a different size, and I think that's problematic.

@igrigorik

This comment has been minimized.

Show comment Hide comment
@igrigorik

igrigorik Oct 28, 2012

What you're describing is content negotiation, which should be handled at a lower layer. In fact, this is nothing new: some clients may support gzip, some not, and the format is negotiated at request time, transparent to the user.

Instead of adding context menu's, etc, the browser can instead send an Accept header indicating which image formats it supports, at which point the URL stays the same, but encoding changes.

What you're describing is content negotiation, which should be handled at a lower layer. In fact, this is nothing new: some clients may support gzip, some not, and the format is negotiated at request time, transparent to the user.

Instead of adding context menu's, etc, the browser can instead send an Accept header indicating which image formats it supports, at which point the URL stays the same, but encoding changes.

@nwtn

This comment has been minimized.

Show comment Hide comment
@nwtn

nwtn Oct 28, 2012

Member

@igrigorik this isn't just for image formats, though, it's an issue for different size images and differently art-directed images, too. It needs to be predictable to the user what image they're copying. Ideally, it would also give them the choice.

Member

nwtn commented Oct 28, 2012

@igrigorik this isn't just for image formats, though, it's an issue for different size images and differently art-directed images, too. It needs to be predictable to the user what image they're copying. Ideally, it would also give them the choice.

@igrigorik

This comment has been minimized.

Show comment Hide comment
@igrigorik

igrigorik Oct 28, 2012

You're copying what you're seeing, providing a client mechanism to arbitrarily swap out the resource when you want to copy or share it is a great vector for abuse and nasty attacks - aka, art-direction in the opposite direction. If you want the user to share a different resource, then provide a link to the alternate version.

You're copying what you're seeing, providing a client mechanism to arbitrarily swap out the resource when you want to copy or share it is a great vector for abuse and nasty attacks - aka, art-direction in the opposite direction. If you want the user to share a different resource, then provide a link to the alternate version.

@Wilto

This comment has been minimized.

Show comment Hide comment
@Wilto

Wilto Oct 28, 2012

Owner

I’m with @igrigorik here. I’m certain there are ways this could be handled really cleverly on the UA side, but one step at a time—for our purposes, I think speccing that the currently visible source is the “sharable” one is the most we can do for now.

Owner

Wilto commented Oct 28, 2012

I’m with @igrigorik here. I’m certain there are ways this could be handled really cleverly on the UA side, but one step at a time—for our purposes, I think speccing that the currently visible source is the “sharable” one is the most we can do for now.

@nwtn

This comment has been minimized.

Show comment Hide comment
@nwtn

nwtn Oct 28, 2012

Member

@igrigorik That's an interesting point about it being a potential attack/abuse vector

@Wilto as I said, I'm leaning this way too right now. I think a new context menu is a good idea but, as I said, I don't think it's something we can push for in the specs.

Member

nwtn commented Oct 28, 2012

@igrigorik That's an interesting point about it being a potential attack/abuse vector

@Wilto as I said, I'm leaning this way too right now. I think a new context menu is a good idea but, as I said, I don't think it's something we can push for in the specs.

@anselmh

This comment has been minimized.

Show comment Hide comment
@anselmh

anselmh Oct 28, 2012

Member

@igrigorik @Wilto Agree. We should do it that way now for the spec. The other things are up to UA/UA-plugins.

Member

anselmh commented Oct 28, 2012

@igrigorik @Wilto Agree. We should do it that way now for the spec. The other things are up to UA/UA-plugins.

@MattWilcox

This comment has been minimized.

Show comment Hide comment
@MattWilcox

MattWilcox Nov 5, 2012

My thinking is that it'd be nice for the browser UI to expose alternative resources, but the use case is someone sharing what they can see. So to me it makes sense that the behaviour would be to grab the URI for whatever asset the user is being shown.

My thinking is that it'd be nice for the browser UI to expose alternative resources, but the use case is someone sharing what they can see. So to me it makes sense that the behaviour would be to grab the URI for whatever asset the user is being shown.

@marcoscaceres

This comment has been minimized.

Show comment Hide comment
@marcoscaceres

marcoscaceres Nov 16, 2012

Owner

I can't see any further action here relating to the use cases. Let's come back to this if we need to later.

Owner

marcoscaceres commented Nov 16, 2012

I can't see any further action here relating to the use cases. Let's come back to this if we need to later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment