Param

Hi, HTML WG-

There are a number of issues with the way the current draft of the HTML5 
spec defines the <param> element [1], which is an optional child of the 
<object> element.


a) It omits any mention of the @valuetype or @type attributes, which are 
defined as attributes of HTML 4.01 [2].  I agree that these attributes 
are probably overly complicated and unnecessary, but the HTML5 spec 
should explicitly deprecate them, rather than ignore them.


b) Most importantly, HTML5 doesn't seem to indicate how these attributes 
should be processed or exposed to the nested browsing context, though it 
does mention that the parameters should be passed to a plugin (and it 
draws a sharp distinction between a nested browsing context and a 
plugin); it states [3]:

[[
When the algorithm above instantiates a plugin, the user agent should 
pass the names and values of all the attributes on the element, and all 
the names and values of parameters given by param elements that are 
children of the object element, in tree order, to the plugin used.
]]

This doesn't seem adequately defined for interoperability:

b1) Though it says the parameter name-value tuple is passed to plugins, 
it doesn't seem to define a data structure or an interface on the 
<object> element that exposes these;

b2) It does not say what to do if the value of the @name or @value of a 
<param> is changed;

b3) It does not say what to do if a new <param> element is inserted;

b4) It only defines passing parameters to plugins [4], not to content 
that is natively supported by the browser and which has a DOM (such as SVG).

The intent seems to be that once the object is instantiated, changes in 
the parameters no longer have any effect.  The SVG WG would prefer that 
parameters could be changed dynamically, and the updated values 
reflected automatically parameters passed to the referenced content.

We are working on an SVG Parameters spec [5] that does not rely on this 
behavior, but would benefit from it.  The WICD specifications [6] also 
make use of <param>, though I don't know if there are any conflicts there.

The SVG Parameters spec references HTML 4.01 normatively, in the hopes 
it would be done before HTML5 is a Recommendation, but we will also make 
an informative reference to HTML5 and adjust the references if HTML5 
reaches Rec sooner.  In any case, we would like to align to HTML5 
behavior, and hope that we can coordinate with the HTML WG to similarly 
align with the goals of the SVG Parameters spec.


As a side note, I don't think the content of the example is appropriate 
for a W3C spec.  For one thing, the fallback text is a bit snarky.  But 
more importantly, the example link [7] is to content by a specific 
vendor, and that content contains an advertisement for a commercial 
product (a prominent link inviting the user to purchase Macromedia Flash 
MX, which redirects to Adobe Flash CS4 Professional in the Adobe store). 
  Please replace the example with something more appropriate, perhaps 
some fake content on www.example.com, or even just a file name as in the 
<embed> examples.


[1] http://dev.w3.org/html5/spec/text-level-semantics.html#the-param-element
[2] http://www.w3.org/TR/html4/struct/objects.html#h-13.3.2
[3] http://dev.w3.org/html5/spec/text-level-semantics.html#object-plugin
[4] http://dev.w3.org/html5/spec/infrastructure.html#plugin
[5] http://www.w3.org/TR/SVGParam/
[6] http://www.w3.org/TR/2007/CR-WICD-20070718/
[7] 
http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 28 November 2009 05:41:14 UTC