W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2010

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 23 May 2010 22:27:18 +1000
Message-ID: <AANLkTimCUPt8_iySx07OVO6Ui_bl0_Eo3tYZAbjPwAq_@mail.gmail.com>
To: Media Fragment <public-media-fragment@w3.org>
FYI: there is a discussion about image sprites happening on the WHATWG
mailing list and I've just had the following feedback on using #xywh
for highlighting an image region rather than focusing in on it.

We might want to change it or better explain our reasons for display choices.


---------- Forwarded message ----------
From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Sun, May 23, 2010 at 10:04 PM
Subject: Re: [whatwg] Built-in image sprite support in HTML5
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, whatwg@lists.whatwg.org,
David Weitzman <dweitzman@gmail.com>

On Fri, May 21, 2010 at 8:07 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> 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.
> One thought was to just highlight the area that is specified - similar
> to a lightbox - where the other areas in the image/video are darkened.
> That follows the idea of fragments being a focus region.
> Another thought is to zoom into that area and decode, but not display
> the others.

The first idea doesn't make any sense to me as an author.  It seems
like it would be vastly less useful than the second.  It's just a
stylistic effect, which you don't even have any control over -- and
authors don't like being unable to control style precisely.  What I'd
expect is the second thing: that URL should behave exactly like a
manually-cropped version of picture.png, so you don't have to use
positioning hacks or serve a separate cropped file.  This would be
useful for spriting -- although resource packages, or another HTTP
pipelining substitute, sounds like a still better idea.
Received on Sunday, 23 May 2010 12:28:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:46 UTC