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

Re: Proposed change to spec on object tag

From: Simon Pieters <simonp@opera.com>
Date: Fri, 25 Apr 2014 14:43:16 +0200
To: "Charles McCathie Nevile" <chaals@yandex-team.ru>, "Greg Davis" <greg.davis@pearson.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.xevhme2midj3kv@simons-mbp>
On Fri, 25 Apr 2014 10:10:23 +0200, Greg Davis <greg.davis@pearson.com>  
wrote:

> 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.

That is a solution. What is the problem?

You can read the param elements yourself same-origin already.

> 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.

If the pages are same-origin, you can do this yourself.

> 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.

"more semantic" doesn't really help your case, sorry. :-)

> Second, it offers a way to gracefully degrade, whereas
> in an iframe the embedded object itself must handle the degradation.

It would only degrade in future UAs that support your suggested feature,  
so that's not so graceful.

> 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.

Actually audio and video are more similar to iframe than object in this  
regard. The element's content is never shown to the user in UAs that  
support audio/video/iframe.

> 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.

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.

-- 
Simon Pieters
Opera Software
Received on Friday, 25 April 2014 12:43:48 UTC

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