W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2008

[Bug 5846] Accessing Object Parameters from an Embedded SVG

From: <bugzilla@wiggum.w3.org>
Date: Thu, 10 Jul 2008 17:15:26 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1KGzjq-0000oQ-EP@wiggum.w3.org>


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch>  2008-07-10 17:15:26 ---
> 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.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 10 July 2008 17:16:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:00:45 UTC