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

Greetings Shane, comments inline . . . 

Regards, Roland
FBCS, CITP
IBM Software Group, Strategy, Software Standards
Tel/Fax: +44 (0)1926-465440
Mobile: +44 (0)77 2520-0620

public-xhtml2-request@w3.org wrote on 07/05/2009 19:48:37:

> [image removed] 
> 
> Re: [ACTION-81] XML Events 2 draft updated
> 
> Shane McCarron 
> 
> to:
> 
> Mark Birbeck
> 
> 07/05/2009 19:52
> 
> Sent by:
> 
> public-xhtml2-request@w3.org
> 
> Cc:
> 
> XHTML WG
> 
> 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.

Agree

> 
> 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)" ).

Agree

> 
> Third, re-introduce the handler element as recently suggested by Mark 

Agree

> (with the param elements - why not?). 

Hmmm, no opinion as yet

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.

Agree

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

Disagree, by all means fix examples but I can see no harm in including a 
script example.

> 
> 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
> 
> 
> 






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU