Fwd: [whatwg] Built-in image sprite support in HTML5

FYI - the discussion on this topic continues at the WHATWG and Ian is
suggesting we make better specifications about what browsers should
implement when facing media fragment URIs.

Might be worth a discussion at our next meeting.

Cheers,
Silvia.


---------- Forwarded message ----------
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, Aug 26, 2010 at 12:00 PM
Subject: Re: [whatwg] Built-in image sprite support in HTML5
To: Ian Hickson <ian@hixie.ch>
Cc: David Weitzman <dweitzman@gmail.com>, "Tab Atkins Jr." <
jackalmage@gmail.com>, whatwg@lists.whatwg.org


On Thu, Aug 26, 2010 at 8:10 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 4 Aug 2010, Silvia Pfeiffer wrote:
> > > >
> > > > However, what exactly happens with a media fragment URI like
> > > > http://example.com/picture.png#xywh=160,120,320,240 is not fully
> > > > specified in the Media Fragment URI spec.
> > >
> > > I would recommend fixing that. :-)
> >
> > Well, that goes into implementation issues and really has nothing to do
> > with the URI specification itself.
>
> Specifications have everything to do with implementation issues. That's
> what they're for. If the specification doesn't say how to get
> interoperablel implementations, then it's not very useful.
>

There are recommendations for what to do with video in the browser. I can
encourage the group to also make recommendations for what it means for
images in the browser.

However, the use of Media Fragment URIs in applications in general really
cannot be prescribed - what a video editor does with a media fragment URI is
different to what a video playlist player does and again different to what
it means in the browser and probably different again for <pick your random
application here>. Not all applications display a timeline - not all
applications allow interaction with the resource, some applications want to
use the resource in context (i.e. with access to the rest of the resource),
others don't. It is early times for Media Fragment URIs so some of these use
cases will have to be experimented with before a good recommendation can be
made.



>
> > As we adopt media fragment URIs into the HTML5 spec, we should prescribe
> > what the user experience is meant to be, such that UAs can implement a
> > consistent handling.
>
> I don't think it makes sense to have the HTML spec define what other specs
> mean. We've had to do it in places, but only when the other specifications
> have dropped the ball.
>

I will take the desire to have a clear specification for what Web browsers
are to do with Media Fragment URIs back into the Media Fragment WG. I
believe Web browsers are a special and the most important use case for such
URIs, so it makes sense to specify that clearly.

It would, however, be good to have an indication where HTML would like to
see it going. Would it be better for a media fragment URI for images such as
http://example.com/picture.png#xywh=160,120,320,240  to display the full
image with the rectangle somehow highlighted (as is the case with fragment
URIs to HTML pages), or would it be better to actually just display the
specified region and hide the rest of the image (i.e. create a sprite)? What
makes the most sense for images?


Cheers,
Silvia.