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

Re: XML Events 2 Scripting Module in XHTML 2

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Mon, 21 Jul 2008 10:49:58 +0100
Message-ID: <ed77aa9f0807210249x4ccff221p17b21c63c882e8e8@mail.gmail.com>
To: "Shane McCarron" <shane@aptest.com>
Cc: "XHTML WG" <public-xhtml2@w3.org>

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 ev:event="xforms-invalid" type="text/javascript">
    <!-- so will this -->

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



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



webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Monday, 21 July 2008 09:50:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:30:30 UTC