Section 16.2 Proposed amendment from Byington, Dale on 2001-04-10 (xsl-editors@w3.org from April to June 2001)

From: Byington, Dale <ByingtonD@peacetech.com>
Date: Tue, 10 Apr 2001 11:49:45 -0400 (EDT)
To: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
Message-ID: <450251B8E6DA1E4EAE9DA56C850B025C04BA55@ptint1.peacetech.com>
Dear Editors:
	I feel that something has been overlooked in the XSL Transformations
recommendation, Section 16.2. While discussing the HTML Output Method, the
recommendation clearly states that no encoding/escaping is to be performed
on the content of <script> tags. I believe that this prohibition should also
extend to <a> tags where the href attribute contains the prefix
"javascript:". I came across a problem while using Apache Xalan 2.0.1 that
complies to your specification. It escaped the href attribute, casuing my
JavaScript function calls to either not run, or to produce erroneous output.
Included below is a copy of a discussion about this topic on the Apache
Xalan developers list group. In it, I lay out the problem I am experiencing
in detail, as well as why I feel that any href beginning with "javascript:"
should not be encoded. I appreciate your consideration of this matter, and
hope that you will find merit in my reasoning. Thank You.

 <<urltest.xml>>  <<urltest.xsl>> 

Dale Byington 
Peace Technology, Inc. 
13685 Baltimore Avenue 
Laurel, MD 20707-5096 
Phone:  (301) 206-9696 
Fax:  (301) 206-9722 




-----Original Message-----
From: Byington, Dale [mailto:ByingtonD@peacetech.com]
Sent: 9 àïðåëÿ 2001 ã. 14:03
To: 'xalan-dev@xml.apache.org'
Subject: Problems with Xalan 2.0.1 and url encoding


I having a problem related to url encoding. I am using Xalan 2.0.1, and
Netscape 4.7. 
The problem is that if I have a url that runs JavaScript, the JavaScript
function arguments get encoded as if they were a URL. 
Given this XML: 
<?xml version="1.0" encoding="UTF-8"?> 
<root/> 
and this stylesheet: 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0"> 
<xsl:output method="html" media-type="text/html" indent="no"/> 
<xsl:template match="/root"> 
        <html> 
                <head> 
                        <script language="JavaScript"
type="text/javascript"> 
                        function sendMessage(string1, string2) { 
                                alert(string1 + string2); 
                        } 
                        </script> 
                </head> 
                <body> 
                        <a href="javascript:sendMessage('hello ',
'world')">Send Message</a><br/> 
                        <a href="javascript:sendMessage('hello
','world')">Send Message2</a> 
                </body> 
        </html> 
</xsl:template> 
</xsl:stylesheet> 


The link should look like this: 
        <a href="javascript:sendMessage('hello ', 'world')">Send Message</a>

Xalan renders this line like: 
        <a href="javascript:sendMessage('hello%20',%20'world')">Send
Message</a> 
When you click on the link in Netscape, nothing happens. 
If you remove the space between the arguments like this: 
        <a href="javascript:sendMessage('hello ','world')">Send Message2</a>

Xalan will encode it like this: 
        <a href="javascript:sendMessage('hello%20','world')">Send
Message2</a> 
Clicking on the link will result in an alert dialog box displaying the text
"hello%20world", instead of "hello world". 
As you can see, depending on how the JavaScript is written, the link will
either not function at all, or will display the wrong data
to the user. The site I am working on is heavily JavaScript driven, with
just about every page being accessed via a JavaScript function. 
JavaScript puts the url together and then changes the location object of the
browser window to complete the navigation. 
I was wondering if there is a way to turn automatic url encoding off?  Older
versions of Xalan did not have this feature, and I'm sure there are many
sites out there that are JavaScript driven like mine. Unfortunately, I need
to use Xalan 2.0.X to provide some needed functionality for the site, so I
can't just switch to an older Xalan. If there currently isn't a way to
disable this feature, could you please provide a mechanism to disable this
feature in the upcoming builds? I would greatly appreciate any help on this
matter, as my project has currently ground to a halt.
<<urltest.xml>> <<urltest.xsl>> 

-----Original Message-----
From: Voytenko, Dimitry [mailto:DVoytenko@SECTORBASE.COM]
Sent: Tuesday, April 10, 2001 2:47 AM
To: 'xalan-dev@xml.apache.org'
Subject: RE: Problems with Xalan 2.0.1 and url encoding


Hi Dale,

that's right, and Xalan does it according to XSLT 1.0 specification. See
16.2 section. Unfortunately, only Xalan 2 does that, not 1.X. So they only
way to avoid this problem is not using javascripts in HREF and SRC
attributes. Use ONCLICK attribute. It's almost the same.

Thanks,
Dmitry
 
------Original Message-----
From: Byington, Dale [mailto:ByingtonD@peacetech.com]
Sent: Tuesday, April 10, 2001 11:49AM
To: 'xalan-dev@xml.apache.org'
Subject: RE: Problems with Xalan 2.0.1 and url encoding

Thanks for the work around. My site is now running again. 

I read section 16.2 of the specification prior to posting my message. I
still don't understand why Xalan would take perfectly valid HTML code and
change it in such a way as to make it invalid. Calling JavaScript functions
using the href attribute of the anchor tag is a widely accepted approach, as
well as being valid HTML. While I understand that URL encoding is a good and
necessary thing, JavaScript function calls are not really URLs, since they
don't use any protocol (http, https, ftp, mailto, etc.) to reference data. 

The specification states that no encoding should be done on data/text
between <script> or <style> tags. The W3C recognizes that encoding text
meant to be executed as a script would be detrimental to that script. Since
we are talking about JavaScript function calls, not URL references, the
W3C's prohibition against encoding script code should still apply. 

In order to implement the work around you suggested, the following HTML
change is required for proper execution:

from 68 characters 
	<a href="javascript:sendMessage('hello ', 'world')">Send Message</a>
to 86 characters
	<a href="javascript:void(0)" onClick="sendMessage('hello ',
'world')">Send Message</a>

This increases the size of the rendered page. For the site I'm working on,
my stylesheet can generate thousands of such links. Let's look at the impact
of this change with different numbers of links:

# of Links		Page Size Increase		Download Time
Increase (56K modem, 3K/second)
100			 1,800 bytes,  1.75K		  .5 seconds
500			 9,000 bytes,  8.79K		 2.9 seconds
1000			18,000 bytes, 17.58K		 5.9 seconds
1500			27,000 bytes, 26.37K		 8.8 seconds	
2000			36,000 bytes, 35.16K		11.7 seconds


NOTE: Kilobyte calculations rounded to the nearest hundredth of a kilobyte. 
      Time calulations rounded to the nearest tenth of a second.

Since every JavaScript function call inside an href will always begin with
"javascript:", Xalan could easily choose not encode the contents of the href
attribute when it sees that prefix. The "javascript:" prefix should be
treated the same as a <script> tag, since they both indicate that script
code exists and will be executed. This behavior would be consistent with the
spirit of the W3C's prohibition of encoding script code, as well as making
Xalan easier to use. Xalan should not turn valid HTML into invalid HTML, nor
should it force users to have increased page sizes and longer download
times. It should not for users to avoid widely accepted and valid practices
for using script technologies. Companies should not have to absorb the cost
of changing valid HTML code to get their sites to run using the latest
XSL/XSLT technologies. 

All it would take to fix this problem is a simple if statement that would
either recognize the "javascript:" prefix or recognize that the user does
not wish to perform url encoding (via an option in a configuration file) and
then not encode the contents of the href attribute. 

While it is true that I could make this change myself, neither my company or
I want to create and distribute a custom version of Xalan to our clients.
Every time a new version is released, someone would have to make the change
again. This process would not only waste valuable time, but also needlessly
waste money on something that should not even be a problem. As more people
embrace XML and XSL technologies, this problem is going to persist and grow.
It will eventually turn into one of these questions that people repeatedly
ask about in newsgroups. Xalan-dev subscribers will start to groan "Oh no,
not *that* question again!" It makes sense to address this problem before it
gets to that point. Not only from a business perspective, but also because
it is the right thing for Xalan. This message will also be forwarded to the
W3C for consideration of ammending the XSLT Specification to recognize this
issue.
Attachments

application/octet-stream attachment: urltest.xml
application/octet-stream attachment: urltest.xsl
Received on Wednesday, 11 April 2001 06:41:34 UTC