Re: Param

Hi Doug and All,

> This doesn't seem adequately defined for interoperability:

I want to say thank goodness SVG is asking these questions about how 
to include an active context in an html document. I hope you and all 
interested are also looking at X3D efforts in this area
http://web3d.org/x3d/wiki/index.php/X3D_and_HTML5

It is great to think of the convenience of native handling of svg 
elements and events using inline code. It is also helpfull to see svg 
as an active object embedded in the document using <object> or even 
<iframe>. Is the problem the same in all of these cases?
How do I use the host DOM to communicate events and data into and out 
of the active object that constitutes the svg runtime DOM?

As far as I can tell, <param> elements arose as a sensible alternative 
to the monster string used in <embed> to transfer initialization and 
maybe runtime name-value pairs into whatever runtime represented the 
nested context. It is a nested context because events can be passed 
between the object runtime and the host DOM. The object context 
internals are hidden and only accessible using interfaces defined by 
the object context.

Each param holds two string attributes, one named @name and one named 
@value.
The params carry info for initialization of the nested context and 
along with other interfaces defined by the context, may be live inputs 
and outputs over the life of the object. The life of the object and 
its ability to communicate with the host DOM and host nertworking 
assets is defined by the host. .

The best general implementation of <object> has the host browser 
inspect @type and then use whatever is registered as the current 
handler for that MIME to start up as a nested context identified in 
<object> by @id and/or @name. The object notifies the host context 
that it is alive and requests the <param> elements.

When all <param> content is received and acknowledged, the <object> is 
considered as a live nested context in the DOM. The host DOM may 
attach listeners with host DOM callbacks for specific events issued by 
the nested context. Likewise for the nested context. The nested 
context can expect to receive inputs from the host at anytime but is 
not required to acknowledge any but pre-defined events. Its internals 
are not accessible by the host DOM except by the standard <object> 
attributes and context defined interfaces.

There are four ways to interact with the nested context created by 
<object>:

1. Bring the nested context out into the DOM and manipulate its 
internal structure, letting the externalized DOM context negotiate the 
updates with the nested runtime.

2. Send events directly to the nested context by name and value as 
defined by the <param> interfaces and others recognized by the nested 
context.

3. Change standard live @data or @type or other attributes of <object> 
element.

4. Directly recreate and activate the <object>.

So, there is a lot that has to happen correctly in order for the host 
DOM to allow a live, scriptable nested context which is running more 
or less independently in the host and communicating freely with the 
host DOM and using host networking services.

In fact, the perfect <object> design for accessibility involves 
setting up this nested context that has complete live access to the 
rest of the document, setting its style and content according to the 
most convenient user interface features available.
But this is far from reality because the host browser and its DOM 
wants to make sure it is safe and so in most browsers free interaction 
of the host DOM and nested context is restricted in time and type. 
Just check the list of current browsers and you will find a range of 
author-defeating <object> implementation features.

Support for <object> with author-defined fallback has steadily 
improved over the years since it first appeared in W3C recommendations 
and has been of incredible importance as a tool for extending the 
basic capabilites of HTML.

For sure, in the years before <object> was accepted by all browsers, 
the history of the development and implementation of of an active 
object living in the document was dominated by work on <embed> with 
the main driver idea of securely integrating a living Flash object or 
a general media player runtime into the document. All of the 
restrictions either deal with safety of the resource put into the 
object (maybe thinking that the host browser is the most smartest 
about what should be allowed to go in), or plug-in specific details 
(like totally restarting the entire player to update content). What to 
do from here and what to allow as inputs and outputs from these 
objects is important now. We can take steps to assure a usefull and 
open <object> interface that allows a general purpose live 
scriptable/networkable object that works in all html browsers. I think 
getting consistent <object> features will also help analysis and 
implementation of what to do with inline code that wants to be 
dynamic.

>  The SVG WG would prefer that parameters could be changed 
> dynamically, and the updated values reflected automatically 
> parameters passed to the referenced content.

Great! That is what makes the <object> useful and directly accessible.

I need to have another round of testing for what is allowed. Part of 
problem is various plugins not understanding how to register their 
mime and not being consistent in the params they accept. But the 
largest part and the part that will add the most stability going 
forward is the W3C browsers agreeing on how to handle this nested 
context in terms of it being alive and trusted in the DOM and maybe 
with its own internal scripting and networking capabilities.

More on this later, I hope.

Thanks and Best Regards,
Joe

ps when I say more testing I mean for HTML DOM and other features like 
used in an example like this:

http://www.hypermultimedia.com/ajax3d/

SAI<=>DOM<=>XMLHttpRequest  is a simple concept of allowing the X3D 
nested context represented by the X3D SAI (Scene Access Interface) a 
way to talk to the host DOM, and vice-versa, and to get access to the 
network. I think we can see that this sort of capability is important 
and should work easily if the nested context were an html or svg 
document in <object> or <iframe>. I haven't looked for svg or flash 
examples that might do this stuff since. Sorry I haven't looked at 
these examples for a long time (still concerned with IE "object 
activation", even, sorry) and they only worked in a very limited 
subset with handholding then. All still works here from server with IE 
and Flux player; not sure now if Ff still works or any others stand 
any chance of working. Of course I am hoping for broader support of 
consistent functionality needed for this stuff both in the range of 
X3D players and in the HTML hosts.



----- Original Message ----- 
From: "Doug Schepers" <schepers@w3.org>
To: "public-html" <public-html@w3.org>
Sent: Friday, November 27, 2009 9:41 PM
Subject: 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 Tuesday, 1 December 2009 16:53:33 UTC