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

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.


> ... 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). So this:

  <script>
    function doSomething() {
      alert("hello");
    }
  </script>

could become this:

  <handler name="doSomething">
      alert("hello");
  </handler>

This would be very easy for a JavaScript library to implement, since
all it amounts to is creating a method on the global object using the
name provided by @name, and setting the function body to the text in
the element:

  window["doSomething"] = function () {
    alert("hello");
  };

Other JavaScript code can call the function in the usual way:

  doSomething();

It's the same as if the function had been defined using <script>, but
the big advantage of adding this additional step to the processing is
that the browser doesn't see it as script until we tell it to -- which
allows us to do things like @implements (which should surely be @role,
no?), @if, @when, and so on.

For example, in XForms, a script handler could be mixed in with
ordinary handlers, like this:

  <xf:trigger>
    <xf:label>Click me!</xf:label>
    <xf:action ev:event="DOMActivate">
      <ev:handler if="/value = true()">
        alert("hello");
      </ev:handler>
      <xf:load resource="mypage.html" />
    </xf:action>

There is simply no way that we could get a current browser to execute
a <script> element conditionally in this way.

(I know we always say that we don't want our specifications to be
driven by how things might be implemented, but equally, the last few
years has shown us that the first implementers are not going to be the
browser vendors, so we might as well think about how this could be
done.)


By the way, an even better way to define <handler> would be to take an
XBL-style approach, and provide a way to define parameters, and so on.
For example, we might have:

  <handler name="power">
    <param name="a" />
    <param name="b" />
    <implementation>
      return Math.power(a, b);
    </implementation>
  </handler>

The actual language used to define the body of the code could in turn
be attached to <implementation>, allowing the processor to choose
whichever implementation is most appropriate:

  <handler name="power">
    <param name="a" />
    <param name="b" />
    <implementation type="text/javascript">
      return Math.power(a, b);
    </implementation>
    <implementation type="text/vbscript">
      return a ** b;
    </implementation>
  </handler>

And so on.

This would not only provide the event handlers we need, but would be a
useful mechanism for adding new functions to languages that use XPath,
such as XForms.


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


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

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 7 May 2009 13:05:22 UTC