- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 21 Feb 2012 16:18:36 +0100
- To: www-style@w3.org
On 02/16/2012 01:27 AM, Tab Atkins Jr. wrote: > On Wed, Feb 8, 2012 at 9:15 AM, Kang-Hao (Kenny) Lu > <kennyluck@csail.mit.edu> wrote: >> 3.2. Image Fallbacks and Annotations: the ‘image()’ notation >> >> # So that authors can take advantage of CSS's forwards-compatible parsing >> # rules to provide a fallback for image slices, implementations that >> # support the ‘image()’ notation must support the xywh=#,#,#,# form of >> # media fragment identifiers for images. [MEDIA-FRAGS] >> >> Is this what implementers are planning to do? It it is, there's nothing >> I would complain. If it is not, as the feature of media fragments seems >> to be heavier than than feature of image fallback, it seems enough here >> if we only require "implementations that support the 'image()' notation >> but not xywh=#,#,#,# must treat such URL as a 404 image" so Example 4: >> >> # background-image: url('swirl.png'); /* old UAs */ >> # background-image: image('sprites.png#xywh=10,30,60,20'); /* new UAs */ >> >> can be written as >> >> | background-image: url('swirl.png'); /* old UAs */ >> | background-image: image('sprites.png#xywh=10,30,60,20', 'swirl.png'); >> | /* new UAs that support fallback image. Might or might not support >> media fragment */ >> >> What are implementers' plans here? > > I don't know about impl plans, but if they aren't planning to support > media fragments in the very near future (in the next 3-4 months, I'd > say), then I like your suggestion to at least force browsers to > *recognize* media fragment URLs and explicitly fail to understand > them. That's the whole reason for the requirement, after all. I think I'd rather gate image() on media fragments than make authors write their fallback URL twice in order to get good fallback behavior. image() doesn't have anything that impressive to offer, afaict, other than media-frags, which gets authors non-hacky spriting. Note, Mozilla has implemented MF functionality with a different syntax: https://developer.mozilla.org/en/CSS/-moz-image-rect IIRC this was at least partly because MF was in early draft stages when that was implemented and also because they wanted to take advantage of CSS fallback parsing. That said, I wouldn't mind specifying that if the UA can't intepret a fragment identifier specified in image(), it should treat that as an unknown image. It would allow us to use image() for fragment-identifier fallbacks in the future. :) ~fantasai
Received on Tuesday, 21 February 2012 15:19:06 UTC