W3C home > Mailing lists > Public > public-xhtml2@w3.org > August 2008

Re: XML Events 2 Scripting Module in XHTML 2

From: Shane McCarron <shane@aptest.com>
Date: Wed, 06 Aug 2008 08:08:38 -0500
Message-ID: <4899A256.6000007@aptest.com>
To: Roland Merrick <roland_merrick@uk.ibm.com>
CC: Mark Birbeck <mark.birbeck@webbackplane.com>, XHTML WG <public-xhtml2@w3.org>, public-xhtml2-request@w3.org

+1

Roland Merrick wrote:
>
> 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 
> <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/
>
>
>
>
>
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Wednesday, 6 August 2008 13:11:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:49 GMT