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
