Re: Param

On Nov 29, 2009, at 5:22 PM, Doug Schepers wrote:

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

Well, it's not that HTML5 fails to indicate *how* <param> values are  
passed to the nested browsing context, it correctly reflects the fact  
that in current implementations they are *not*.

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

As far as I know, plugin API designers don't need anything specific in  
HTML5, such as defining a data structure, to figure out how to expose  
<param> values.

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

There doesn't seem to be a compelling need to change it. Using  
<object> to embed a natively supported type is unusual and generally  
not the best way to do things, so I would be hesitant to add new  
features tot hat functionality.

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

<object> has downsides due to the fact that it behaves differently for  
image types, types handled by plugins, and natively handled types that  
form a DOM. Which of these three modes is enabled cannot be properly  
decided until the type of a remote resource is retrieved from the  
server. This tends to cause performance and correctness issues.  
<iframe>, which is specialized for containing a natively supported DOM- 
forming document type, tends to work more reliably. It would be my  
first choice to embed either HTML or SVG.


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

If there were no mechanism available which already works, then this  
would be an argument to consider. However, it seems like embedding  
parameters in the fragment ID, as discussed below, will work in all  
embedding contexts (even CSS images), with no need to change HTML,  
either spec or implementations. Why also add the <param> mechanism  
which only works for <object> as an embedding context, and which does  
require changes in HTML?

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

Sounds good to me. This seems like it could be especially useful for  
the CSS case - dynamically recolorable background images could be a  
powerful UI-building facility.

Regards,
Maciej