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