This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5846 - Accessing Object Parameters from an Embedded SVG
Summary: Accessing Object Parameters from an Embedded SVG
Status: VERIFIED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://lists.w3.org/Archives/Public/w...
Whiteboard:
Keywords: NoReply
Depends on:
Blocks:
 
Reported: 2008-07-09 13:54 UTC by Hallvord R. M. Steen
Modified: 2010-10-04 14:30 UTC (History)
9 users (show)

See Also:


Attachments

Description Hallvord R. M. Steen 2008-07-09 13:54:57 UTC
Given 
  <object data="http://some.other.domain/example.svg" ><param
name="foo" value="bar"/></object>

- there should be a standardised way a script running inside an embedded SVG can access any parameter name/value pairs from the OBJECT tag that embedded it.

- suggestion is to standardise an object named window.paramList (name up for debate of course) with name/value mappings for PARAM and attributes of parent object.

- window.paramList needs only be defined when the window object belongs to content loaded with the OBJECT tag?

- window.paramList should be enumerable.
http://lists.w3.org/Archives/Public/www-dom/2008JanMar/0012.html
Comment 1 Ian 'Hixie' Hickson 2008-07-09 21:16:20 UTC
What's the use case? Would this also apply to HTML content? Would it apply cross-site? Why do query parameters not handle this?
Comment 2 Hallvord R. M. Steen 2008-07-10 13:03:27 UTC
> What's the use case?

Simplifies passing data to a script inside an embedded SVG graphic or other embedded document.

> Would this also apply to HTML content?

I see no reason to limit it to SVG. Scripts in any type of document embedded by an OBJECT might be interested in the PARAM tags of that object.

> Would it apply cross-site?

Yes. That is one of the important use cases, because it is the one we can't work around now (scripts in child documents from the same origin could always investigate the DOM of their parent to find PARAMs) and indeed this use case was the reason the mailing list thread was started.

> Why do query parameters not handle this?

Query parameters is an alternative. However, there are limits to how much data you can pass in a URL, and it introduces unneccessary URLencoding/decoding requirements. 

Also, not adding this feature makes <PARAM> useless in cross-domain embedding scenarios. I think this seems like an oversight in the spec since the author's intention when specifying PARAMs presumably is to make those parameters available to the embedded content. We already have this working for plugins (also cross-domain) but we don't have it for natively supported content.

Hixie, I hope this answers the questions so I revert the bug from NEEDSINFO state. Thanks for following up.
Comment 3 Ian 'Hixie' Hickson 2008-07-10 17:15:26 UTC
> Simplifies passing data to a script inside an embedded SVG graphic or other
> embedded document.

That's what it does, but what's the use case? Who would use this? Is this a proposal based on something that would directly benefit some site?


> Yes. That is one of the important use cases, because it is the one we can't
> work around now (scripts in child documents from the same origin could always
> investigate the DOM of their parent to find PARAMs) and indeed this use case
> was the reason the mailing list thread was started.

postMessage() is intended for cross-site communication.


> Also, not adding this feature makes <PARAM> useless in cross-domain embedding
> scenarios.

Having things in the language that aren't always useful isn't a problem.


> I think this seems like an oversight in the spec since the author's
> intention when specifying PARAMs presumably is to make those parameters
> available to the embedded content. We already have this working for plugins
> (also cross-domain) but we don't have it for natively supported content.

Is there any evidence showing that people actually _do_ specify <param>s for HTML and SVG objects?


Marking WONTFIX since there doesn't seem to be a compelling reason to do this. Completeness isn't compelling, we have much bigger fish to fry.
Comment 4 Jeff Schiller 2008-07-10 23:32:02 UTC
Well, since the question was originally asked by me, yes it would directly benefit my site by allowing me to write cleaner code (for instance, the menu.svg can sit at www.codedread.com and can be self-contained and the referencing page can send in parameters at the markup level).  I suppose that won't be considered important enough though.

At the moment, I'm using a Unix softlink at blog.codedread.com to the menu.svg, which obviously wouldn't work if things were truly on a different domain.  I haven't investigated query parameters or postMessage() - do they work in all browsers?

Seems really weird to me that we have parameters that you can send to objects, but only the objects located in the same domain can actually access those parameters.  But I thought that Java and Flash plugins can actually get at those parameters - I guess it just leaves native content out in the cold?  That seems even weirder...
Comment 5 Jeff Schiller 2008-07-11 02:52:35 UTC
1) Query Parameters.  Can someone point me to documentation on these?  Can someone also clarify whether query parameters force browsers to fetch a new copy of the document?  (PHP URL arguments do, so that's why I'm asking).  This would seem to be a reason NOT to use query parameters as they would be inefficient (ideal to only have one copy of the SVG document in the browser cache and not do multiple HTTP requests).

2) Here are some Use Cases:

a) SVG Text labels that are populated via object parameters

<object data="http://openclipart/funkyWordArt.svg">
  <param name="theText" value="Hello World!"/>
  <param name="fillColor" value="PapayaWhip" />
</object>

b) Link targets in the SVG that are configurable.  Embed clip art into my site and parts of the image link to different things depending on the page that embedded the clip art.  I can see MANY uses for this, like a 'bug' image that links to a specific bug 
  <object data="http://openclipart/bug.svg">
    <param name="theLink" value="http://bugzilla/bug1234" />
  </object>
  <object data="http://openclipart/bug.svg">
    <param name="theLink" value="http://bugzilla/bug5678" />
  </object>

c) Allow the embedding document to specify a stylesheet to use for the SVG

3) Evidence.  "Is there any evidence showing that people actually _do_ specify <param>s for HTML and SVG objects?"

This seems an odd question to me.  Since it is currently not possible to do this across domains, obviously NO ONE is doing that.  If the linked SVG doc is in the same domain, it is possible to navigate from SVG DOM to HTML DOM without security issue, so there is not as much reason to use <param> objects, you can communicate using a variety of mechanisms.


Since I don't seem to have Bugzilla permissions, I wonder if someone could reopen the bug to NEEDSINFO again.  Thanks.
Comment 6 Hallvord R. M. Steen 2008-07-16 09:39:47 UTC
> Is there any evidence showing that people actually _do_ specify
> <param>s for HTML and SVG objects?

No. I looked and I could not find any. However, there is not much authoring practise on HTML+SVG OBJECTs on the web yet. Points to consider:

 * This issue comes from an author request. An early deployer points out that the spec has a hole because he fell into it - counts for something, no?

 * While there is no such HTML+SVG usage that I could find, the proposed feature is very similar to Flash's "flashvars" PARAM. There's precedence for simplifying "markup -> script inside OBJECT" communication when you consider <param name="flashvars"> and this is very, very common in real-life usage.

Using postMessage here seems like a lot of overhead and "scaffolding" for a very simple use case.

> Completeness isn't compelling

I agree with that. I think feature parity with plugin implementation matters though - including comparing SVG features to Flash features.

I take the liberty of re-opening this again, I hope you find the arguments compelling enough for another consideration..
Comment 7 Ian 'Hixie' Hickson 2008-07-16 19:56:45 UTC
(In reply to comment #5)
> 1) Query Parameters.  Can someone point me to documentation on these?

They're the "?xxx" part of URLs. See RFC3986. You can obtain them from the location.search attribute in HTML5. Changing them on the fly requires reloading, but if you're doing on-the-fly changes then that's exactly what postMessage() was designed for, so use that.


> a) SVG Text labels that are populated via object parameters
> 
> <object data="http://openclipart/funkyWordArt.svg">
>   <param name="theText" value="Hello World!"/>
>   <param name="fillColor" value="PapayaWhip" />
> </object>

That's not a use case, it's an example of how it could be used. What I mean by use case is an actual example of an actual site that is currently working around the lack of this feature, or that would be able to do something dramatically better if this feature was available.


> b) Link targets in the SVG that are configurable.  Embed clip art into my site
> and parts of the image link to different things depending on the page that
> embedded the clip art.  I can see MANY uses for this, like a 'bug' image that
> links to a specific bug 
>   <object data="http://openclipart/bug.svg">
>     <param name="theLink" value="http://bugzilla/bug1234" />
>   </object>
>   <object data="http://openclipart/bug.svg">
>     <param name="theLink" value="http://bugzilla/bug5678" />
>   </object>

Just use query arguments:

   <img src="http://openclipart/bug.svg?http://bugzilla/bug5678" alt="Bug 5678">

...or even better, so that the page remains accessible to all users:

   <a href="http://bugzilla/bug5678"><img
      src="http://openclipart/bug.svg?http://bugzilla/bug5678"
      alt="Bug 5678"></a>


> c) Allow the embedding document to specify a stylesheet to use for the SVG

<iframe seamless> does this now, if you want the parent stylesheet to cascade in. If you don't, just use query parameters. They work today.


> 3) Evidence.  "Is there any evidence showing that people actually _do_ specify
> <param>s for HTML and SVG objects?"
>
> This seems an odd question to me.  Since it is currently not possible to do
> this across domains, obviously NO ONE is doing that.

Ok, so we don't _have_ to do it. Now the question is, does providing this offer a compelling solution to something that otherwise wouldn't be possible? As far as I can tell, the answer is "no".

(In reply to comment #6)
> * This issue comes from an author request. An early deployer points out that
> the spec has a hole because he fell into it - counts for something, no?

It's good feedback to have, but realistically we need much more than a single request to justify adding a feature, especially for something that has very little uptake in the first place (like SVG) and that has workarounds (like query parameters and postMessage()).


> * While there is no such HTML+SVG usage that I could find, the proposed
> feature is very similar to Flash's "flashvars" PARAM. There's precedence for
> simplifying "markup -> script inside OBJECT" communication when you consider
> <param name="flashvars"> and this is very, very common in real-life usage.

It isn't clear to me that flashvars are the best solution to this for Flash either.


> Using postMessage here seems like a lot of overhead and "scaffolding" for a
> very simple use case.

In the case of merely sending static data, I agree; query parameters are the way to go for that. They allow the server to statically update the file as well as allowing the SVG file itself to read the data.


> I agree with that. I think feature parity with plugin implementation matters
> though - including comparing SVG features to Flash features.

Feature parity is not a goal. Making the platform useful and powerful is the goal, with the high priority items getting the first chance.

I'm marking this WONTFIX again because until such time as there really is a lot of SVG out there I don't think it makes sense to worry about this. The only cost of the query syntax is caching, and it is far too early to worry about that kind of optimisation for a technology as young as SVG-in-HTML, IMHO.
Comment 8 Jeff Schiller 2008-07-16 22:48:48 UTC
"That's not a use case, it's an example of how it could be used. What I mean by
use case is an actual example of an actual site that is currently working
around the lack of this feature, or that would be able to do something
dramatically better if this feature was available."

Use Cases should not be limited to only 'actual examples', especially since that limits your use cases to things that are only currently achievable.  But in the interest of continuing the discussion...

I've already mentioned that my own site wants to use this and I've worked around this missing feature.  See the menu.svg object at codedread.com.  The way I worked around it was by making a soft-link on my webserver so that the pages appear to be on the same domain.  Since I don't have SSH access to my webserver, the way I had to make this soft link was to create a special PHP file which would do the soft-link for me (one time).  What a pain.  What a virtual non-starter for non-technical users to do such things.  What a literal non-starter for files on truly different domains/web servers.

Google AdSense is another example.  Instead of including a single HTML file from Google's servers and then sending it parameters, I have to monkey around with script elements, whose JS variables pollute my scripting space.  Then I have to include a 21kb script in my page for every ad (http://pagead2.googlesyndication.com/pagead/show_ads.js).

"it is far too early to worry about that kind of optimisation for a technology as young as SVG-in-HTML"

We shouldn't call this "SVG-in-HTML", since that term is typically used to refer to inline SVG within text/html.  This problem exists with referenced SVG/HTML content in HTML or XHTML.
Comment 9 Ian 'Hixie' Hickson 2008-07-16 23:27:33 UTC
The menu.svg example is not a good example, since it is mixing layers (you have presentation stuff at the semantic layer -- just look at your site with CSS disabled to see what I mean). XBL would be a better solution for this kind of thing.

Google Adsense is also not really a good example -- in all my discussions about HTML5 with the Adsense teams, this has never been an issue they have mentioned as wanting fixed in this way. Even if we did want to use an explicit frame instead of script to embed the ads, we would (for various reasons) use an <iframe>, not <object>, and thus wouldn't be able to use <param> anyway.

I hate to be dismissive like this, but I really am not convinced that this is something that is of enough importance to add to HTML5.
Comment 11 Maciej Stachowiak 2010-03-14 13:15:09 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 12 Hallvord R. M. Steen 2010-03-15 22:19:55 UTC
Had forgotten about this bug - but the omission still bugs me when I look at it again :-p. 

I think this *will* be a common requirement for SVG usage on the web - regardless of whether you think flashVars is a good solution its usage is extremely common, and so is the use cases for it. (BTW flashVars can be used either as query string - example.swf?foo=bar or as a param - the latter was obviously added to make sure SWFs can be cached.)

Example use case:
 * SiFR replacement SVG
 * SVG graphic hosted on some content server
 * Trivial JS inside the SVG inserts text from parent page through the SVG's DOM

Query string is not an acceptable workaround. We might have a document with many headlines - loading that SVG 20 times is just silly when once would do.

I'm not stubborn enough to reopen the bug though.
Comment 13 Maciej Stachowiak 2010-03-15 23:54:26 UTC
(In reply to comment #12)

> 
> Query string is not an acceptable workaround. We might have a document with
> many headlines - loading that SVG 20 times is just silly when once would do.
> 

What about fragment identifier? That doesn't requiremultiple loads and it works in contexts other than <object>.
Comment 14 Hallvord R. M. Steen 2010-03-16 00:21:46 UTC
Fragment id is not a bad idea actually. You may run into nasty URL encode/decode issues where current browsers differ (Gecko bug), but it sounds like a solution that is simpler than window.paramList. Jeff, thoughts?