Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
> What about <img> only supporting raster images? If authors want vector
> images then they could use <object> instead.
Maybe, yeah, but I don't like having something that is <object>-only; the
idea is that <embed>, <img>, and <iframe> are case-specific versions of
<object>, so that you use <embed>, <img>, or <iframe> when you know what
you want, and <object> when you don't.
(Although <iframe> is different from <object> in that it always loads the
resource.)
(<object> is less efficient to
implement because the UA has to wait til it knows what the content type is
before it can know how to render the element.)
Also when there's a type attribute?
> Interestingly enough though, Firefox 1.6a1 displays the PNG images from
> <embed> natively (not via a plugin). Further more, a "plugin" is
> probably UA dependent; some UAs require a plugin for a particular format
> while another UA supports it natively (e.g. IE has a plugin for MathML
> while Mozilla supports it natively).
Yeah, what's a plugin and what isn't is a UA thing, so if the UA decides
that its PNG and SVG "plugins" happen to be native support, well, that's
what it is. (Both PNG and SVG are recognised by Mozilla's <embed> because
at one point they were plugin-only in IE and so people would use <embed>
instead of <img>/<object> and so when Mozilla moved to native implemen-
tations for those types, it kept <embed> working for compatiblility.)
That makes it hard to test. :)
> How should <noembed> work? (If at all, I actually dislike all <no*>
> element types.)
No idea, haven't looked at <noembed> yet. Found any trends in support?
Opera:
If plugins are enabled, render all <embed>s and hide all <noembed>s, and
parse <noembed> as CDATA. If plugins are disabled, hide all <embed>s and
display all <noembed>s, and parse <noembed> as #PCDATA.
Firefox:
I can't find a way to disable plugins, so they are treated as Opera's
"plugins enabled" behaviour.
IE:
Same as Firefox.
Regards,
Simon Pieters
