Re: Param

On Nov 27, 2009, at 9:41 PM, Doug Schepers wrote:

> 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]:

<param> elements are not passed along at all if the <object>  
instantiates a nested browsing context (for example if it refers to an  
HTML document).


>
> [[
> 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;

Historically, these details are defined by the specific plugin API  
being used (NPAPI or ActiveX). I would be hesitant to make HTML5  
depend on a specific plugin API.

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

In WebKit, the behavior is that (b2) is ignored, and (b3) will cause  
the plugin to be re-instantiated.

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

As far as I know, parameters are not passed to natively supported  
content in any browser. I think this should probably remain the  
standard behavior.

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

 From briefly scanning the SVG Parameters primer, I think the  
suggested mechanisms for passing parameters are not good choices:

1) <object>/<param> only works when embedding via <object>, which is  
likely not the best choice for embedding SVG in a browser that  
supports it natively (I would recommend <img> for static meaningful  
content, a CSS image for a decorative image, or <iframe> for  
interactive content). It also repurposes a mechanism that historically  
has only been used by plugins for use in content.

2) Passing parameters via the URI query syntax conflicts with the  
standard server-side processing of the query. Passing parameters for  
client-side processing should be done via the fragment part of the  
URI, not the query. That way, server-side processing of the query and  
client-side processing of parameters can be in separate namespaces. As  
an added bonus, this would allow the parameters to be changed without  
reloading the resource, from either inside or outside the SVG.

Regards,
Maciej

Received on Saturday, 28 November 2009 18:12:39 UTC