SVG Clock: Conclusion
With a little bit of math knowledge, this was an extremely easy script to write. I personally can't wait until SVG becomes mainstream just so I can see more of these effects. Unlike Flash, people can learn by looking at other people's code.
Just to sum things up, here is the "correct" version, the ASV-friendly version, and the Mozilla version. Also, the stylesheet used to style the clock.
It is possible with a small hack to get the same file working in both renderers, but may screw over a 3rd renderer. Since ASV doesn't understand the JS, and Mozilla doesn't understand the script element, you could put the ASV-only code in the SVG-namespaced script element, and the correct code in an XHTML-namespaced script element. In this one case, the renderers are mutually exclusive in which one it uses. However, if a third, completely correct rendered came along that understood XHTML namespaces, there will be some conflicts. Ultimately, if the XHTML-namespaced script was last, I believe the "bad" functions would be overwritten and everything would work out, but it would be ugly.
Some related links:- Once again, WebFX pulls through with a clock written in VML. I hate VML with a passion, and it doesn't have a future on the web, but you got to give credit where credit is due. Instead of using polar coordinates to change the line endpoints, they just rotated the hands. Another approach to the same problem, and SVG handles it just as easily.
- Probably the only time I'll ever link to something on Dynamic Drive, I think this DHTML clock is quite impressive, and does an excellent job of showing why HTML shouldn't be used for such things ;-). Many props to the author though, he did a fine job overcoming inherent problems with trying to fit a square peg into a round hole.
So, go forth and animate! (Using SVG of course). If you have a neat SVG animation, let me know at davisj@mssm.org. I love these sorts of things.
Back: Compatibility