- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 22 Feb 2012 09:43:23 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style@w3.org
On Tue, Feb 21, 2012 at 6:30 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > -moz-image-rect() is not really generic in Mozilla; it only applies to > background-image, not to other places images might be used in CSS (most > notably, 'content'). Extending it to 'content' would be pretty nontrivial. Presumably it should be identically usable in the other <image>-using properties besides 'content', right? That seems like a limitation imposed solely by the original patch being incomplete, not by the feature actually being difficult to implement for other properties. What makes it hard to use in 'content'? >>>> it looks like a Gecko implementation of the current image() >>>> spec would be pretty easy. >>> >>> >>> I wouldn't assume that. >> >> >> Can you elaborate? > > Well, for example to sanely handle situations where people have lots of > references the same image with different fragment identifiers (a situation > that never comes up now) may well require some changes to the image library > and image cache in Gecko. That's off the top of my head; it may depend on > the exact implementation strategy chosen and such of course. > > Then again maybe you and I just have different thresholds of "pretty easy"? > Mine tends to be counted on hands (ideally no more than one) in > engineer-days... It's reasonable that a *good* implementation would take more time. We have a similar difficulty. I'm curious what the use-case for -moz-image-rect() was in the first place, if not precisely what you describe (lots of references to the same image with different rects). But you already have implemented the *exact* user-facing behavior that the #xywh=... fragment has, so at minimum you could just reuse that. ~TJ
Received on Wednesday, 22 February 2012 17:44:10 UTC