Re: Proposed change to spec on object tag

Thanks for the response, Chaals.

Specifically, what I'm thinking is a case where I embed an HTML page
with the object tag and pass it parameters via the param tags, and the
embedded page can access those params via a js API. Likewise, the
embedded object could communicate back up to the parent whether or not
the js is able to fire correctly, and the parent would be able to
gracefully degrade to a fallback element.

The things that this does are two fold in my mind. First, it
represents the parameters in a much more semantic, human readable way
than an iframe. Second, it offers a way to gracefully degrade, whereas
in an iframe the embedded object itself must handle the degradation. I
think it's very much in line with the way that audio and video tags
are being done, so that the degradation is handled in a much more
declarative way.

I've been doing a lot of working around embedding widgets in epubs,
and when we handle a diverse range of browsers, reading situations and
rendering engines, this would be a great way to author embedded
widgets and easily understand and see what they're doing.

-Greg

> On Apr 25, 2014, at 1:57 AM, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:
>
>> On Wed, 23 Apr 2014 19:57:43 +0200, Davis, Greg <greg.davis@pearson.com> wrote:
>>
>> Hello all,
>> I'd like to propose a change to the spec on the HTML object tag.
>>
>> Right now as it stands, the object tag is aimed at using non-HTML scripted content. That content has access to the param tags within that
>> object and is able to render itself based on those parameters. It also
>> provides the ability to have a fallback image or content if the type of
>> object embedded is not supported.
>>
>> A new use case is using object tags to embed HTML/JS content that may not
>> play nice with the parent page or need to be otherwise sandboxed. This can be done either via iframe or object, with parameters passed in via
>> the URL.
>
> To understand this better:
>
> Currently, an iframe has a src URL, which can include parameters. It is possible for the parent page to change the src URL, and therefore the parameters.
>
> And you can use postMessage to pass information.
>
> Object has param elements.
>
> Are you looking for something that takes an item in the DOM of the parent document which is not normally rendered, and enabling it to be updated live by the parent and accessed by the embedded object?
>
> What such an API looks like is probably easy to decide if we know why we need it, but it is unclear to me when you would use this. Is there something specific you would like to do that iframe doesn't support nicely?
>
> cheers
>
> Chaals
>
>> I propose that the object tag be augmented, so that the embedded HTML doc
>> can access, via JS in conformance with same-origin policies, the param tags within the object tag. There should also be an api available to communicate back to the parent window if the embedded object is
>> un-displayable, so the fallback can happen gracefully.
>>
>> The object tag is much more semantic in nature with the way it passes
>> parameters in, and I think it makes sense in the move towards having a
>> totally declarative web to have this feature available.
>>
>> I would propose that the API looks something like this:
>>
>> window.parent.receiveParam() -- this would return a serialized array:
>> [
>>  {
>>    name : "foobar",
>>    value : "foobarVal"
>>  },
>>  {
>>    name : "foobar2",
>>    value : "foobar2Val"
>>  },
>>  ...
>> ]
>>
>>
>> and that the object could return a status like this:
>>
>> window.parent.objectValidation({
>>  id : param.id,
>>  runs : true
>> })
>>
>> If no status is returned, then the object is assumed to be properly
>> supported and it displays. If falsey then it uses the fallback content.
>>
>>
>> Thoughts? Interest in this?
>>
>> Thanks,
>> -Greg Davis
>
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>      chaals@yandex-team.ru         Find more at http://yandex.com

Received on Friday, 25 April 2014 08:10:49 UTC