3 ms·

From reading the spec, the problem with SVG is that it is very difficult to implement completely due to the all-encompassing rendering model, javascript integra

From reading the spec, the problem with SVG is that it is very difficult to implement completely due to the all-encompassing rendering model, javascript integration and animation scripting. This makes it difficult to read and write, without pulling in half a browser, and next to impossible to edit fully, unless using a text editor. So if we do see more adoptions, it's quite likely they'll either end up incompatible with each other or some consensus on a work-able subset of SVG is reached. Perhaps if W3C had done a reference implementation much like, say, H.264 has reference implementations, some of this could have been avoided? I'd enjoy reading opposing views on this, interesting topic.

indypb 14y ago
http://www.w3.org/Amaya/ http://www.w3.org/Amaya/ is a kind of reference browser from the W3C. The release history lists the first SVG support in Amaya 4.0 from 10 November, 2000.
- jarek-foksa 14y ago
  Amaya does not render correctly the most basic SVG files. Even IE6 would make a better reference implementation of web standards. Batik seems to be the most well-tested and conformant implementation of SVG at the moment: http://xmlgraphics.apache.org/batik/status.html http://xmlgraphics.apache.org/batik/status.html, though I would use WebKit as reference because of it's market share and potential of Google and Apple to change the SVG spec.