My suggestion would be to simply can the CSS sprite mapping altogether and use only SVG. I was able to come up with a (self-proclaimed) ingenious method for sprite mapping in SVG. I would love to link my finished copy but my server is currently on the fritz so I'll try to explain the best I can.
First you create a <pattern> out of your sprite image (i may be forgetting some required attributes so forgive me): <!-- width and height correspond to the dimensions of your sprite image --> <pattern id="spritemap" x="0" y="0" width="100px" height="100px"> <image width="100px" height="100px" xlink:href="spritemap.png" /> </pattern> OK, fancy! Now, whenever you use the pattern, imagine that it is "behind" the SVG and that you have to cut "holes" through in order to map the sprites. You can use any shape but I will use <rect> for the sake of simplicity. You will create these shapes in a <defs> section because you *have* to translate the rect afterwards to where you want it because its xy coordinates are going to refer to the spritemap and *not* to where you want it to be. So the following example assumes that the sprite you want is at (25px, 25px) on your spritemap and that the sprite is 10px by 10px: <defs> <rect id="sprite1" x="25px" y="25px" width="10px" height="10px" fill="url(#spritemap)" /> </defs> Awesome, you now have your sprite defined! Now simply throw it wherever you want it on your page with <use>! <use id="mysprite" x="150px" y="300px" xlink:href="#sprite1" /> I hope this helps you with your problem. On Thu, Jan 5, 2012 at 4:31 PM, David Dailey <[email protected]>wrote: > ** > > > As I zoom in (using CTRL +), I see what you mean. Opera also, then does not > show the proper hover effect (rolling over to the original image). > > I don't see what you mean though at regular levels of zoom. > > Certainly this is a bug in at least some browsers, if not an > underspecification by the spec - these areas of HTML-CSS-SVG interaction > seem to be rather frontiersy at present. > > I have found a goodly number of examples recently in which the degradation > of vectors into pixels happens with exactly the opposite ordering (Opera > best, Chrome/Safari worst), and that is staying within the relatively > civilized parts of SVG (like filters and patterns and so forth). > > I find that one must almost be a member of an implementation team to figure > out where in "the spec" something might be covered. HTML5 has, it seems, > popularized the notion that one should read at least six specs (HTML5, DOM, > DOM events, CSS, SVG and XFORMS) before one can figure out if something is > consistent with the spec or not, but if it were otherwise, what would we > have to grouse about? > > In your case, I think it has to do with the way browsers are left to their > own devices for zoom level specification - when you say > > #wrapper{position:absolute; padding:1em 1em 0 2em; top:20px; > left:100px;width:300px; background:lightgrey url(spriteN.svg) 3px 30px > no-repeat; border-radius:.5em;} > > #wrapper:hover{background-position:3px -160px} > > It looks like you are just changing the locus of the background rather than > changing the url of the image, and browsers seem to be left to their own in > terms of how pan and zoom are specified, which means, I think, that you'd > have to script this, to get them all to agree. > > Rather than handling this sort of animation through CSS sprite sheets > ( > http://en.wikipedia.org/wiki/Sprite_%28computer_graphics%29#Sprites_by_CSS > ) as you have, which has the advantage of all drawings being in one file, I > would probably have tried to mimic the effect by doing it all in SVG > (including the CSS) with all instances of the image being at the same > locus, > but with their display (none or block) being triggered by mouse hover . > > Better yet, use SVG-SMIL which works pretty consistently everywhere where > it > is implemented and don't worry about the three years it will take the > browsers and the various specs to see eye-to-eye on CSS-HTML-SVG > communication. Of course that leaves out the one browser that doesn't do > SMIL, but they have said that they're just waiting for people to use SMIL > before they implement it ;) (isn't that what they said?) > > Cheers > > David > > From: [email protected] [mailto: > [email protected]] > On Behalf Of Andreas > Sent: Thursday, January 05, 2012 3:26 PM > To: [email protected] > Subject: [svg-developers] Scaling behaviour and the browser > > > I 've created a simple SVG-Sprite and use this via CSS as a background: > http://dl.dropbox.com/u/1088569/svgsprite.html > > If I scale the file, I notice different behavior in browsers. > Only Chrome (and maybe Safari(but i'm not tested this)) show a behaviour > that i expected. Opera and Fox show it blurred as any other non-vector > images. > > Is this a bug or a feature? > > [Non-text portions of this message have been removed] > > > [Non-text portions of this message have been removed] ------------------------------------ ----- To unsubscribe send a message to: [email protected] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
