[whatwg] <embed> feedback

[Michael A. Puls II]

On Thu, 20 Nov 2008 08:58:19 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 24 Jul 2008, Michael A. Puls II wrote:
>>
>> 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?
>
> No, but that's a rendering-level concern. The element can represent
> nothing while still rendering as a lot of whitespace.

I hope the rendering part is clarified. Firefox collapses the embed's width and height, which, by popularity, kind of makes Opera and Safari's behavior unexpected.

>> > 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 changed the spec to treat the type="" attribute as an override, and the
> Content-Type as the truth if there's no type="". No sniffing.
>
> I guess we'll see if browsers implement it or if they can't.

Understood.

>> >> 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.
>
> Seems like a conformance issue, but I'm not sure how to define it.

Here's how I would describe it:

If you have a plugin that supports loading a resource sent as a mime type other than the mime type specified in the type attribute that loads the plugin, using the data attribute may produce undesired results. In this case, it's better to omit the data attribute and use the <param> the plugin looks for to find what resource to load.

I'm sure you could turn that into something that reads better, but you should get the point. Perhaps that belongs in an authoring guide though.

>> >> 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.
>
> Right now, the spec says to use the extension to determine the type for
> <embed> (but not <object>). I don't like it. If we can get UAs to change
> this, I'd be happy.

O.K.

>> >> 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 :) )
>
> I've changed <embed> to do this as you describe (after testing that it
> does indeed happen!). I haven't changed <object>, which in at least  
> Safari
> has similar behavior.
>

O.K.

Thanks


-- 
Michael