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: svg-developers@yahoogroups.com [mailto:svg-developers@yahoogroups.com]
On Behalf Of Andreas
Sent: Thursday, January 05, 2012 3:26 PM
To: svg-developers@yahoogroups.com
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]
------------------------------------
-----
To unsubscribe send a message to: svg-developers-unsubscr...@yahoogroups.com
-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:
svg-developers-dig...@yahoogroups.com
svg-developers-fullfeatu...@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
svg-developers-unsubscr...@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
