Mr. Schepers put together a proposal entitled Referenced Parameter Variables in SVG. This would allow declarative access to parameters from a parent document.
These types of proposals are actually just the sort of thing the SVG Interest Group should be putting out there, and I've had this particular idea for awhile, though I never put it into any concrete proposal form. I'd like to blame the fact that I ran into a stumbling block but that's not really true - it's mostly about priorities and time. Doug walks it like he talks it. That's why he's the SVG Posse.
I think Doug's proposal would be awesome for the web, allowing components to be reused by authors without requiring script or heavy technologies like XBL. It could also save on document fetches if the 'component' is cached by the browser. I could foresee technologies like ad servers using this (and I would prefer this over the script-based solutions that Google Adsense uses, for instance).
I do have some questions for Doug:
- Which takes priority: the html:object params or the URL parameters? Based on your example, it seems you prefer the object params and I think I agree.
- Are there any issues when the character encoding is different from the referencing document to the embedded document (SVG)?
- How could I send in a parameter that includes both a single quote and a double quote? Entities? Does this mean that <param name="sandwich" value="pb&j" /> renders in SVG text as "pb&j" ?
- How can I use this with svg:a elements? Think about ad servers wanting to parameterize where a link goes. To me, this is a high priority.
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.
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!)