Comments on: Pluggable SVG http://www.codedread.com/blog/archives/2009/04/14/pluggable-svg/ Tue, 17 Jan 2012 21:56:44 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Shepazu http://www.codedread.com/blog/archives/2009/04/14/pluggable-svg/comment-page-1/#comment-1250 Shepazu Fri, 17 Apr 2009 02:26:34 +0000 http://blog.codedread.com/archives/2009/04/14/pluggable-svg/#comment-1250 Thanks for the kind words. I am specifying this for SVG, but it could be used for CSS or HTML, too, if HTML ever pulls in declarative syntax. As for your questions... 1) I made the choice to prefer html:param over URL querystrings, though that's a bit arbitrary; I could see the other argument, that since param is unique to object, URLs should take precedence for greater consistency, but I think that params should have greater specificity, because they are easier to change dynamically... I wonder if there could be a hack there, such that a local page could "hijack" a URL's parameters... maybe URLs should be preferred? 2) What Laurens said. 3) Ditto. 4) We'd have to allow <a href="http://www.w3.org/TR/SVGTiny12/linking.html#IRIforms" rel="nofollow">FuncIRIs</a> as attribute values for xlink:href, like so: <param name="url" value="http://example.com/sprockets"/> ... <svg ...> <a xlink:href="url(#url)">Buy Now! This offer is unrepeatable!</a> </svg> I don't have a problem with that on the surface, and it does sound like a solid use case... thanks! (BTW, despite the name, FuncIRIs have nothing to do with 70's groove, disappointingly. Sorry, Bootsy!) Thanks for the kind words. I am specifying this for SVG, but it could be used for CSS or HTML, too, if HTML ever pulls in declarative syntax. As for your questions…

1) I made the choice to prefer html:param over URL querystrings, though that’s a bit arbitrary; I could see the other argument, that since param is unique to object, URLs should take precedence for greater consistency, but I think that params should have greater specificity, because they are easier to change dynamically… I wonder if there could be a hack there, such that a local page could “hijack” a URL’s parameters… maybe URLs should be preferred?

2) What Laurens said.

3) Ditto.

4) We’d have to allow FuncIRIs as attribute values for xlink:href, like so:

<param name=”url” value=”http://example.com/sprockets”/>

…

<svg …>

<a xlink:href=”url(#url)”>Buy Now! This offer is unrepeatable!</a>

</svg>

I don’t have a problem with that on the surface, and it does sound like a solid use case… thanks!

(BTW, despite the name, FuncIRIs have nothing to do with 70′s groove, disappointingly. Sorry, Bootsy!)

]]> By: Laurens Holst http://www.codedread.com/blog/archives/2009/04/14/pluggable-svg/comment-page-1/#comment-1249 Laurens Holst Tue, 14 Apr 2009 17:54:37 +0000 http://blog.codedread.com/archives/2009/04/14/pluggable-svg/#comment-1249 Re. question 3, entities are transparent to the underlying string, they are just an encoding format that is part of the serialisation. So yes a parameter “pb&j” results in the string “pb&j”, as demonstrated when you e.g. would do param.getAttribute('value'). Entities are only relevant when constructing documents by string concatenation or text editing. Re. question 2, I’d it is using an established system and encoding is handled through the normal existing mechanisms. I believe the URI specification dictates escaped characters within URLs be encoded as UTF-8. Re. question 3, entities are transparent to the underlying string, they are just an encoding format that is part of the serialisation. So yes a parameter “pb&amp;j” results in the string “pb&j”, as demonstrated when you e.g. would do param.getAttribute(‘value’). Entities are only relevant when constructing documents by string concatenation or text editing.

Re. question 2, I’d it is using an established system and encoding is handled through the normal existing mechanisms. I believe the URI specification dictates escaped characters within URLs be encoded as UTF-8.

]]>