Re: [ACTION-81] XML Events 2 draft updated

Okay....  I have discussed this at some length with Roland, and done 
some pondering.  The reason we moved script into  XML Events 2 was 
because we wanted a version that was 100% compatible with existing 
practice for use in XHTML 1.2. In other words, a version that has 
attributes like @charset and @type.  However, XHTML 1.2 is not going to 
include XML Events 2, so that's been overcome by events. Here's my proposal:

First, there is no reason at all to have the Script module in XML Events 
2.  Script is not really part of Events.  It is properly a part of XHTML 
2.  I propose we move it back into XHTML 2 / XHTML M12N 2 as a module.  
To the extent possible, ensure that the script element defined there is 
backward compatible with XHTML 1.  However, still define @implements 
because that's a direction we want to go.

Second, leave @function as defined in XML Events 2's Event module - 
possibly expanding the definition slightly so it is possible to pass 
parameters to the function named (e.g. function="myFunction(e, this)" ).

Third, re-introduce the handler element as recently suggested by Mark 
(with the param elements - why not?).  Have handler be part of the 
content model of the action element just as the script element is 
today.  I don't personally have a use for this element, but I can see 
how it could help some people who want to do simple handlers for events.

Finally, fix the examples in section 3.3.1 so they don't say anything 
about script. 

Comments?  Criticisms?  Fire away!

Shane McCarron wrote:
> Comments inline:
>
> Mark Birbeck wrote:
>> Hi Shane,
>>
>>  
>>> I actually think those examples are just misleading / confusing...
>>>     
>>
>> That is where I started when I began my email. :)
>>
>> I was commenting initially on the use of event registration on <img>
>> and was going to suggest that since this wouldn't work in HTML, we
>> might be storing up trouble by using it as an example.
>>
>> Then I noticed the <script> example, and then realised that <script>
>> was actually still in the spec, when I thought we'd agreed to remove
>> it.
>>
>>   
> A long time ago we decided to remove script in favor of handler.  Then 
> we realized that we needed script for compatibility and some other 
> reasons - not the least of which is that exclusively using a handler 
> element would mean you would be forced to declaratively create all 
> methods for supporting some event model inline.  Also, at the time we 
> revisited this the group determined that it would be wise to include 
> script because that would make it easier for user agents to support 
> XML Events 2.  At least, that's my recollection.
>>> ... and need to
>>> be updated to reflect the new use of the @function attribute.  We could
>>> re-introduce the handler element.  However, I don't know what that 
>>> would
>>> mean.
>>>     
>>
>> I've always seen <handler> as containing 'headless' script (or that's
>> at least one way it could be used). 
> ...
>>
>> There is simply no way that we could get a current browser to execute
>> a <script> element conditionally in this way.
>>   
> I don't think it is necessary to conflate the issues of script and 
> handler in this way.  A script is NOT a handler.  As defined in XML 
> Events 2 right now, it is the traditional script element that always 
> was in user agents - we have only added an attribute that provides 
> guidance to user agents so that going forward they can recognize that 
> a script was meant to bring in an implementation of some feature and 
> skip that if the user agent already has an implementation of that 
> feature.
>
> I can see the argument for supporting the handler element as a way of 
> having functions where the name of the function is effectively 
> declared on the handler element.  I can even see why having the 
> parameters be declared as you have described might be interesting.  
> But I maintain this is orthogonal.
>>  
>>> We *need* to define the script element so we can add @implements...
>>>     
>>
>> But the problem is that <script> already has defined behaviour in
>> current browsers, so how are we going to change that -- how can we get
>> a browser to ignore a <script> element, based on the @implements
>> value? By the time any extension such as a JavaScript library gets the
>> opportunity to look at the DOM and examine the @implements value, the
>> script will already have been run.
>>
>> (Obviously that problem doesn't exist with browser native code, but as
>> I said, that isn't likely to happen any time soon.)
>>   
> The definition in the draft does not change the value of the script 
> element, other than to add a SHOULD.  We were trying to enable a 
> future where implementations of various features come from elsewhere 
> (e.g. ubiquity).
>>
>>  
>>> ... and
>>> so that we have a consistent story about how scripts are part of the 
>>> XML
>>> Events model.
>>>     
>>
>> I agree, but I don't think we can get that by using the <script>
>> element itself. I still maintain that we should leave <script> alone,
>> and add other elements as 'intermediaries' to help us to achieve what
>> we want.
>>   
> I see your point, and I think we could do that too.  Also, I imagine 
> that the script element does not need to be defined in this spec.  It 
> is in here because we needed a place to hang the @implements 
> definition for XHTML 1.2.  But we could just define that embedded in 
> XHTML 1.2 I suppose.  We also needed it in here because of @function - 
> without <script> it is hard to tie @function to anything.
>
> Ideas?
>
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Thursday, 7 May 2009 18:49:16 UTC