[whatwg] <embed> feedback
ian at hixie.ch
Thu Nov 20 05:58:19 PST 2008
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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg