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

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 14:01:12 UTC