W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] <object> element feedback

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 20 Nov 2008 12:28:44 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0811201033570.25582@hixie.dreamhostps.com>
On Tue, 6 May 2008, Michael A. Puls II wrote:
> On 5/6/08, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 31 Jan 2006, Shadow2531 wrote:
> > >
> > > The current methods of "The server Content-Type rules all" and "If 
> > > there's no data attribute, then fail" are not working out. There are 
> > > cases where a data attribute is not needed and there are cases where 
> > > a type attribute should be the priority. The type attribute is 
> > > really used as "Here's what plug-in/handler I want to use".
> >
> >  For the no-data="" case, the spec now handles it.
> 
> As for the other issue, there are some type attribute values that are 
> special.
> 
> <object type="application/x-mplayer2" data="file.gif(sent as 
> image/gif)"></object>
> 
> That really means to load the gif file in the plugin and not with the 
> browser's native gif handler.

I disagree. I agree that many browsers treat the type="" attribute as an 
HTTP override, but I don't think that's what we want them to do.

We'll have to adjust the spec if it turns out browsers are required to do 
this by legacy, but I'd rather we tried to honour HTTP here than once 
again violate the underlying RFCs.


> > > There also needs to be some specifics for the classid attribute.  
> > > If the classid contains an unsupported naming scheme, should the UA 
> > > really have to just fail or should it go on and try to use the type 
> > > and data attributes?
> >
> > It appears it should fail. Do browsers do otherwise?
> 
> Opera currently doesn't let classid get in the way. It will ignore it 
> and still use the object. Other browsers don't agree though.
> 
> One problem with Opera supporting this is that the object might have a 
> codebase attribute on it that points to a cab file for IE, which can 
> mess up the path resolving of the data attribute. Since other browsers 
> fall back when there's a classid, they usually don't get this problem.

I prefer sticking to the majority here.


> > > How should data uris be handled?
> > Isn't this up to the plugin API?
> 
> It's currently up to the plugin api and the particular plugin. I just 
> think more plugins should support data URIs though and maybe there'd be 
> a way for browsers to fill that gap.

Not sure what HTML5 can do about this.


> > > What should happen when a UA encounters a codebase attribute that 
> > > has a path to a cab file instead of a base URI? Should the UA always 
> > > use the codebase to resolve URIs even if it has junk in it?
> >
> >  Right now codebase="" is just ignored by the spec. What should it do?
> 
> Ideally, codebase should be a base href for the data attribute, but only 
> be allowed when used with handlers that *properly* support the data 
> attribute for loading the resource. Of course, you can't really validate 
> that.

Ideally, codebase="" would not exist. The question is what are we stuck 
with. :-)

Since the browsers all do different things, and since of those, Safari 
doesn't do anything with codebase="" at all as far as I can tell and has 
not received many bugs about it as far as I can tell, I've continued the 
previous pattern of not doing anything.


> > > 1. base URI for resolving (kind of like <base href="">)
> > > 2. URI to a .cab file (for activeX stuff)
> > > 3. For java, it's specifically a URI to the directory the .class file
> > > is in unless you're using current IE in which case, it's #2 and a
> > > codebase param is used instead.
> >
> > o_O
> >
> > I'd rather just not support it and make it non-conforming... Do any
> > browsers actually support case 1?
> 
> Opera and Firefox support #1 and it works really well (for native
> handlers at least) if you use it properly.

Except that it'll screw up IE and Safari, right?


> As Vlad said, HTML4 says objects can be submitted via forms. This 
> happens when the object has a name and the object loads a plugin that 
> exposes a value getter.
> 
> This doesn't work completely across browsers, but it's essential for the 
> xstandard plugin.

Added; see earlier mail.


> Not sure about making it valid or not, but for the handling section, 
> something like the following (but maybe more specific) would probably 
> do.
> 
> If the classid attribute is present, then the codebase attribute 
> behavior is defined by the classid handler.
> 
> If classid is not present and data is present, it specifies a base href 
> for the data attribute.

Given that not all UAs do the latter, I'd rather not do it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 20 November 2008 04:28:44 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC