Re: an interoperable object (fallback and context menus)

Boris Zbarsky 2009-03-25 16.31:
> Leif Halvard Silli wrote:

>> http://www.malform.no/html5/object+tiff
> 
> There's a plug-in that can handle that MIME type (QuickTime) to be 
> exact, so it's instantiated.  But NPAPI doesn't have a way to 
> communicate intrinsic sizes, and you didn't specify a size, so it ends 
> up sized 0x0.  See discussion with Robert Burns earlier in this thread.

So we must wait for a plug-in api fix, I gather.

> I can't help the fact that Youtube is suggesting silly markup; as far as 
> I can tell all those browsers have the right behavior.

You can support removing <embed> from HTML 5.

>> So the mania about always using embed seems to be based on 
>> superstition and tradition - not on what UAs support or can be made to 
>> support.
> 
> As long as you don't have to worry about older IE releases, I believe 
> this is correct.

So why do we keep it?

>>>> 1. Embed being used as "the fallback" = hinders that textual 
>>>> fallback can be added withotu disturing sighted users (unless one 
>>>> fiddles with CSS).   [...]

> To be honest, I have no idea what you're talking about here...

http://www.malform.no/html5/object+youtube

As the two first examples of that page demonstrates: When an UA 
falls back to <embed>, then any textual fallback - like a 
transcript or image description - will also by neccessity become 
visible. This we agree about as correct behaviour.

We also agree that fallback should only show when the intended 
resource fails to load.

And we know that for the <object><embed> pattern, the intention is 
to show the fallback, because <embed> is the fallback.

We also know that this pattern isn't use because one has 
corresponding fallback text.

My claim, then, is that the <object><embed> pattern has a negative 
effect on authors' and developers' perception of what <object> can 
do and how it works. (We have some evidence of this confusion, for 
example the Safari treatment of <object><embed> - see below.)

Only that day when an author needs to include some fallback text, 
will he get to experience that it doesn't work together with 
<embed>. (Though he might not realize that it is <embed> that 
causes the problem - after all, he might be used to Safari.) And 
also, because of the dominance of the <object><embed> pattern, he 
will be left to figure out how to do it right on his own.

It would be better to use a bare naked <embed> than to clad it in 
an <object>. After all, IE seem to have support for <embed> as 
well (I don't know to what extent.)

>> It is perfectly possible to embed two object elements in each other in 
>> Internet Explorer 6 - both as an outer object or as an inner object. 
>> It takes tricks.
> 
> Which makes it more complex than object+embed, so people took the path 
> of least resistance.

The path of least resistance or just the most common path?

> Last I checked, the issues were on the parser level, not just on the 
> display level, so CSS couldn't really help.  But it's been a while.  In 
> any case, the precise failure mode of IE6 here doesn't seem to matter 
> for purposes of figuring out what the spec should say, to me.
> 
>> http://www.malform.no/html5/object+youtube
>>
>> In the two first examples, Safari should have displayed the fallback. 
>> But it doesn't. IE also doesn't - but unlike Safari it doesn't hide 
>> the outer <object>.
> 
> Very interesting.  I'd love for someone who knows what's going on there 
> to comment.

Maciej, we're waiting. :-) (And Chris.)

>> One thing is <embed> in itself. But it should at least be invalid to 
>> use <embed> inside <object>. Or, at the very least, it suld be 
>> forbidden to use it as the single fallback of an <object>.
> 
> Why, exactly?

Was the explanation above satisfying?

I think we are past those days when one must do this in order to 
support both IE and other browsers simultaneously. And to continue 
to allow this only only adds to the confusion about how <object> 
works with regard to fallback.

>> More generally, <embed> only takes away attention from <object> (as 
>> well as from <video> and <audio>).
> 
> That's an argument for making <embed> use non-conformant period, no? 
> That is, defining processing, but making any page that uses it not 
> validate.

Yes.

The risk of doing that is perhaps that authors will continue to 
think that the spec is out of touch with reality. And to avoid 
that risk as much as possible, one could instead say that <embed> 
inside <object> is incorrect use. (It must perhaps be expressed a 
bit more fine grained than I have the power to right now.)

>> Where is that poster child of a web browser that is unable to handle 
>> <object>?
> 
> The problem is that it's impossible to create an <object> that will work 
> in both IE7 and, say, Gecko, last I checked.  The former requires an 
> @classid, last I checked, while the latter will fallback if it sees one. 
>  One can use nested <object> to get around this, but an <embed> will 
> Just Work across the board.
> 
> So in fact, it's not that browsers can't handle <object>; it's that they 
> handle it in such wildly different ways that using it in practice is a 
> huge pain.
> 
> As IE7 and earlier disappears from use, the situation will change, I 
> hope.  At least assuming IE8 does dispatch by type for <object>.

Above you believed that I was correct in saying that all current 
browsers can work with OBJECT.  The advent of IE7 made A List 
Apart publish an article called Bye Bye Embed.

http://www.alistapart.com/articles/byebyeembed/

In September last year, Karl found out how simple it is to embed 
Youtube videos with <object>, without any nesting at all

http://www.w3.org/QA/2008/09/howto-insert-youtube-video.html

And, had no big problems getting a QuickTime Pro video to display 
without <embed>, in both IE6, 7 and 8.

http://www.malform.no/html5/object+video/

So where is the documentation that <embed> is needed in HTML 5?

>> Some sort of check I would eventually have expected - just as I expect 
>> that one allready check MIME support. As for plug-ins, UA vendors 
>> could have "plug-in guidelines" which specified that a plug-in that 
>> handle PNGs also should be able to display transparent PNGs.
> 
> That would basically do nothing to affect plug-in behavior, unless UAs 
> blacklisted plug-ins that violate the guidelines or something...  The 
> whole point of plug-in architectures is to be a generic extensibility 
> point: to allow someone else to do whatever they want.

Guidelines are not laws. Apple is famous for their guidlines for 
how to write Mac apps. Sometimes some apps - including Apple 
themselves - break those guidelines, for better or worse. Not sure 
I see the problem.


>>> Seriously, from your perspective as a web author, is there a 
>>> difference between an NPAPI plug-in that doesn't handle the type well 
>>> and a Firefox extension that doesn't handle the type well?
>>
>> No. But I have yet to find a plug-in that that presents transparent 
>> PNGs as transparent, whether in IE or any other UA.
> 
> This should be pretty straightforward to do with a windowless NPAPI 
> plug-in.  If a plug-in is not doing that (e.g. Quicktime on Mac; I just 
> checked) then it's just buggy...

In addition to QuickTime, it is the same situation with Windows 
Media Player on Windows (but it works fine for Flash ...):

http://www.malform.no/html5/object+png+mplayer

>> But apart from that, do you agree that in case of
>>
>>   <object data="IMG.JPG"> Text 1.
>>       <object type="IN/VALID" data="IMG.GIF">Text 2.

> In this case, a UA would be perfectly allowed to fall back from the 
> inner object to the <img> without trying to load IMG.GIF.  While the 
> HTTP header does trump @type, if @type is not supported then making an 
> HTTP request is not required.  So one never even sees the HTTP header.

Ok ...

>> But is this the case in real life? The answer is that Firefox and 
>> Opera do. While Safari and IE displays the image instead:
>>
>> http://www.malform.no/html5/object+image-fallback.html
> 
> Yep.  Both behaviors are allowed by the spec.  See the definition of 
> @type on <object>.  Note that the above document is non-conformant, for 
> what it's worth (due to a mismatch between the @type and the HTTP 
> header).  In a conformant document this situation does not arise.
> 
> I make no guarantees about Gecko's future behavior in this regard; we 
> might start looking at @type in terms of deciding whether to fall back.

Leif Halvard Silli

Received on Thursday, 26 March 2009 15:42:31 UTC