Re: XML Events 2 Scripting Module in XHTML 2

Greetings Mark, I think that you are correct in pointing out that the 
<script> in the latest editors draft suffers from the problem is that its 
behaviour is not backwards-compatible with current browsers.

I think that we should have two elements defined in the handlers module. A 
new element, perhaps <handler> along the lines we have been discussing. We 
should also keep a <script> that is backwards-compatible with current 
browsers but with the additional of @implements.

If we proceed with <handler> and <script> then we should also allow an 
additional attribute to supplement @handler that allows a script function 
to be used much as it is today.

        @handler specifies the URI of resource that defines the action to 
take if the event reaches the observer.
        @function specifies the name of a function that is to be invoked 
if the event reaches the observer.

I think you are also correct in suggesting that 
        <script type="text/javascript" src="../mystuff/m.js" />
would be shorthand for
        <handler event="load" type="text/javascript" src="../mystuff/m.js" 
/>

Regards, Roland




From:
"Mark Birbeck" <mark.birbeck@webbackplane.com>
To:
"Shane McCarron" <shane@aptest.com>
Cc:
"XHTML WG" <public-xhtml2@w3.org>
Date:
21/07/2008 10:53
Subject:
Re: XML Events 2 Scripting Module in XHTML 2




Hi Shane,

I keep forgetting to mention that I also think we should change the
name of <script> in the module.

The problem is that its behaviour is not backwards-compatible with
current browsers. Current behaviour is to execute the script as it is
encountered, which will mean that handlers for specific events would
be run regardless:

  <xf:action ev:event="xforms-invalid">
    <script type="text/javascript">
      <!-- this will be run on load in old browsers -->
    </script>
  </xf:action>

  <script ev:event="xforms-invalid" type="text/javascript">
    <!-- so will this -->
  </script>

The sub-text is of course that it is good to make as much of what we
do backwards-compatible, so that our modules can be used independently
of XHTML 2.

Of course, we don't necessarily want to 'orphan' <script> and say that
it's no longer used. One way to avoid this would be to define <script>
as being a shorthand for:

  <script-handler-element-name-we-invent ev:event="load" 
type="text/javascript">
    <!-- do this on load -->
  </script-handler-element-name-we-invent>

<script-handler-element-name-we-invent> may just be <handler>...I
can't remember what happened to the XML Handler draft.

And the 'load' event might actually be something more akin to 'element
ready', since browsers seem to load and process scripts before the
entire document has completed loading.

But I'm sure you get what I'm driving at....

Regards,

Mark

On Mon, Jul 21, 2008 at 2:48 AM, Shane McCarron <shane@aptest.com> wrote:
>
> While editing XHTML 2 tonight, attempting to make all of the external
> references hang together, I noticed something that I don't know the 
solution
> for:
>
> If we are integrating XML Scripting into the XHTML namespace (as we have
> planned to do) then the script element will bring with it the attributes
> "encoding", "implements", "src", and "type".  Naturally, we also want 
the
> "script" element to take the Common attributes, which perforce include 
the
> Metainformation attributes (RDFa), the embedding attributes from XHTML 
2,
> etc...  Now @src and @encoding from the Embedding module are probably
> consistent with what we meant for the script element.   So that's fine. 
I
> think.  Correct me if I am wrong.
>
> @implements is a new thing, and there is no conflict.
>
> @type...   XML Events 2 goes to great pains to explain what @type 
means....
> and I think it is exactly what is meant by @srctype in XHTML 2.  So... I 
am
> not sure what to do here.  We can change @type to @srctype in XML Events 
2.
>  We can bring in @type on the script element, also bring in @src, and 
just
> have the script element reference the Common attributes collection (use 
a
> subset that makes sense, but does not include the embedding 
attributes)....
> or maybe something else.
> Help?
>
> --
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
>
>
>
>



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









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