[whatwg] <object> element feedback

[Michael A. Puls II]

On Thu, 20 Nov 2008 07:28:44 -0500, Ian Hickson <ian at hixie.ch> wrote:

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

What I've found is that data="" is way overrated for *plugins*. It's just better to omit data="", let the plugin load and use THE <param> the plugin requires or scripting to give the plugin what it wants and watch it load the resource regardless of mime type (if it wants). Given that, I'm fine with the data="" mechanism honoring http. It works fine for properly-implemented, native handlers that support data="".

Of course, <object classid=""> pretty much says, "Just load the plugin dammit!", which is kind of nice in theory when you really want <plugin>, specifically :).

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

O.K.

Side note:

The spec currently says that Opera, Firefox and Safari can use the classid attribute to load the plugin if they want. This might be done by mapping a classid to a plugin handler. They just need to fall back if that fails, instead of then trying type and data.

The danger of mapping classid for non-activex browsers is that sometimes an <object> that uses classid="" might be meant for an activeX plugin that uses a different API than the  NPAPI  version of the plugin. This where vendors would have to be careful before deciding what classids to support.

If that's not the handling intended by the spec and classid is meant to be IE-only, the spec should be clarified. classid isn't a valid attribute, so maybe that doesn't matter.

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

As said above, I now think data="" is way overrated for plugins. Better to omit data="", load the plugin via type="" and use a plugin that supports data URIs through one of its <param> values.

I originally though it'd be cool for the browser to take a data URI, create a file from it and stream that to the plug-in. If done properly, the plug-in wouldn't know the difference. You'd have to be careful about security perhaps.

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

Yeh, there's nothing that 100% compatible with what browsers do now as they all do different stuff. Since it's so messed up, I figured it would be good to just have browsers align to the good (to-be-defined) way of doing it.

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

IE for sure.

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

Awesome. Thank you.

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

O.K., cool. Maybe "codebase" will drift into the past, all the way.

Thanks

-- 
Michael