- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 26 Mar 2009 12:05:20 -0400
- To: Leif Halvard Silli <lhs@malform.no>
- CC: HTMLWG <public-html@w3.org>
Leif Halvard Silli wrote: > So we must wait for a plug-in api fix, I gather. Yep. >> 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. I could, but I'm not really convinced it's harmful... That said, you might want to bring up this suggestion in a separate post. I get the feel this thread is not getting widely read. ;) >>> 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? Good question; worth asking explicitly. >>>>> 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. Yes. > We also agree that fallback should only show when the intended resource > fails to load. Or is of a type the UA can't handle, yes. > And we know that for the <object><embed> pattern, the intention is to > show the fallback, because <embed> is the fallback. The fallack is the contents of the <object> whatever it is. > We also know that this pattern isn't use because one has corresponding > fallback text. This part I don't follow. > 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.) I agree that Safari's behavior here is wacky. > 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>. How does it not work, pray tell me? Seems like it works fine, except in Safari. > 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.) This doesn't give as much control in some cases (e.g. Flash, where there are various <param>s you can use with <object>). Which is why people use <object> for Flash in IE... I suspect most other <object> usage is colored by the Flash situation, since Flash is so commonly used. >> 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? The former automatically becomes the latter. In this case, I think we had the former. >>> 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? Not completely; again, this would be a good subject for a separate thread. > 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. That's a somewhat compelling argument, yes. -Boris
Received on Thursday, 26 March 2009 16:06:06 UTC