[whatwg] <embed> feedback

[Ian Hickson]

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.


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


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


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


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

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