Re: Proposed change to spec on object tag

On Fri, Apr 25, 2014 at 6:43 AM, Simon Pieters <simonp@opera.com> wrote:

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

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 :)


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


 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 :-(


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


Good point, hadn't thought of that one...


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


So does it stand as a tag to avoid for the use I'm describing then? 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.

Thanks!


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