- From: David Carlisle <davidc@nag.co.uk>
- Date: Wed, 06 Jun 2012 10:48:13 +0100
- To: Frédéric WANG <fred.wang@free.fr>
- Cc: www-math@w3.org
On 31/05/2012 23:14, Frédéric WANG wrote: > 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>. > > https://bug748779.bugzilla.mozilla.org/attachment.cgi?id=618260 > > 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). If I understand you correctly then you are saying that after a user interaction you want to act as if maction always has a select attribute (so the value is never inherited). That seems perfectly reasonable to me. In many ways maction is there to give a certain basic layer of interactivity that is portable between browser/javascript instances and non-browser implementations. As such it really doesn't want to be too specified (in the spec) how it interacts with javascript as it isn't assumed that a javascript event model is there at all. In a browser context I think that the guiding principle would be to stay within the constraints of the spec so that simple cases have a chance of working in a non-javascript world, but otherwise be as much like the rest of the HTML/DOM/Javascript event handling as possible. so that the combined html+mathml language is as coherent as possible. David [personal response] ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________
Received on Wednesday, 6 June 2012 09:48:39 UTC