- From: <Nick_Van_den_Bleeken@inventivegroup.com>
- Date: Fri, 27 Jun 2008 09:13:29 +0200
- To: "Steven Pemberton" <steven.pemberton@cwi.nl>
- Cc: "Forms WG" <public-forms@w3.org>,"XHTML WG" <public-xhtml2@w3.org>
- Message-ID: <OF2B554835.108E84CC-ONC1257473.00559E3A-C1257475.0027AEC6@inventivegroup.com>
Hi Steven, I (as an implementer) included my answer in-line. > > Hi Forms WG, and in particular XML Events implementors, > > For XML Events 2 we have had a request that we be more specific about when > listeners get registered. > > We would like your advice: > > 1. What should the spec say about when listeners get initially registered? The spec should point out that the listeners should be attached in an early stage (as soon as possible I guess). In XForms for example we fire events when the XForms processor begins to initialize ( xforms-model-construct is sent to the models when the XForms processor is going to initialize itself) and document authors should be able to listen for those events. > 2. Should the listeners be live? In other words, if the DOM of the markup > gets changed, chould the listeners react? We don't think that DOM mutations to the declaratively defined event listeners should cause changes to the run-time listener objects (the attached listener shouldn't be removed, change its observer, listen to other events, ...). If the author wants to remove/change the declaratively added listener he should use the script API for dealing with event handlers directly and not change the DOM. If you use the declarative syntax and need conditional handlers you should use the if attribute instead of using script to add/remove the listener. Using this declarative syntax has the advantage that the conditionality is expressed in the document itself, what is good when you want to be able to save and digital sign your documents. Furthermore it is going to be nearly impossible in some implementations to support listening for mutation events because the markup DOM is provided host language processor and not by the XForms processor (one such example is a current web browser, it doesn't allows you to register for mutation events). I know that this is just a temporary technical implementation issue and should not prevent you from adding the feature, but I personally think it isn't good practice to automatically reflect changes made to the declarative XML events syntax to the run-time listener objects (those run-time listeners could already been changed by script, and then the declarative syntax is out of sync with its run-time state). > > Thanks for any advice you can give. > > Steven > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- > > Your e-mail was discussed by the WG and my answers therefore also reflect the feelings of the WG about your questions. Regards, Nick Van den Bleeken Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer = -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --
Received on Friday, 27 June 2008 07:14:13 UTC