[whatwg] WhatWG and <embed>

[Christian Biesinger]

Sorry for replying to this a bit late, but other stuff kept me 
distracted the last two weeks...

I should maybe also note that the purpose of the question wasn't so much 
to introduce new attributes to embed with (maybe) nicer semantics, but 
more about how to implement <embed> as it exists today in a web browser, 
Gecko in this case.

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)

I also want to note that generally in HTML the type attributes are 
purely advisory and the server's type takes precedence, so I'm not 
really in favour of failing if the types don't match...

Shadow2531 wrote:
> Yes, it's arguably a bug, but I do like this bug because I can use
> only one object element to do IE's classid way and the normal way.
> It's a compatibility feature imo.  However, I can't use it in
> production without breaking FF or adding alternate content or doing IE
> conditional comments or other ways.   ( IE doesn't like nested objects
> very well without some css hacks. )

Personally I don't mind the <object><embed></object> way really :)

> <object fallondata="true" codetype="type"  classid="clsid:123456"
> type="type" data="file.ext">
> <param name="src" value="file.ext">
> </object>
> 
> could be an answer to this.

I'd rather see IE work without specifying classid, then this would work 
without any new attributes...

> Maybe Mozilla can compromise for IE-compatiblity. If not, we need the
> spec to say specifically that classid must be tried first and using
> the data attribute after that must not happen.  ( It's seems there are
> interpretation differences with the current spec and I'd like there to
> be no doubt what should happen.  Then, we can fix bugs.)

I would like the spec to say that, indeed. (A while ago I asked a few 
questions about how <object> should behave on this list, btw).

> Also, IE's current use of  the codebase attribute is of course wrong
> according to HTML 4.01.  I'd like to see something in the spec like
> "The UA may ignore the codebase if it is determined that it does not
> contain a base IRI".  Basically, ignore codebase if it has known URIs
> to cab files etc. in it.

Ew...

> Also, I'd like to see mention in the spec that it is O.K. to map
> object element attributes to other params for plug-ins that don't
> conform to object element handling. For example, mapping codebase ->
> baseurl and data -> filename for WMP. I'd also like to have it spelled
> out what happens with mapping if both codebase and baseurl are
> present.  (Like which one gets priority )

Why is that OK? Which browser does that? And why not specify that either 
way must be done, instead of allowing both?

Presumably it's the plugin itself that handles those attribute mappings.

> Does FF need that or does the java plugin automatically allow applet
> -> js communication.

<param> elements are only handled by the plugin itself...

-christian