[whatwg] <embed> feedback

> 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.

Thanks.

These should no longer be a concern as the following works now:

<object type="application/x-java-applet">
    <param name="code" value="MyJavaClass">
    <param name="mayscript" value="true">
</object>
<embed type="application/x-java-applet" code="MyJavaClass" mayscript="true">

>> 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.

O.K., I guess there's nothing that can be done.

>> 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.

Thanks.

I see "When the element is created with neither a src attribute nor a
type attribute, and when attributes are removed such that neither
attribute is present on the element anymore, any plugins instantiated
for the element must be removed, and the embed element represents
nothing."

So, does that mean that <embed width="1000" height="1000"> would take
up zero space?

If so, how would you explain that as default css?

embed {
    display: none;
}
embed[src], embed[type] {
    display: inline-block;
}

??

> 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.

Thanks.

> 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 guess nothing. Leave it up to th UA?

>> 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?

Not sure. Another UA issue I guess.

>> 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.

Yeh, the plug-in is junk and Real no longer supports all browsers
anyways (the keep discrimating more and more), so we can leave this as
a plug-in / UA issue.

>> 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.

Yeh, another UA issue I guess.

>> 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.

Yeh, a UA configuration issue I guess.

> 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?

The idea was to allow the author to tell the browser that (s)he wants
the file sent with the given mime type or else fail.
Again though, I guess this is a UA config issue.

>> 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.

Yeh, this is another UA-config issue I guess.

>> 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.

Thanks

>> 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.

<embed src="000.asx"> or <embed type="text/plain" src="000.asx"> (with
000.asx sent as text/plain) loads up in the Windows Media plug-in in
Opera, Firefox and Safari, despite the Windows Media plug-in not
claiming that it supports text/plain.

Is that the correct behavior? (I guess it is since they all do it :) )

>> 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.

O.K.

>> 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.

See the question above though.

>> 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.

Thanks. This also makes: <embed type="application/x-java-applet"
code="MyJavaClass"> valid now too. (which is good)

>> Maybe having a nosrc="true" attribute would please me for this.
>
> What would it do?

Not needed now as you're not requiring src anymore.

>> 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.

O.K.

>> 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.

O.K.

>> Maybe having a strict="true" for that would please me.
>
> That seems like a feature that not many people would use.

O.K.

>> 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.

O.K.

>> 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.

O.K.

> 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.

Yeh, understood. Another UA/plugin issue I guess.

> 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. :-)

Point taken.

> 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.

O.K.

>> Should the UA make sure it doesn't pass any common attributes to the
>> plugin?
>
> There's no such restriction.

O.K.

>> 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.

O.K.

Thanks

-- 
Michael

Received on Thursday, 24 July 2008 03:57:28 UTC