Re: Param

Hi, Maciej-

Thanks for your responses.

Maciej Stachowiak wrote (on 11/28/09 1:11 PM):
>
> On Nov 27, 2009, at 9:41 PM, Doug Schepers wrote:
>
>> 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).

Thus my requested change. :)


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

I'm not suggesting that HTML depend on either of those, but rather that 
a standardized way of exposing parameters is defined such that plugin 
APIs can adapt to and depend on that.


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

Why do you think that?


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

I agree with your advice about <img> and CSS, which is what we recommend 
in the SVG Integration spec [1].

Why would you recommend <iframe> instead of <object>?


> It also repurposes a mechanism that historically has only been used by
> plugins for use in content.

HTML5 makes a point of repurposing existing mechanisms for new purposes. 
  Why shouldn't <param> be reused in this way?  It seems better than 
inventing a whole new element or mechanism for doing it.


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

Yes, we'd come to that conclusion as well, but haven't decided on a 
syntax for URI syntax yet.  One aspect of not reloading the resource is 
that the same resource can be used in multiple instantiations on the 
same page, and it can take advantage of chaching.


[1] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

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

Received on Monday, 30 November 2009 01:22:48 UTC