- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Thu, 7 Jul 2011 12:34:52 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Yves Lafon <ylafon@w3.org>, Raphaël Troncy <raphael.troncy@eurecom.fr>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, "public-media-fragment@w3.org" <public-media-fragment@w3.org>
On Jul 7, 2011, at 12:01 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Thu, Jul 7, 2011 at 12:51 AM, Yves Lafon <ylafon@w3.org> wrote: >> On Wed, 6 Jul 2011, Tab Atkins Jr. wrote: >>> 2011/7/6 Raphaël Troncy <raphael.troncy@eurecom.fr>: >>>> Following these >>>> discussions, we have added the following sentence to the spec: >>>> >>>> "Note that in the case of pixel-based clipping areas, application of >>>> those >>>> areas to multi-resolutions visual media is undefined." >>>> >>>> in the section 4.2.2 [2]. >>> >>> What's the reasoning for making it undefined? If it's just "it's >>> hard", then I don't find that acceptable. >> >> For percent-based clipping fragments, it makes sense at all resolutions (but >> perhaps having them integer-based is sub-optimal in many cases), but for >> pixel-based ones, it is impossible to know the intent. >> Does the format as a "default" version to apply the pixel clipping to? the >> first one? last one? bigger one? The one that fit the display? >> So it's not that it's hard, I just don't see how this could work reliably. > > I agree that it's difficult to find a good answer. If we think the > problem is essentially impossible, then we should just make it > explicitly unsupported, not undefined. I agree that unsupported is better than undefined. But the fragments spec could also just define it, even if it is a bit arbitrary. For instance, I'd probably go with largest in area, then scale clipping based on relative proportions to that "largest size" of horizontal and vertical dimensions (independently) for smaller versions.
Received on Thursday, 7 July 2011 19:35:44 UTC