Re: Proposed change to spec on object tag

Okay, I'm going to try this again and see if I can make more sense... I did
some testing and thinking and have a more complete thought now :)

Problems:
Object tags work to embed HTML docs, but the way to access the contents of
the param tags does not work gracefully, especially cross-domain. The
current work around includes setting up a messaging bus where the parent
window listens for the framed element to ask for it's parameters and then
sends back an object of the serialized params in a similar message, all
using window.postMessage(). The biggest limitation is that (as of yet) I'm
unable to find a way to reference the object that is sending the message,
making it difficult to have more than one object tag on a page performing
this type of communication. In addition, the child window is unable to
communicate back that it has experienced a failure for some reason and
trigger the use of the fallback element (mainly because of the inability of
postMessage to reference the source frameElement cross-domain).

Use:
Embedding self-controlling widgets within HTML pages (specifically epub3
documents which require embedding as part of the spec), passing complex
objects as parameters that would be too long to include in a URL for an
iframe as well as controlling the ability of content authors to display
fallback content without having to modify the included widget.

Proposal:
An API, somewhat like window.postMessage(), to get the parameters from an
embedded object in a simple, cross-domain supported way. Something like
window.parent.getParams(), which returns a serialized array of the
parameters in the parent element. Also, an API to communicate failures back
up, like window.parent.supported(boolean). Proposals are based on my
fractured understanding of browser architecture, so please forgive my
overly simplistic thoughts on that.

Security:
Not sure here... it seems like it should be a fairly harmless thing to pass
these params back, but at the same time I've got a weak understanding of
these concerns. Could it use the cross-origin headers from the server(s) to
allow access?

Fallback:
Could be shimmed with javascript until it's fully supported by setting up a
two-way bus that assigns a unique id to each element, allowing the widget
and consuming page to be aware of it's own context.

Thoughts?

-Greg Davis



On Mon, Apr 28, 2014 at 2:10 AM, Simon Pieters <simonp@opera.com> wrote:

> On Fri, 25 Apr 2014 17:21:21 +0200, Davis, Greg <greg.davis@pearson.com>
> wrote:
>
>  Really!? Could you expand on this? I wasn't aware that it was currently
>> possible... seems like a silly conversation if I can already do it :)
>>
>
> I meant, what you described is a proposed solution to some problem, but
> you didn't describe the problem well before going ahead and proposing a
> solution. This makes it impossible for others to evaluate the proposal.
>
>
>   Wow... obviously I'm ignorant on what you can do with the object tag...
>> if
>> I told you how many hours I'd spent trying to figure this out :-(
>>
>
> I meant that you can implement your proposal in JS today. You can access
> the parent <object> element using window.frameElement, and from there you
> can iterate over the <param> elements. To make an <object> element fall
> back, you can add a classid attribute with a bogus value, or remove the
> classid/type/data attributes. If you want to do that when some script fails
> to compile or fails to catch an exception, use window.onerror.
>
>
>
>  Can you point to some concrete examples that would benefit from your
>>> proposal?
>>>
>>> FWIW, <object> is so complicated already because it does too many
>>> different things that we've tried to avoid extending it and are still
>>> struggling with interoperability, so it may be hard to convince browsers
>>> to
>>> complicate it further.
>>>
>>
>>
>> So does it stand as a tag to avoid for the use I'm describing then?
>>
>
> I'd still like to understand better what the use is, exactly.
>
>
>  We've
>> been having conversations at the IDPF (standards org for ePubs) about
>> this,
>> and everyone in the group favored using object tags if they "worked
>> better", but now I'm feeling like we are all victims of a lack of
>> documentation... and if everything I'm saying is doable same-origin, then
>> it would work fine as described right now, since everything in an ePub is
>> same origin.
>>
>
> OK.
>
>
> --
> Simon Pieters
> Opera Software
>



-- 


*Greg Davis*UX Prototyping

*Pearson*

Always Learning
Learn more at www.pearson.com<https://mail.ecollege.com/owa/redir.aspx?C=4f920a44870947f4bb154392a08797c5&URL=http%3a%2f%2fwww.pearson.com>