Steps to reproduce: 1) Don't have Adobe SVG Viewer installed. 2) Load http://www.andyjamesdavies.com/experiments/svg/ Actual results: Firefox doesn't render the SVG graphics referenced using <object>. (Neither does Opera 11 beta.) Safari 5, Chrome 9 and IE9 PP7 render the SVG graphics. Expected results: Expected Firefox to render the SVG graphics like Safari, Chrome and IE.
Hmm. HTML4 says: codebase = uri [CT] This attribute specifies the base path used to resolve relative URIs specified by the classid, data, and archive attributes. When absent, its default value is the base URI of the current document. which is exactly what we do. HTML5 seems to think the "codebase" attribute doesn't exist at all. Is that because no one other than Opera and us has ever implemented it or something? I would be very surprised if that's the case for plug-ins in earlier IE releases, say.
(In reply to comment #1) > HTML5 seems to think the "codebase" attribute doesn't exist at all. HTML5 omits the ActiveX-specific attributes that were put into HTML 4. The HTML5 view of plug-ins is that you invoke them the way NPAPI plug-ins are invoked. That is, single-vendor stuff (i.e. ActiveX-specific stuff) isn't in the spec. > I > would be very surprised if that's the case for plug-ins in earlier IE releases, > say. I believe the ActiveX site-initiated native code install feature uses an URL in the codebase attribute to point to the .cab file to install. However, I believe (didn't test) that if the user has already installed the required ActiveX control, the codebase attribute is not needed to instantiate it. FWIW, during the last ten years or so, I've never understood why Gecko has insisted on treating <object>s that have ActiveX-ish traits as not loadable instead of ignoring the ActiveX-ish traits and seeing if an NPAPI plug-in or a built-in handler can handle the data.
Should this be Core->Plug Ins then?
> HTML5 omits the ActiveX-specific attributes Yes, but nothing in HTML4 says @codebase is ActiveX-specific. Gecko has always applied it to all types of objects: NPAPI plugins, HTML objects, etc. It's just used as a base URI for @data, like HTML4 says. Are you perhaps confusing it with @classid? I'd really like to see some clear testing of @codebase behavior across all types of <object> in browsers before messing with things here.
You need to log in before you can comment on or make changes to this bug.