On Thu, 20 Nov 2008 07:28:44 -0500, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Tue, 6 May 2008, Michael A. Puls II wrote:
On 5/6/08, Ian Hickson <[EMAIL PROTECTED]> 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
