Isn't this up to the Media Fragments spec to define?

The answer should be, imo, that a spatial fragment represents precisely that - a fragment of a larger resource.  Only the fragment would be displayed.

(In reply to comment #1)
> Isn't this up to the Media Fragments spec to define?
> 
> The answer should be, imo, that a spatial fragment represents precisely that -
> a fragment of a larger resource.  Only the fragment would be displayed.

The issue is that you cannot deliver just the fragment pixels, so it's up to the User Agent to restrict the image pixels to just the requested ones. Otherwise it would be simple. So, since the UA receives all the pixels, it needs to be specified what pixels the UA actually has to deal with.

The Media Fragment spec already makes a recommendation, but is that sufficient for browsers to actually be assured of what pixels to work with from within a HTML5 page? In particular in a cross-browser consistent manner?

Note: related earlier discussion http://lists.w3.org/Archives/Public/public-media-fragment/2010May/0061.html

It is actually necessary to specify where a media fragment URI is executed and where not in a browser. For example in a download link such as in right-clicks, the UA can't execute the fragment, since that would require creation of a consistent new resource and not just several byte range requests (unless browsers actually repackage the content, which is certainly an option).

(In reply to comment #4)
> ...since that would require creation of a
> consistent new resource and not just several byte range requests (unless
> browsers actually repackage the content, which is certainly an option).

Byte range requests wouldn't work for spatial media fragments would they? For the formats that immediately come to mind you'd have to download the actual resource and then crop. You can't byte range request into a spatial area.

(In reply to comment #5)
> (In reply to comment #4)
> > ...since that would require creation of a
> > consistent new resource and not just several byte range requests (unless
> > browsers actually repackage the content, which is certainly an option).
> 
> Byte range requests wouldn't work for spatial media fragments would they? For
> the formats that immediately come to mind you'd have to download the actual
> resource and then crop. You can't byte range request into a spatial area.


No, you cannot do byte ranges on spatial media fragments in general. Indeed, cropping is necessary, which would be browser-internal only.

My above comment was also for temporal media fragments, where it is possible though probably not trivial to re-package the content as a shorter piece of audio/video.

What about the percent syntax #xywh=percent:25,25,50,50 ? If that does not map to a integer number of pixels, should rounding be applied and in which direction?

I presume that videoWidth and videoHeight should also reflect the cropped dimensions, so the question applies there as well.

I note also in passing that if Opera implements support for Media Fragment, there's no plan for supporting the xywh syntax, as you can already achieve cropping with CSS. If there are compelling use cases where CSS doesn't do a good job, then I might reconsider, of course.

(In reply to comment #7)
> What about the percent syntax #xywh=percent:25,25,50,50 ? If that does not map
> to a integer number of pixels, should rounding be applied and in which
> direction?

That should probably go into the media fragment spec. Good point to make - I would say always round up.

> I presume that videoWidth and videoHeight should also reflect the cropped
> dimensions, so the question applies there as well.

Yes, indeed, so that has to go into the HTML spec (or at least refer to the media frag spec).

> I note also in passing that if Opera implements support for Media Fragment,
> there's no plan for supporting the xywh syntax, as you can already achieve
> cropping with CSS. If there are compelling use cases where CSS doesn't do a
> good job, then I might reconsider, of course.

Link below has a use case..


(In reply to comment #3)
> Note: related earlier discussion
> http://lists.w3.org/Archives/Public/public-media-fragment/2010May/0061.html

Sorry, I meant this one:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027581.html

(In reply to comment #8)
> (In reply to comment #7)
> > What about the percent syntax #xywh=percent:25,25,50,50 ? If that does not map
> > to a integer number of pixels, should rounding be applied and in which
> > direction?
> 
> That should probably go into the media fragment spec. Good point to make - I
> would say always round up.

OK, raised in http://lists.w3.org/Archives/Public/public-media-fragment/2011Apr/0011.html

> Link below has a use case..

> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027581.html

I'm not sure I understand this. What is "image sprite support" and why is cutting an image using the canvas 2d api not good enough?

(In reply to comment #9)
> > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027581.html
> 
> I'm not sure I understand this. What is "image sprite support" and why is
> cutting an image using the canvas 2d api not good enough?

Consider the general case of CSS spriting, which is currently done in a hacky way with background-position.  Spriting into an <img> is just one instance of this type of spriting that can't be done even hackily at present (without doing something like running script to use <canvas>).

(In reply to comment #10)
> (In reply to comment #9)
> > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027581.html
> > 
> > I'm not sure I understand this. What is "image sprite support" and why is
> > cutting an image using the canvas 2d api not good enough?
> 
> Consider the general case of CSS spriting, which is currently done in a hacky
> way with background-position.  Spriting into an <img> is just one instance of
> this type of spriting that can't be done even hackily at present (without doing
> something like running script to use <canvas>).

Is the goal of this to save bandwidth by putting several images into a single physical image?

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027581.html
> > > 
> > > I'm not sure I understand this. What is "image sprite support" and why is
> > > cutting an image using the canvas 2d api not good enough?
> > 
> > Consider the general case of CSS spriting, which is currently done in a hacky
> > way with background-position.  Spriting into an <img> is just one instance of
> > this type of spriting that can't be done even hackily at present (without doing
> > something like running script to use <canvas>).
> 
> Is the goal of this to save bandwidth by putting several images into a single
> physical image?

Not bandwidth, but connections, yes.  Spriting isn't the best approach for saving connections (better is resource packages, or a reworking of the internet architecture like SPDY), but it's a decent stop-gap solution.

My concern with supporting #xywh for still images is that it would require rewriting code all over the place (<img>, CSS backgrounds/borders) that previously used the physical size of the image to also consider the fragment size. This is of course possible, but it's really a question if it's worth the implementation cost (and future bugs) to support these use cases, which IMO are rather marginal.

If HTTP pipelining were completely inadequate, I'd have expected to see JavaScript libraries to work around this using CSS or canvas in common use.

(In reply to comment #13)
> If HTTP pipelining were completely inadequate, I'd have expected to see
> JavaScript libraries to work around this using CSS or canvas in common use.

You do, in the form of CSS Spriting, which is very widespread and recommended by all major performance optimization guides.  It's an ugly hack, though - background-position was never meant to be used in this way.  I'm helping with a bug on an internal page right now where background-position rounds in different directions at certain zoom levels, causing the sprited image to appear to vibrate when you animate between the sprites - my best suggestion so far was to use <canvas> to sprite the images instead. ^_^

(In reply to comment #0)
> Problem: what is a browser to display when the browser navigates to a image or
> video resource with a spatial media fragment URI

That's more or less out of scope of the HTML spec, no?


> or when the @src attribute of
> a <img> [...] element contains a spatial media fragment URI

Are there any image MIME types that support the media fragment syntax? If not, then the answer is "nothing different".


> or <video>

For video, the spec just defers to the video format; if the video format supports the media fragment syntax then that'll be defined by the video format spec.

In conclusion, this seems out of scope for HTML.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see above

mass-move component to LC1