Warning: include(/home/content/j/e/f/jeffschiller/html/log.php) [function.include]: failed to open stream: No such file or directory in /home/content/68/6293468/html/blog/wp-content/themes/cd2010/header.php on line 9

Warning: include() [function.include]: Failed opening '/home/content/j/e/f/jeffschiller/html/log.php' for inclusion (include_path='.:/usr/local/php5/lib/php') in /home/content/68/6293468/html/blog/wp-content/themes/cd2010/header.php on line 9
Parameterizing SVG and HTML | CodeDread Blog

Hallvord R.M. Steen (an Opera employee and member of the HTML WG) was kind enough to create a bug regarding an issue I had raised a few months back. It is currently not possible inside an embedded SVG to determine the parameters sent in from HTML:object if the two documents are on different domains. This appears to be a hole in the HTML4 spec, which doesn’t really address cross-domain security concerns for the HTML:object element.

At the moment, the issue is dead in the water. Ian Hickson suggested that query parameters could solve this issue. However, query parameters are part of the URI. In my experiments with PHP, I found that query parameters are a good way to ensure the browser actually re-fetches a document and doesn’t rely on the document in the cache. This means that using query parameters would defeat one of the purposes of parameterizing the SVG in the first place (one document in the browser cache that could be used for many purposes).

It’s sad because plugins like Flash have the luxury of being able to pass parameters into their content, but we can’t do that for content the browser understands natively (like SVG and HTML). I failed to convince the benevolent dictator that this is an important capability that the open web stack lacks.

I think this would be a nice way to turn bits of HTML/SVG into simple components without requiring script on the embedding side and without requiring heavier technologies like XBL and/or waiting for browser support of postMessage(). For example, it seems like web page authors using things like Adsense could benefit from this by not having to include foreign script in their pages, but apparently Google has no interest in this.

Eric Meyer’s link-anywhere proposal inspired me to at least float this issue in my blog in case someone else thinks it important. For now, I’m tired. Hm, I wonder if I can use the window.name hack

§478 · July 25, 2008 · Adobe, RIA, Software, Technology, Web · Tags: , , , · [Print]

5 Comments to “Parameterizing SVG and HTML”

  1. I agree that this is a feature that the HTML WG shouldn’t dismiss so quickly.

  2. Kevin H says:

    > In my experiments with PHP, I found that query parameters are a good way to ensure the browser actually re-fetches a document and doesn’t rely on the document in the cache.

    I think you need to re-run your experiment, or publish your methodology and findings so they can be scrutinized. Because the presence of a query string in a GET should not, in practice, adversely affect the cacheability of that request.

  3. Kevin H says:

    Oh, Wait!

    I think I get it now. I suspect that what you want to be able to do is the equivalent of calling url.php?caption=A and then url.php?caption=B without making 2 separate calls to the server (loading url.php out of the cache on the second fetch, and letting it process the caption=B parameter client-side). For this example usage, you are right, query strings are completely inappropriate.

    While I’m too unfamiliar with SVG to say if there is an alternate way of doing what you want, I think typically this sort of behavior is limited to <SCRIPT>

  4. @Kevin: You got it on the second try, but instead of PHP, you can do the same thing with HTML files (url.html?caption=A) meaning parameters can be processed by JS in the browser.

  5. Update: Apparently browsers send in the attributes of the <object> element to the plugin as well the <param> elements. HTML 5 favors the plugin over the native content handler even more than I thought it did before.