My OperaThis topic has been closed. No new entries allowed.
Reason: You can now post comments on articles on Dev Opera
You need to be logged in to post in the forums. If you do not have an account, please sign up first.
How to do photoshop-like effects in SVG
Wanna add some polish to your site, the standards way? In this article Erik shows how you can save time and money on creating graphics and effects programmatically using SVG instead of doing them all manually using Photoshop.( Read the article )
Hey, this looks very nice!
Thanks for the inspiration, this is really a good example for intelligent use of SVG in modern web pages.
I just noticed two problems with the hover effect (Opera 9.5beta on Linux): The blue highlight ellipse isn't clipped to the button area, and it's above the text, which makes it lesser readable. (The clipping seems to work fine in rsvg, though.)
And then, normally I would use scripting for such simple mouseover effects, but declarative animation. But since Opera is the only browser with quite complete animation support, currently it may be wiser to choose scripting. However, Batik seems to have problems with you script. Maybe you could test it in Batik, too? It's currently one of the best (and strictest) SVG implementations out there, so if it runs in Batik without problems, it should run everywhere.
Thanks for the inspiration, this is really a good example for intelligent use of SVG in modern web pages.
I just noticed two problems with the hover effect (Opera 9.5beta on Linux): The blue highlight ellipse isn't clipped to the button area, and it's above the text, which makes it lesser readable. (The clipping seems to work fine in rsvg, though.)
And then, normally I would use scripting for such simple mouseover effects, but declarative animation. But since Opera is the only browser with quite complete animation support, currently it may be wiser to choose scripting. However, Batik seems to have problems with you script. Maybe you could test it in Batik, too? It's currently one of the best (and strictest) SVG implementations out there, so if it runs in Batik without problems, it should run everywhere.
@freedo:
The blue highlight is on top of the text yes, and I see now that's not how the original photoshop-version looked like. Good thing it's so easy to change that in the svg by moving the highlight to before the button text. I think I'll just leave that as an exercise.
About the clipping issue in 9.5beta/linux: we'll try to get that fixed for the final version, no worries.
Scripting allowed the svg source to stay a bit cleaner in this case IMHO, declarative animations are sometimes verbose in comparison. I prefer to use declarative animation when I can though.
I did test in Batik 1.7 before publishing the original article, and while it is indeed a very nice SVG implementation it doesn't implement some specifications, in this case the <a href="http://www.w3.org/TR/DOM-Level-2-Style/">DOM Level 2 Style</a> spec, which is used to do the hover effect. You may note that the SVG 1.1 spec requires complete support of DOM Level 2 Style, for more information see <a href="http://www.w3.org/TR/SVG11/svgdom.html#SVGDOMOverview">here</a>. Anyway, sans the hover effect the testcase looked just as good in Batik 1.7 as in Opera 9.
The blue highlight is on top of the text yes, and I see now that's not how the original photoshop-version looked like. Good thing it's so easy to change that in the svg by moving the highlight to before the button text. I think I'll just leave that as an exercise.
About the clipping issue in 9.5beta/linux: we'll try to get that fixed for the final version, no worries.
Scripting allowed the svg source to stay a bit cleaner in this case IMHO, declarative animations are sometimes verbose in comparison. I prefer to use declarative animation when I can though.
I did test in Batik 1.7 before publishing the original article, and while it is indeed a very nice SVG implementation it doesn't implement some specifications, in this case the <a href="http://www.w3.org/TR/DOM-Level-2-Style/">DOM Level 2 Style</a> spec, which is used to do the hover effect. You may note that the SVG 1.1 spec requires complete support of DOM Level 2 Style, for more information see <a href="http://www.w3.org/TR/SVG11/svgdom.html#SVGDOMOverview">here</a>. Anyway, sans the hover effect the testcase looked just as good in Batik 1.7 as in Opera 9.
I've made two modifications in the <a href="http://files.myopera.com/MacDev_ed/blog/vistamenu.svg">original example</a>:
1) Made the button text be on top of the blue hover shape
2) Added type="text/css" to the <style> element
That makes it work in FF3 nightlies, and also makes the text more readable.
1) Made the button text be on top of the blue hover shape
2) Added type="text/css" to the <style> element
That makes it work in FF3 nightlies, and also makes the text more readable.
Though this kinda thing is nice for repetitive maintenace and/or localization, I could still do that in Photoshop and code it up in HTML/CSS faster than doing all that code. and it doesn't take long at all to make changes. you just make the changes in photoshop and save it out. how often do navigation bars change that often anyways?
i don't know. as a designer i just feel this is too much work. it's neat that you can generate so much dynamically, but to me it's still faster to do it in photoshop.
i don't know. as a designer i just feel this is too much work. it's neat that you can generate so much dynamically, but to me it's still faster to do it in photoshop.
Originally posted by SteveD:
I could still do that in Photoshop and code it up in HTML/CSS faster than doing all that code.
But you don't actually need to code that. SVG editing applications like Inkscape can easily be used to design the actual svg image. You'd only need to add the dynamic parts afterwards.
And this method has one big advantage: the result is a scalable graphic. it looks fine at any resolution.
Originally posted by MacDev_ed:
Scripting allowed the svg source to stay a bit cleaner in this case IMHO, declarative animations are sometimes verbose in comparison.
I just tried a version without scripting. It's easily doable, ads only 7 lines, and I think it's really just a matter of subjective preferences which one to prefer. The scripted version is a bit shorter, the animated one a bit more comprehensible (and faster, I guess?).