[whatwg] <object> element feedback

Vlad Alexander (xhtml.com) vlad.alexander at xhtml.com
Tue May 6 02:26:07 PDT 2008


> Does the NPAPI define a way to submit form data?
Yes, please see:
https://bugzilla.mozilla.org/show_bug.cgi?id=188938

IE, FF and Opera support plug-ins to submit data in a form. And XStandard plug-in supports this. For example:

<object type="application/x-xstandard" name="editor1" width="100%" height="300">
	<param name="Value" value="Hello World" />
</object>

IE, FF and Opera will send "editor1=Hello World" to the server in an HTTP POST.

The alternative is to this feature is an ugly hack which I hope will not be necessary one day. Please see:
http://xstandard.com/en/documentation/xstandard-dev-guide/web-integration/step2/


> Auto-installing unprotected binary code on an enduser machine seems 
> unbelievably unwise.
But it's not silent install. The user is prompted to approve the operation. So from security point of view, it's no different than asking a user to install via installer.

> I take it you don't like the idea of HTML+JS being the alternative
> solution [alternative to codebase attribute]?
Sorry, not sure how HTML+JavaScript can be an alternative to the codebase attribute.

There is a need for a cross-browser technique to install plug-ins. Until such a technique is specified, the codebase attribute should not be removed.

Regards,
-Vlad




-------- Original Message --------
From: Ian Hickson
Date: 2008-05-06 2:08 AM
> On Sat, 7 May 2005, Christian Biesinger wrote:
>> OK, another <object> fallback question: Consider an object that has no 
>> attributes that would allow selecting a plugin/content handler. For 
>> simplicity, consider an object without any attributes, say:
>>
>>   <object>Foo</object>
>>
>> What should be displayed? Should the user agent just fall back to the 
>> contents of the object? (Presumably "empty string" as fallback content 
>> does not affect the answer to this question either :-) )
> 
> The spec now defines this.
> 
> 
> On Wed, 25 Jan 2006, Hallvord Reiar Michaelsen Steen wrote:
>> On encountering an OBJECT, the UA must check type and/or classid.
>>
>> If the type attribute identifies a file type the UA handles 
>> internally, check if the OBJECT has a data attribute. Render contents 
>> of this attribute if found, proceed to fallback contents if not.
>>
>> If type/classid identifies a known plugin, the UA must initialise the 
>> plugin passing on information about the attributes and the name/value 
>> pairs of any PARAM descendants that are not children of nested OBJECT 
>> tags.
>>
>> If type/classid does not identify a known plugin, and there is a data 
>> attribute, do a HEAD request on the resource identified by the data 
>> attribute. If the server sends a content-type that identifies a known 
>> plugin, initialise plugin.
>>
>> If there is no data attribute, the resource can not load or the 
>> content-type of the resource is unknown, proceed to render fallback 
>> contents.
> 
> The above is somewhat what the spec says, though it is more closely 
> aligned with what browsers (Mozilla in particular in this case) seem to 
> do.
> 
> 
>> Issues: if there is a known content-type and a data: attribute, 
>> should the UA check if the content-type sent from server also 
>> identifies the plugin? In other words, do we want to say that the 
>> type attribute on the OBJECT tag is only a hint and that the actual 
>> HTTP content-type header is the one that counts?
> 
> Right now the spec uses the Content-Type header if it is present.
> 
> 
>> I'm not sure if "only a hint" should be speced. It sounds quite risky to 
>> meddle with the logic for embedding contents - could break many sites, 
>> particularly if we are supposed to start relying on the famously 
>> malconfigured HTTP content-type responses.
> 
> What should it be instead?
> 
> 
>> Since there are use cases for plugins that do not load data at all, the 
>> UA should initialise the plugin even without data attribute if the type 
>> is known. That sort of negates the point about type being a hint because 
>> we can't initialise one plugin, look at the content-type of files that 
>> plugin decides to request and say "whops, we started the wrong plugin, 
>> let's do this again". If the spec goes the "hint" route, it really needs 
>> to make that apply only to OBJECTs with a data attribute, and to 
>> minimise problems with malconfigured servers it should only take place 
>> if the UA doesn't know the specified type attribute IMO.
> 
> Right now if type="" is present but data="" isn't then the respective 
> plugin is fired, otherwise the plugin to fire is taken from the 
> Content-Type header.
> 
> 
>> Another issue is of course if and how one should map classid to plugins.
> 
> Indeed. I don't know how to do that. I suppose it is UA-specific.
> 
> 
> 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.
> 
> 
>> 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?
> 
> 
>> How should data uris be handled?  Is it just up to the plug-in to handle 
>> the passed data uri or is the UA allowed to create a file from the data 
>> URI and pass the file path to the plug-in/hander (if it can do it 
>> safely)?
> 
> Isn't this up to the plugin API?
> 
> 
>> 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?
> 
> 
>> First, the UA should check for a classid attribute.
>>
>> If present and the the UA has a handler associated with the specified 
>> naming scheme, then the UA should pass all arguments to the handler in a 
>> manner that is specific to the handler.
> 
> That's what the spec says, indeed.
> 
> 
>> If the classid attribute is not present or the naming scheme is not
>> supported or the handler returns an error code, then the UA must check
>> for the presence of a type attribute.
> 
> If classid="" isn't supported, it just shows fallback.
> 
> 
>> If it exists, the UA must check to see if it has a handler associated
>> with the Content-Type specified in the type attribute.
>>
>> If the Content-Type is associated with a handler, the UA must pass all
>> arguments to the handler.
> 
> The resource is actually downloaded by the UA in this case, as far as I 
> can tell. Is that wrong?
> 
> 
>> If that fails and there is a data attribute, check the Content-Type
>> sent by the server for the file and determine if there's a handler
>> associated with the type.
> 
> The spec honours the Content-Type header over all else if it is present 
> and classid="" isn't.
> 
> 
>> If there is a handler associated with the type, pass all arguments to
>> the handler.
>>
>> If there is not, the UA *should* compare the file extension to a list
>> of known Content-Types associated with that extension.
>>
>> If a handler is found, pass all arguments to the handler.
> 
> I do not want to add any extension-sniffing to the spec, it is too 
> dangerous, highly unreliable, and as far as I can tell isn't necessary.
> 
> 
>> ( URIs to files should be passed to the handler and the handler should 
>> download the files as necessary. The Ua should not download the file on 
>> its own. Only the handler should make that request to the UA.)
> 
> Really?
> 
> 
>> Once the handler gets the arguments, it *must* detmermine whether it has 
>> the necessary and valid arguments to initialize. If it does not, it 
>> should return a failure code. If it does, it should try to initialize 
>> and if successful, return a success code; otherwise, return a failure 
>> code. The handler should return a failure code in every situation where 
>> there's no need to initialize in the first place.
> 
> This is out of our scope.
> 
> 
>> The UA must check for this return code to determine whether to display 
>> fallback content.
> 
> It's not clear to me how to tell if a plugin failed.
> 
> 
> On Wed, 1 Nov 2006, Christoph P?per wrote:
>> I think it would be helpful to /explicitly/ allow content types (alias 
>> media types) in |type| of |object| to omit the subtype, e.g.:
>>
>>   <object type="video" data="foo.mpv"/>
>>   <object type="audio" data="foo.mpa"/>
>>   <object type="image" data="foo.png"/>       ~= <img src="foo.png">
>>   <object type="application" data="foo.swf"/> ~= <embed src="foo.swf"/>
>>   <object type="text" data="foo.txt"/>        ~= <iframe src="foo.txt"/>
>>
>> Maybe this is all the support for this element type that should be 
>> required from conforming implementations. Furthermore |width| and 
>> |height| should be required for freely scalable formats, but OTOH not 
>> apply to 'audio' types (i.e. always equal zero), and exclude the space 
>> required for an optional inline GUI.
>>
>> I never understood, by the way, why videos and Flash-like content 
>> shouldn't work within |img|. (Parameters can be specified in URIs.)
>>
>> I could also envision an HTML5 where |alt| was optional for (or even 
>> removed from) |img|, which in return was only allowed to be used for 
>> optional, decorative images (and perhaps likewise |embed|). Every 
>> illustration conveying meaning was then to be embedded using |object| 
>> (including descriptive content, but nesting |object|s would be 
>> discouraged, although allowed) or more sophisticated methods. This 
>> wouldn't keep many correctly authored existing pages conformant, though.
> 
> I don't really see how to handle this feedback. We can't really make the 
> changes that would change how <object> works today.
> 
> 
> On Tue, 7 Nov 2006, Lachlan Hunt wrote:
>>   Should the data attribute be required for <object>?  There is at least 
>> one plugin that doesn't need it.  XStandard embeds itself without using 
>> it, like this:
>>
>> <object type="application/x-xstandard" id="editor1" width="100%" height="400">
>>   <param name="Value" value="Hello World!" />
>> </object>
>>
>> I'm not sure whether that's a correct use of the object element or not, 
>> and I do think it would make more sense for XStandard to replace a 
>> textarea, but there must be implementation issues with that or 
>> something.
>>
>> http://xstandard.com/page.asp?p=A4372B00-8D7F-4166-977C-64E5C4E3708E&ss=C2B75B64-1544-429D-ACDA-07D17E35FB56
> 
> It's allowed.
> 
> 
> On Tue, 7 Nov 2006, Shadow2531 wrote:
>> Reason 1:
>> <object classid="java:MyJavaClass"></object> is used for Java. (
>> Although I'd love to have <object type="application/java"
>> data="file.class"></object> work, but ...)
> 
> This is not allowed. Java should use the standard mechanism, as you point 
> out.
> 
> 
>> Reason 2:
>> You might want to load a plugin like this: <object
>> type="application/x-mplayer2"></object> and later use scripting to
>> tell the plugin to get the resource. If the data attribute is
>> required, you'd be forced to load a resource that you didn't want to.
> 
> Indeed.
> 
> 
>> Reason 3:
>> The tcl plugin <http://www.tcl.tk/software/plugin/> suports inline
>> scripts via a script param and things like the following need to work
>> without the data attribute.
>>
>> <object type="application/x-tcl">
>>   <param name="script" value="script content">
>> </object>
> 
> Indeed.
> 
> 
> On Sat, 23 Dec 2006, Rohan Prabhu wrote:
>> I've been writing a spec called 'XObject' for the past week.. and i'm 
>> going on a 2-day vacation from tomorrow.. just got the idea of sharing 
>> this with you. I wrapped it up in a small site-like thingy in the short 
>> time i had.. so the site is not really good... but the content is there 
>> as much as i have worked on. It is still a work in progress. Do read the 
>> foreword there, I've already warned about some factual inaccuracies... 
>> :)
>>
>> Here is the link to it: http://xobject.tritiumx.com
> 
> It's not clear to me what this spec (which btw is now no longer available) 
> was supposed to address.
> 
> 
> On Sat, 7 Apr 2007, Henri Sivonen wrote:
>> HTML5 should probably make the Java applet embedding patterns documented by
>> Sun conforming or at least make the <applet> case conforming as it is the
>> cross-browser syntax:
>> http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html
> 
> Java needs to get over itself and stop being such a drama queen and just 
> use the standard embedding methods that everyone else uses.
> 
> 
> On Sat, 7 Apr 2007, Michael A. Puls II wrote:
>> Currently, the only way to embed an applet that's allowed by the spec 
>> is:
>>
>> <object type="application/x-java-applet">
>>    <param name="code" value="MyJavaClass">
>> <object>
>>
>> (That works fine for Opera and FF at least.)
> 
> Indeed.
> 
> 
>> There's also <embed type="application/x-java-applet" 
>> code="MyJavaClass">, which is currently not allowed because src is 
>> required.
> 
> Indeed.
> 
> 
>> There's also <object classid="java:MyJavaClass> (which is used as a 
>> non-deprecated example at 
>> <http://www.w3.org/TR/html4/struct/objects.html#h-13.4>). This is 
>> currently not allowed because there's no classid allowed, which has to 
>> be present to be compatible with IE.
> 
> Right.
> 
> 
>> And, then, there's of course APPLET, which needs to be defined (no 
>> rush), including how fallback content works when java support isn't 
>> present and the alt attribute is present. (As in, does alt get used over 
>> fallback content or the other way around or somewhere in between.)
> 
> There's a note in the spec about this.
> 
> 
>> I also think it might be necessary to clarify (or at least hint to)
>> what mime type should trigger java. application/x-java-vm and
>> application/x-java-applet etc. are provided by the Sun Java plug-ins,
>> but not all browsers use those plug-ins. (application/java is used in
>> W3C examples.)
> 
> The spec has an example with x-java-applet now.
> 
> 
>> On a side, if codebase is allowed on the object element, it will have 3 
>> different uses.
>>
>> 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? Case 2 seems incompatible with case 1.
> 
> 
>> In the case of #3 (for browsers besides current IE), where both a 
>> codebase attribute and a codebase param are present, one of them would 
>> have to override the other. It might be necessary to define which one 
>> and how etc.  (Going to something specific like this might be out of 
>> scope for plug-ins etc. in general, but Java handling might be an 
>> exception.)
>>
>> With all the different OBJECT situations for Java, APPLET will be a huge 
>> relief.
> 
> How about just not supporting Java?
> 
> 
> On Mon, 22 Oct 2007, Vlad Alexander (xhtml.com) wrote:
>> I noticed that the latest HTML 5 draft states that the "name" and 
>> "codebase" attributes are not allowed on the "object" element.
>>
>> 1. Plug-ins, such as XStandard, use the "name" attribute for submitting 
>> content to the server without the need for JavaScript. This makes for an 
>> accessible solution. XStandard has been doing this for 4 years in some 
>> browsers. IE, Firefox and Opera support this feature. This attribute 
>> serves a vital role for plug-ins.
> 
> name="" is now supported, though not for this purpose.
> 
> 
>> 2. The "codebase" attribute is the only way to auto-install or update 
>> plug-ins in IE. This is an important feature that should not be removed 
>> without providing an alternative solution.
> 
> I take it you don't like the idea of HTML+JS being the alternative 
> solution?
> 
> Auto-installing unprotected binary code on an enduser machine seems 
> unbelievably unwise.
> 
> 
>> 3. The HTML 5 draft states that the "embed" element is used for plug-in 
>> content. The "object" element is a better mechanism for loading plug-ins 
>> and is supported by all browsers. The HTML 5 spec should state the 
>> "embed" or "object" elements can be used for loading plug-ins.
> 
> I'm not sure which bit you're referring to here.
> 
> 
> On Thu, 25 Oct 2007, Michael A. Puls II wrote:
>> Yes, I agree. The name attribute has to be supported (at least when the 
>> object is inside <form>. (All the form stuff hasn't been dealt with yet 
>> though.)
> 
> It's not clear to me how this is supposed to work. Does the NPAPI define a 
> way to submit form data?
> 
> 
>>> 2. The "codebase" attribute is the only way to auto-install or update 
>>> plug-ins in IE. This is an important feature that should not be 
>>> removed without providing an alternative solution.
>> If we do define it, it's going to be fun because what it's for depends
>> on how it's used.
>>
>> It can be a URI to fetch a new version (for IE).
>> It could be the directory that java class files are in (in browsers
>> besides IE when using the Sun java plugin).
>> It could be a base URI used for resolving relative URIs (in browsers
>> besides IE for possibly native stuff and some plugins).
>>
>> For the last 2, there would need to be rules to follow  to determine
>> whether it's an IE upgrade URI or a base URI so browsers besides IE
>> don't use it as a base path if it's not really a base path. But,
>> there's not much need to use a codebase attribute in FF, Opera and
>> Safari (not even for java).
> 
> I have no idea what to do here.
> 
> 
> On Tue, 1 Jan 2008, Jeff Walden wrote:
>> http://biesi.damowmow.com/object/011.html
>>
>> Firefox 2 shows FAIL.
>> Firefox 3 currently shows PASS.
>> WebKit nightly shows a broken image icon.
>> Opera 9.25 shows PASS.
> 
> WebKit now shows PASS, so this seems like a non-issue. (Spec agrees.)
> 
> 
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded0.html#the-object
>>
>> For the moment ignoring that WebKit's using @type instead of the 
>> server-sent type of the <object> producing the PASS/FAIL/icon (contrary 
>> to current HTML5 and HTTP RFC 2616), it seems that WebKit isn't 
>> displaying fallback content when the primary content contains "errors" 
>> -- malformed images, in this case -- where recent Firefox and Opera are.
>>
>> The spec doesn't currently address falling back for malformed content, 
>> i.e. malformed images, invalid XML (maybe?), content a plugin handler 
>> declines to handle (?, dunno whether this is expressible in NPAPI or 
>> ActiveX or whether that question's too implementation-dependent), etc.  
>> I tend to think it should since a broken-image icon's not particularly 
>> useful, but I don't care strongly one way or the other.
> 
> Fixed for everything but XML.
> 





More information about the whatwg mailing list