W3C home > Mailing lists > Public > public-html@w3.org > April 2014

Proposed change to spec on object tag

From: Davis, Greg <greg.davis@pearson.com>
Date: Wed, 23 Apr 2014 11:57:43 -0600
Message-ID: <CANnhi750syv-Mj3MdoMJ13ALeZPbCPxa_V-kuhOgC1b5OH_=Tg@mail.gmail.com>
To: public-html@w3.org
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.
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
Received on Wednesday, 23 April 2014 17:58:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:38 UTC