[whatwg] <embed> feedback

[Ian Hickson]

On Tue, 25 Apr 2006, Henri Sivonen wrote:
>
> Apparently, the Gecko plug-in folks *still* insist on ignoring objects 
> with MS-style classids instead of special-casing the common ones and 
> mapping them to Netscape-style plug-ins or even using the data attribute 
> if present. Opera at least uses the data attribute. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=106065#c1 
> https://bugzilla.mozilla.org/show_bug.cgi?id=46569

The spec now effectively requires the Mozilla behaviour.


> Therefore, I suggest that the object element have an alternative content 
> model, where the possible param elements are followed by one embed 
> element and the embed element is optionally followed by one noembed 
> element whose content model is what the content model of the object 
> element would otherwise be in this context (except for params).

I've just allowed <embed> as a first-class citizen.


On Sat, 13 May 2006, Shadow2531 wrote:
> On 4/26/06, Ian Hickson <ian at hixie.ch> wrote:
> > I don't envisage keeping <applet> around unless someone can specify it 
> > in enough detail and give a convincing case for its inclusion.
> 
> At the least, Opera and Firefox can not expose java methods in an applet 
> to javascript when you use the object element. <applet mayscript="true"> 
> must be used.

That should be resolved at the NPAPI level. There's no reason we should 
support Java as some sort of special case as compared to Flash, 
Silverlight, or other runtimes.


> <object> is supposed to be used in place of <applet>, but that can't 
> happen in all situations currently.

<embed> can also be used. We don't need three separate ways of doing this.


> The problem with <embed> is that it doesn't support fallback content. 
> There's <noembed>, but that's only for when the <embed> element itself 
> is not supported (because you have plugins turned off in your browser or 
> something.).  Plus, <noembed> isn't really tied to any certain <embed>.

If the author could provide a non-propietary variant of the content, he 
wouldn't need to provide a proprietary one. So fallback isn't critical for 
this, IMHO. Authors seem to live quite well with just giving the user the 
choice of a Flash version or a no-Flash version, for instance.


> Also, <embed> in Opera doesn't collapse in situations like this: <embed 
> src="http://filenotfound" width="1000" height="1000">
> 
> You just get a big plug-in content area on the page.
> 
> There needs to be a defined behavior for what should happen here.

The spec now defines how <embed> works for these cases, more or less.


I didn't reply to all of your e-mail, but I think the issues you raised 
have either been resolved or are moot given the desire not to promote 
proprietary plugins over open Web formats. Please let me know if there are 
specific issues that still need fixing.


On Sun, 7 May 2006, Simon Pieters wrote:
> > 
> > I think for <img> you want to only support image/* types (e.g. not 
> > text/plain or text/html, not sure about image/svg+xml either, since 
> > there is no difference between that and application/xhtml+xml); and 
> > you want to only show them for 200 (or 301-200).
> > [...]
> > For <embed> you want to show only things that require plugins, and 
> > only if they have 200 (or 301-200) responses.
> 
> The only browser to my knowledge that only support 200 (or 301-200) 
> responses for <img> and <embed> is IE5/Mac. Safari, Opera, Mozilla and 
> IE all load the resourse for <img> and <embed> regardless of the 
> response. (In the real world it works fine because error responses are 
> normally text/html.)

This is now what <img> and <embed> say.


On Fri, 18 Aug 2006, Christian Biesinger wrote:
> 
> I got a question about <embed>. Firstly, does WhatWG intend to document 
> that element and how it works?

Yes.


> Secondly, if so:
> Consider an <embed src="testmovie.wmv">. Consider that said system has a
> plugin installed that can show movies in that format (that is,
> video/x-ms-wmv). The plugin can also handle "*.wmv" movies.
> 
> Now, imagine that the server sends a type of text/plain for this file.
> 
> What should happen?
> 
> I think the short way to phrase this question is, for <embed> without 
> explicit type attribute, should the extension matter or the server-sent 
> type?
> 
> (context is https://bugzilla.mozilla.org/show_bug.cgi?id=347736)

Right now the spec has some wacked thing with extension sniffing, which I 
hate. I really would much rather do real content sniffing. Why do browsers 
do extension sniffing here? Could we convince them to just do byte 
sniffing of the actual content?


On Sat, 19 Aug 2006, Shadow2531 wrote:
> 
> If text/plain is sent, I expect it to fail unless you have a text/plain 
> plug-in installed. Even then though, the video wouldn't play because 
> it'd be a text/plain plug-in, not a video plug-in.. However, if no type 
> at all is sent ( like if you're loading a local page that embeds a local 
> wmv file), then I'd say use the extension as a backup.

There are a lot of videos sent as text/plain. I'm not sure we can ever get 
around that.


> I think the type attribute should be required though and things should 
> fail if the type sent by the server doesn't match the type attribute. An 
> exception would be the generic types like application/x-mplayer2 , which 
> are allowed to embed more than one type or any type ( because they 
> support more than one type. )

How do we define that, beyond what the spec already says?


> Also note that some plug-ins like the real plug-in are very picky. 
> Unless you have a modified one, not only does the file have to be sent 
> as audio/x-pn-realaudio-plugin, but it has to have an .rpm extension. If 
> you have rpmfile.php for example that sends audio/x-pn-realaudio-plugin, 
> you'll be lucky if it works because the extension is .php instead of 
> .rpm. It can be that picky.

I'm not sure what to do about that.


> Basically, the browser should follow the rules of the plug-in and only 
> invoke the plug-in for types and extension the plug-in says it supports.

That's not how browsers seem to behave -- they ignore the type if the 
extension is supported.


> Now, on the other hand :), having browsers go out of their way to make 
> things work makes it all that more O.K. to send files with the wrong 
> type, which we don't really want.
> 
> Making <embed src="testmovie.wmv"> ( sent as text/plain ) fail may seem 
> evil, but it might be for the better.

Better for the Web on the long run maybe, but it won't be better for the 
browsers on the short run, so we likely won't get there from here.


On Sun, 20 Aug 2006, Dave Bacher wrote:
>
> 1.  The embed tag is redundant with the object element, and the object 
> element is now widely supported.  New pages should not use embed, they 
> should use object.

I don't see what's wrong with <embed> really.


> 2.  If you want to add the embed element to an HTML 4.01 standard, then 
> its handling of content type should in every way match the handling of 
> the content type by the object tag, because there is no reason why it 
> should apply different (more or less) restrictive rules than a directly 
> equivalent tag.

That wouldn't really be compatible with how browsers work. Or to put it 
another way, there _is_ a reason -- compatibility with legacy pages.


> 3.  It should always be assumed that the web server and its 
> configuration are outside the page author's control.  HTML standards, 
> which are not tied to any specific transport mechanism, should be built 
> around that concept.  There should be no differences in behavior because 
> of content type, aside from potentially using a XML parser in place of 
> the HTML parser by default for an XML data type.  Even in that case, the 
> browser should fall back on the HTML parser if it fails (because the 
> user isn't the one who made the mistake, and you are penalizing the user 
> for using an up-level client -- the user will soon learn to install and 
> stick with a down-level client, so that you don't interfere with their 
> browsing).

Ignoring the Content-Type like this is a quite route to privilege 
escalation. We can't always do it. We have to be very careful.


On Mon, 21 Aug 2006, Shadow2531 wrote:
> 
> This is where I myself would like to invoke strict handling ( via some 
> attribute ) as I might want things to fail if the proper content-type is 
> not sent.
>
> <embed src="file.php"> might not do me any good if file.php doesn't send 
> the right content-type.
> 
> I can see something like this:
> 
> <embed strict="true" type="audio/x-ms-wax" src="file.php">
> 
> where that would fail if file.php isn't sent as audio/x-ms-wax.
> 
> To stress again, I know we don't want to break current handling, but we 
> definitely need to straighten some things out.

I don't really understand the proposal or the reason behind it. Could you 
elaborate?


> bz wrote:
> > > If text/plain is sent, I expect it to fail unless you have a 
> > > text/plain plug-in installed.
> > 
> > Does that match current UA behavior?
> 
> No. The file will still be played.

Right, the spec right now says to use the extension.


> I expect it ( not necessarily saying I want it ) to fail because the 
> Windows Media plug-in in this case does not report that it supports 
> playing text/plain media. It says it supports the .wmv extension, but 
> what if I have a text/plain plug-in? Will it load in the plug-in 
> associated with text/plain or in the windows media plug-in or other?

Based on my tests with images, it looks like browsers honour the extension 
before the MIME type.


> I'd like to see the steps spelled out *exactly* because HTML 4.01 does 
> not do that.

The spec does now have the exact rules.


> Also, what about this <embed src="file.asx"> (where the asx file is 
> served as text/plain).  What if I really want it embedded as a text file 
> and don't want it embedded with the wmp plug-in?

The type="" attribute overrides the extension.


> Things usually work without a type attribute.
> 
> I think it should be encouraged though. It does have it's uses.

We can allow it, but we can't require it, really, since the author might 
now know the type ahead of time.


> It's a great hint if the browser can't figure out what to do with the 
> mime type sent, if any, and the extension doesn't help.

Actually it overrides both of those.


> Also, whether it currently works correclty this way or not, 
> type="application/x-mplayer2" for example means to load the src with the 
> windows media plug-in regardless of the the extension or type and leave 
> it up to the plug-in to decide whether the file is supported.

Right.


> Also, <embed type="sometype"> without a src could be used to invoke a 
> plug-in for scripting so that scripting could set a source.

Done.


> Maybe having a nosrc="true" attribute would please me for this.

What would it do?


> Also, ( this is more with the object element ), if I specify a type="" 
> and the server sends the file with a type that doesn't match, I might 
> want the alternate content to display.

That would probably break too many pages.


> If the type attribute is required and things failed if the server 
> content-type doesn't match, then maybe we wouldn't have so many people 
> embedding files sent with the wrong type.

That may have been true when the element was invented, but it's far too 
late now.


> Maybe having a strict="true" for that would please me.

That seems like a feature that not many people would use.


> We need some type of standard for plug-in development too as most 
> plug-ins don't use a data param and browsers have to map it to a src 
> param.

That's up to the NPAPI.


> I know we can't break pages, but I believe strict handling of things 
> would be better in the long run.

I agree, but I can't see how to get there from here.


On Fri, 1 Sep 2006, Christian Biesinger wrote:
> 
> I should maybe also note that in Gecko, if you specify a type attribute 
> the plugin will always be invoked, no matter what the content of the src 
> attribute (indeed even if there is no src attribute), and also 
> independent of what the server sends. (This is different from <object>, 
> where on Gecko trunk the server-sent type always wins)

What are the plugins for which <embed> is used without src=""?


On Sat, 2 Sep 2006, Shadow2531 wrote:
> 
> An example that Firefox and Opera both do: 
> <https://bugs.helixcommunity.org/show_bug.cgi?id=4766>
> 
> I'd like the spec to describe exactly how browsers should do stuff like that.
> 
> As for the priority deal. Here's an example:
> 
> <object codebase="http://somesite.com/dir/">
>    <param name="baseurl" "http://someothersite.com/">
> </object>
> 
> If the browser must map codebase to baseurl for a certain plugin like
> WMP to work with the object element, if both are specified, does the
> codebase still map to baseurl or can the browser give the actual
> baseurl priority and not map. It could be done a few different ways.
> All I'm saying is I'd like it spelled out so everyone can stick to it.
> 
> Another example WMP example:
> 
> <param name="autostart" value="false">
> 
> does nothing for the WMP netscape 6.4 plugin that Opera and Firefox
> (normally) use.
> 
> Instead of 'false', it has to be '0'.
> 
> Should browser's be allowed to map false|true to 0|1 on a 
> plugin-by-plugin basis in this case to make things work?
> 
> I know it's MS's fault for this or Real's fault in the other case, and 
> there are markup ways around it, but I'm saying that browsers have to do 
> all kinds of things to make plugins work, because most plugins suck.
> 
> The thing is, if all browsers are not working around the problems is 
> some common way, it doesn't help. If half are using duct tape and half 
> are using elmer's glue, we're still stuck with cross-browser 
> incompatibility.
> 
> Maybe this stuff is beyond the spec, but I bring it up for everyone to 
> decide.

I've made notes relating to this, and will look at it in due course. It's 
not entirely clear how much of this belongs in HTML5 and how much in the 
NPAPI docs, though.


On Tue, 5 Sep 2006, Shadow2531 wrote:

> Yes, codebase + data -> src is great and universal.
> 
> However, see <http://shadow2531.com/opera/testcases/plugins/wmp/004.html>
> 
> That works in Opera, but doesn't in Firefox. It seems that Firefox is 
> not using the codebase to resolve the data attribute before mapping it 
> to src.

Given that the music only plays in Opera, and not in any other browser 
(including IE8), I don't think this is a point in Opera's favour. :-)


On Tue, 31 Oct 2006, Alexey Feldgendler wrote:
> 
> I belive that there should not be any special markup for plugins. The 
> fact that the browser uses a plugin to display the movie, or image, or 
> VR scene, or whatnot, is that browser's implementation detail. Some 
> text-only browsers use external programs to display images, but there 
> isn't a special markup which tells them to do so. I don't see why video 
> clips should be any different.
> 
> Because one of the goals of WHAT, as I perceive it, is to provide 
> semantic markup for things that are currently marked up 
> presentationally, I think that HTML 5 should encourage transition from 
> the presentational EMBED ("plugin content") to the semantic OBJECT 
> ("external subdocument") or even to more semantically fine-grained 
> VIDEO, AUDIO etc. It doesn't mean that support for EMBED should be 
> dropped: just like with FONT, there are many existing documents which 
> use it, and there probably will be authors which continue using it 
> despite its use being discouraged.

Well we have <video> and <audio> and we also have <embed>. I don't think 
the goals of the WHATWG are just to provide semantic markup for the sake 
of it.


On Thu, 9 Nov 2006, Henri Sivonen wrote:
>
> How does <embed> allowing any attribute in no namespace interact with 
> attributes that are defined to apply to all elements? That is, should 
> datatype constraints on common attributes apply?
> 
> For example, is dir="blahblah" a conforming attribute on <embed>?

No. Any XML-compatible attribute may be set, but that doesn't override the 
rules for certain attributes, like dir="".


On Thu, 9 Nov 2006, Shadow2531 wrote:
> 
> Are common attributes reserved and therefore can't be used as params?

Effectively, though they are still passed.


> Should the UA make sure it doesn't pass any common attributes to the 
> plugin?

There's no such restriction.


> If no, and dir can be a param of whatever type you want, it should not 
> have any constraints.

The reserved attributes (like id="") still have their usual behaviour, so 
they should have their restrictions. They are passed to the plugin anyway, 
for legacy reasons.


On Fri, 23 Mar 2007, Henri Sivonen wrote:
> > 
> > * <applet>: the (old) way of activating Java. Probably must also die, 
> > though I'm unsure about this one.
> 
> Why must it die? Browsers have to support it anyway, so documenting it 
> and letting it pass conformance checking seems sensible.

Having an essentially proprietary technology have a dedicated embedding 
point when we have at least two other mechanisms for general embedding 
of proprietary technologies seems excessive.


> I don't like applets, either. In fact I've never seen a Java applet that 
> wasn't either useless, better implemented in JavaScript, better 
> implemented in Flash or better in a window of its own rather than in a 
> replaced element rectangle. Still, pretending that <applet> doesn't 
> exist won't make applets disappear. :-(

I agree we have to define it, to some extent.


On Thu, 26 Apr 2007, Anne van Kesteren wrote:
>
> * Why is this section named "Page load processing model for
>   content that uses plugins" as opposed to "Page load
>   processing model for plugins" which would be more in line with
>   the rest of the sections there?

Because the pages don't contain the plugins themselves, they contain 
content to be passed to a plugin.


> * It says to set the src attribute of the img element as
>   opposed to setting the src attribute of the embed element.
> * It talks about address of the image as opposed to address
>   of the plugin.

Fixed.


> * I only got Opera to reveal that this is in fact how it's
>   implemented, but it seems that we also set height and
>   width attributes on embed (both to 100%) and remove
>   margins on the body element.

That's allowed (but not required) by the current prose.


On Wed, 13 Jun 2007, Kristof Zelechovski wrote:
>
> The embed element should be deprecated because of the expando feature 
> that makes it so special. 

I don't understand the "because" here. This seems like a non-seqitur.


> I understand that having both embed and object can capture some semantic 
> differences where "embed" means "display" and "object" means "run" but 
> breaking the fixed interface rule weighs more than introducing this 
> distinction IMHO.

I don't understand.


On Wed, 13 Jun 2007, Kristof Zelechovski wrote:
>
> Deprecating the embed element would make the standard more consistent 
> and would make me feel better about the standard eventually. Not that I 
> feel bad right now, that is.

HTML5 is a long way from being "consistent". That's a battle we lost long 
ago, I think!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'