Re: unrecognized actiontype in maction

Yet another question. What is the rationale for handling nested maction 
that way:

"When a MathML application receives a mouse event that may be processed 
by two or more nested maction elements, the innermost maction element of 
each action type should respond to the event."

Wouldn't it be easier and maybe more consistent with other DOM event 
handling specifications to make only the innermost maction (whatever the 
actiontype) handle the event?

Then browsers may allow users to force custom handling with the standard 
defaultPrevented method (or something similar):

On 01/06/2012 00:14, Frédéric WANG wrote:
> While we are on maction, we have another question about maction with 
> actiontype=toggle. When the user clicks on the maction, we must change 
> the visible child. In Mozilla, this is implemented by modifying the 
> selection attribute in the DOM i.e. it is equivalent to do 
> mactionNode.setAttribute("selection", newSelection) in javascript. In 
> particular, this selection attribute is present when the document is 
> serialized (when you save the page or show the source for example). 
> That seems weird to me, but apparently it is the expected effect:
> "If a MathML application responds to a user command to copy a MathML 
> sub-expression to the environment's "clipboard" (see Section 6.3 
> Transferring MathML), any maction elements present in what is copied 
> should be given selection values that correspond to their selection 
> state in the MathML rendering at the time of the copy command."
> Another situation where this is problematic: in the test case, this 
> behavior prevents mstyle@selected to apply on a descendant <maction> 
> when it is set via javascript after the user clicked on the <maction>.
> Can you confirm it is the intended behavior? Or should implementers 
> store the selection value in a "private" variable i.e. which is not 
> accessible via the DOM but still present when the user copies the 
> MathML sub-expression (in that case, that's likely to be more 
> difficult to implement).

Frédéric Wang

Received on Friday, 1 June 2012 12:27:52 UTC