XHTML-compliant document.write

[Michael Powe]

How can I make an XHTML-compliant form of an expression in this
format:

document.write("<scr"+"ipt type='text/javascript' src='path/to/file.js'>"+"</scr"+"ipt>");

this turns out to be a non-trivial exercise. inserting '&lt;' and
'&gt;' causes the browser to write the text to the page as literal
text rather than as the intended script element. Using escape codes
seemed to work (makes it standard compliant) but the text is not
written to the page.

The point is to have a conditional branch in which, when a certain
condition is true, a script tag will be generated that will call a
JS include that responds to the specific condition.

This procedure works in the present implementation -- but fails XHTML
compliance testing. Now, we would like to have both.

Thanks.

mp

--
Michael Powe mi*****@trollope.org Naugatuck CT USA

'Unless we approve your idea, it will not be permitted, it will not be
allowed.' -- Hilary Rosen, President, RIAA

[Jim Ley]

On 10 May 2006 09:36:54 -0400, Michael Powe
<mi**********@trollope.org> wrote:

How can I make an XHTML-compliant form of an expression in this
format:

document.write("<scr"+"ipt type='text/javascript' src='path/to/file.js'>"+"</scr"+"ipt>");
Well you have a few problems, not least that the majority of XHTML
user agents believe that document.write is undefined for XHTML
documents - they're wrong, the HTML DOM clearly defines it, but that
doesn't stop the above simply not working in a genuine XHTML User
Agent.
this turns out to be a non-trivial exercise. inserting '&lt;' and
'&gt;' causes the browser to write the text to the page as literal
text rather than as the intended script element. Using escape codes
seemed to work (makes it standard compliant) but the text is not
written to the page.
The above snippet is in any case entirely valid XHTML, assuming you
place it in an appropriate place, ie inside a CDATA section.
This procedure works in the present implementation -- but fails XHTML
compliance testing. Now, we would like to have both.

There's little point in attempting to fix it, when as soon as you do
it will fail user testing as the document.write will simply fail in
current XHTML UA's.

Jim.

[VK]

Michael Powe wrote:

How can I make an XHTML-compliant form of an expression in this
format:

document.write("<scr"+"ipt type='text/javascript' src='path/to/file.js'>"+"</scr"+"ipt>");

this turns out to be a non-trivial exercise. inserting '&lt;' and
'&gt;' causes the browser to write the text to the page as literal
text rather than as the intended script element. Using escape codes
seemed to work (makes it standard compliant) but the text is not
written to the page.

The point is to have a conditional branch in which, when a certain
condition is true, a script tag will be generated that will call a
JS include that responds to the specific condition.

This procedure works in the present implementation -- but fails XHTML
compliance testing. Now, we would like to have both.

There is a little use to care of XHML, this format is not used
anywhere, and in few places where it is used it is served as text/html
and thus parsed as trached up HTML anyway.

Jim Ley already pointed on obstacles relevant to your particular
situation.

Yet no one is in power to regulate your personal desires :-) If you are
determined to make your code XML valid (despite still not working in
XHTML) you can use a combo for mixed environments (where you don't know
in advance if it will be parsed as HTML or XML). We are using it for
bindings in XSLT:

<script type="text/javascript">/*<![CDATA[*/
// your code goes here
/*]]>*/</script>

if parsed as HTML, it will see two /*...*/ comments, and lt/gt signs
wil not break the parsing anyway.

if parsed as XML, it will see /**/ node value and CDATA block will hide
all lt/gt.

A bit ugly looking, but bulletproof.

[cwdjrxyz]

Michael Powe wrote:

How can I make an XHTML-compliant form of an expression in this
format:

document.write("<scr"+"ipt type='text/javascript' src='path/to/file.js'>"+"</scr"+"ipt>");

Document.write is taboo in xhtml 1.1 because it will not validate as
xml and may cause some pages to fail. If you serve the xhtml 1.1 page
correctly as application/xhtml+xml, the page is parsed as xml by
browsers that can handle it, and the least little xml error usually
gives you an error message instead of the page or the page just does
not work at all. In true xhtml, everything downloaded from the server
needs to be checked for xml errors. The document.write is, in effect, a
closed box that could contain all sorts of xml errors, such as unclosed
tags, once the box is opened after download. Such surprises are not
allowed in xml and can cause all sorts of problems in xml only devices.
I find the most simple way to handle the document.write problem is to
use php script on the server so that what the document.write would do
is done on the server and you then download the resulting code that the
xhtml aware browser can examine. Of course IE6, and probably IE7, can
not handle true xhtml served as the correct mime type, and you just get
error messages and no page displayed. You have to provide an alternate
page in html 4.01 strict, for example, for IE6. Of course if you serve
the xhtml 1.1 page incorrectly as html rather than true xhtml, the page
will also work on IE, but then why bother to use xhtml in the first
place if you do this. There is only one version of xhtml 1.1 (very
strict), and some of the tricks that would work on xhtml 1.0
transitional will not work on it.

[Michael Powe]

>>>>> "Jim" == Jim Ley <ji*@jibbering.com> writes:

Jim> On 10 May 2006 09:36:54 -0400, Michael Powe
Jim> <mi**********@trollope.org> wrote:

How can I make an XHTML-compliant form of an expression in this
format: document.write("<scr"+"ipt type='text/javascript'
src='path/to/file.js'>"+"</scr"+"ipt>");
Jim> Well you have a few problems, not least that the majority of
Jim> XHTML user agents believe that document.write is undefined
Jim> for XHTML documents - they're wrong, the HTML DOM clearly
Jim> defines it, but that doesn't stop the above simply not
Jim> working in a genuine XHTML User Agent.
this turns out to be a non-trivial exercise. inserting '&lt;'
and '&gt;' causes the browser to write the text to the page as
literal text rather than as the intended script element. Using
escape codes seemed to work (makes it standard compliant) but
the text is not written to the page.
Jim> The above snippet is in any case entirely valid XHTML,
Jim> assuming you place it in an appropriate place, ie inside a
Jim> CDATA section.
This procedure works in the present implementation -- but fails
XHTML compliance testing. Now, we would like to have both.

Jim> There's little point in attempting to fix it, when as soon as
Jim> you do it will fail user testing as the document.write will
Jim> simply fail in current XHTML UA's.

Unfortunately, this is being written for a client who wants -- or,
rather, insists that -- his pages validate as XHTML. We're not in a
position to say no. ;-)

I will follow up on your suggestion about CDATA.

Thanks.

mp

--
Michael Powe mi*****@trollope.org Naugatuck CT USA
COMPETITION: An event in which there are more losers than winners.
Otherwise it's not a competition. A society based on competition is
therefore primarily a society based on losers. -- John Ralston Saul

[Michael Powe]

>>>>> "VK" == VK <sc**********@yahoo.com> writes:

VK> Michael Powe wrote:

How can I make an XHTML-compliant form of an expression in this
format: document.write("<scr"+"ipt type='text/javascript'
src='path/to/file.js'>"+"</scr"+"ipt>");

VK> There is a little use to care of XHML, this format is not used
VK> anywhere, and in few places where it is used it is served as
VK> text/html and thus parsed as trached up HTML anyway.

VK> Jim Ley already pointed on obstacles relevant to your
VK> particular situation.

VK> Yet no one is in power to regulate your personal desires :-)
VK> If you are determined to make your code XML valid (despite
VK> still not working in XHTML) you can use a combo for mixed
VK> environments (where you don't know in advance if it will be
VK> parsed as HTML or XML). We are using it for bindings in XSLT:

VK> <script type="text/javascript">/*<![CDATA[*/ // your code goes
VK> here /*]]>*/</script>

VK> if parsed as HTML, it will see two /*...*/ comments, and lt/gt
VK> signs wil not break the parsing anyway.

VK> if parsed as XML, it will see /**/ node value and CDATA block
VK> will hide all lt/gt.

Thanks for the suggestion. We'll look into it. We are putting this
up for a client who is in a position to insist on XHTML validation.
Not our call, unfortunately.

Thank you.

mp

--
Michael Powe mi*****@trollope.org Naugatuck CT USA
It could have been an organically based disturbance of the brain --
perhaps a tumor or a metabolic deficiency -- but after a thorough
neurological exam it was determined that Byron was simply a jerk.
-- Jeff Jahnke, runner-up, Bulwer-Lytton contest

[Jim Ley]

On 10 May 2006 13:42:38 -0400, Michael Powe
<mi**********@trollope.org> wrote:

>> "VK" == VK <sc**********@yahoo.com> writes:

VK> if parsed as XML, it will see /**/ node value and CDATA block
VK> will hide all lt/gt.

Thanks for the suggestion. We'll look into it. We are putting this
up for a client who is in a position to insist on XHTML validation.
Not our call, unfortunately.

It doesn't matter whose call it is, you cannot use both document.write
and XHTML in current era user agents, the validation is not your
problem.

Jim.

[Richard Cornford]

Michael Powe wrote:

"Jim" == Jim Ley writes: <snip>Jim> There's little point in attempting to fix it, when as
Jim> soon as you do it will fail user testing as the
Jim> document.write will simply fail in current XHTML UA's.

Unfortunately, this is being written for a client who wants --
or, rather, insists that -- his pages validate as XHTML.
We're not in a position to say no. ;-)

<snip>

What is the point in the client requiring that the mark-up validates as
XHTML if the scripts are absolutely depended upon the document only ever
being interpreted as HTML? It seems to me that either the client needs
to be informed of the futility/stupidity of their requirement, or you
should be creating scripts that would be interoperable with HTML and
XHTML DOMs (to satisfy the spirit of the client's requirement). So not
be using - document.write - at all.

Incidentally, if you import the script as an external JS file its
contents will never be considered during the validation of the XHTML
mark-up.

And while I am at it, the concatenation in:-

document.write(
"<scr"+"ipt ... /file.js'>"+"</scr"+"ipt>"
);

- is unnecessary and is indicative of someone not understanding why they
are doing what they are doing. The issue is that if the (x)HTML parser
encounters the character sequence '</script>' inside a script element it
has no alternative but treat that as the closing tag for the script
element. Officially the issues is a little wider than this as the HTML
specification allows the browser to regard any occurrence of the
character sequence '</' as closeing the script element. No browser is
known to be that strict, but validators may (will) be.

The issue is addressed by either putting the code in an external file so
that the (x)HTML parser will never see it, or by disrupting the
'</script> character sequence. The concatenation of the closing tag
string achieves this, but the point at which '</script>' is split fails
to address the official issue (the '</' sequence). All of the other
concatenations in the string literal are superfluous, they represent a
kind of mystical incantation; the result 'works' but the author does not
know why they are there, else they would not (all) be there.

The preferred method of addressing this issue is through the '</'
sequence, by escaping the forward slash, so the result becomes '<\/'.
And the total string would become the shorter, and more efficient
(because no runtime concatenation, and consequential intermediate string
creation, is needed):-

"<script type='text/javascript' src='path/to/file.js'><\/script>"

While we are on the subject of escaping, that could also be used to
address the XHTML PCDATA issue in this case (as the offending characters
are in a string literal) as the '<' and '>' characters could be escaped
into the Unicode escape sequences '\u003C' and '\u003E' respectively.
This escaping would also render the '</' sequence invisible to the XHTML
parser:-

"\u003Cscript ... /file.js'\u003E\u003C/script\u003E"

Richard.

[Richard Cornford]

cwdjrxyz wrote:

Michael Powe wrote:

How can I make an XHTML-compliant form of an expression
in this format:

document.write("<scr"+"ipt type='text/javascript'
src='path/to/file.js'>"+"</scr"+"ipt>");

Document.write is taboo in xhtml 1.1 because it will not
validate as xml and may cause some pages to fail.

<snip>

Rubbish. A validator will have no interest in the exact function/method
calls within a document. Using - document.write - inside a script
element will have no impact upon the validity of an XHTML document.

The reason for not using - document.write - in/with an XHTML document is
that no current XHTML DOM implementations support its use. A practical
consideration rather than a question of validity.

Richard.

[cwdjrxyz]

cwdjrxyz wrote:

Michael Powe wrote:

How can I make an XHTML-compliant form of an expression in this
format:

document.write("<scr"+"ipt type='text/javascript' src='path/to/file.js'>"+"</scr"+"ipt>");

Document.write is taboo in xhtml 1.1 because it will not validate as
xml and may cause some pages to fail. If you serve the xhtml 1.1 page
correctly as application/xhtml+xml, the page is parsed as xml by
browsers that can handle it, and the least little xml error usually
gives you an error message instead of the page or the page just does
not work at all. In true xhtml, everything downloaded from the server
needs to be checked for xml errors. The document.write is, in effect, a
closed box that could contain all sorts of xml errors, such as unclosed
tags, once the box is opened after download. Such surprises are not
allowed in xml and can cause all sorts of problems in xml only devices.
I find the most simple way to handle the document.write problem is to
use php script on the server so that what the document.write would do
is done on the server and you then download the resulting code that the
xhtml aware browser can examine. Of course IE6, and probably IE7, can
not handle true xhtml served as the correct mime type, and you just get
error messages and no page displayed. You have to provide an alternate
page in html 4.01 strict, for example, for IE6. Of course if you serve
the xhtml 1.1 page incorrectly as html rather than true xhtml, the page
will also work on IE, but then why bother to use xhtml in the first
place if you do this. There is only one version of xhtml 1.1 (very
strict), and some of the tricks that would work on xhtml 1.0
transitional will not work on it.

I will give you an extreme example of what using document.write can do
for various versions of xhtml/html. First examine the page
http://www.cwdjr.info/dhtml/7veilsDance.html. This is just a
conventional html 4.01 strict page loaded with document.writes. The
document.write is used within loops to write the code for up to
thousands of divisions to produce vertical and horizontal grids of very
narrow lines and produce a color gradient on some. This is used to
produce transparency and grad color effects. It validates at W3C as
html 4.01 strict, and if you use the W3C extended interface, you find
that the page is being served as text/html. Now look at the page at
http://www.cwdjr.info/dhtml/7veilsDancePsudoXhtml.html and also
validate. You will find that it also validates, but that it is also
being served as text/html and not xhtml. The CDATA xml tags added
prevent the script section being validated as xml which would produce
numerous error. The correct closing tags such as <br /> have been
added. The moral here is that the W3C validator has validated the code
as correct xhtml1.1. However it finds the code is not being served as
xhtml - just html. The validator only says that the code has no formal
errors - it does not say that the page is served properly or that it
will work. Many have thought that the W3C correct validation for such a
psudo xhtml page means that they are serving xhtml, but if they would
bother to use the extended interface of the validator they would find
that they are just serving text/html. The html 4.01 strict page and
psudo xhtml page work on most common recent browsers including IE6,
Firefox, Netscape, Mozilla and Opera.

Now let us serve the page as true xhtml 1.1. See
http://www.cwdjr.info/dhtml/7veilsDance.xhtml . On my server, the
extension .html is associated with the mime type for html, while the
extension .xhtml is associated with the mime type for xhtml+xml. Now
something very interesting happens to the page. If you validate at W3C
you will find the page valid, and that it is being served as
application xhtml+xml rather than text/html. Now if you look at the
page on an xhtml capable browser such as Firefox, Opera, etc you will
find the page is missing everything that was produced by all of the
document.writes. If you have a WMP you will see a control button for it
at the top of the page. This was generated by an object for the WMP and
not a document.write. However if you try to view the page on IE6 you
just get an error message that IE6 can not handle the xml. If I wanted
to overcome this problem, I likely would write most of the script as
php on the server as I have done in other like cases. However the page
I am using is just a test page for some experiments and not something
intended for a specific web page. It no doubt could be and should be
cleaned up somewhat if one were considering it for a useful web page.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

[...]
And while I am at it, the concatenation in:-

document.write(
"<scr"+"ipt ... /file.js'>"+"</scr"+"ipt>"
);

- is unnecessary and is indicative of someone not understanding why they
are doing what they are doing.
Yes, indeed.
The issue is that if the (x)HTML parser encounters the character
sequence '</script>' inside a script element it has no alternative
but treat that as the closing tag for the script element.

Noticing that you included X(HT)ML parsers here as well, I have to say no.

The following cases must be clearly distinguished:

1. Character data as content of the HTML `script' element

You explained that again correctly in the part I snipped here.

2. Character data as content of the XHTML `script' element as is

The data is considered PCDATA (parsed character data), due to the content
model of the _XHTML_ `script' element. Therefore, any markup character,
unless escaped, is considered the end of character data:

,-[XML 1.0, 2.4 Character Data and Markup, §4]
|
| In the content of elements, character data is any string of characters
| which does not contain the start-delimiter of any markup and does not
| include the CDATA-section-close delimiter, "]]>".

The "start-delimiter of any markup" refers to unescaped `&', and `<',
respectively.

3. Script code as content of a CDATA section within the XHTML `script'
element

,-[ibid.]
|
| In a CDATA section, character data is any string of characters not
| including the CDATA-section-close delimiter, "]]>".

That `</' (ETAGO) or an end tag character sequence (here: `</script>') is
_always_ indicative of the end of character data, is an SGML parsing rule
that is not adopted by XML.
And Michael, please stop using name prefixes for your quotations, and do
reduce their indentation to zero, so that the maximum number of characters
are visible within an 80-columns window. Use an attribution line instead.
TIA.
PointedEars
--
Alcohol and Math don't mix. So please don't drink and derive!

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

[...]
And while I am at it, the concatenation in:-

document.write(
"<scr"+"ipt ... /file.js'>"+"</scr"+"ipt>"
);

- is unnecessary and is indicative of someone not understanding why they
are doing what they are doing.
Yes, indeed.
The issue is that if the (x)HTML parser encounters the character
sequence '</script>' inside a script element it has no alternative
but treat that as the closing tag for the script element.

Noticing that you included X(HT)ML parsers here as well, I have to say no.

The following cases must be clearly distinguished:

1. Character data as content of the HTML `script' element

You explained that again correctly in the part I snipped here.

2. Character data as content of the XHTML `script' element as is

The data is considered PCDATA (parsed character data), due to the content
model of the _XHTML_ `script' element. Therefore, any markup character,
unless escaped, is considered the end of character data:

,-[XML 1.0, 2.4 Character Data and Markup, §4]
|
| In the content of elements, character data is any string of characters
| which does not contain the start-delimiter of any markup and does not
| include the CDATA-section-close delimiter, "]]>".

The "start-delimiter of any markup" refers to unescaped `&', and `<',
respectively.

3. Character data as content of a CDATA section within the XHTML `script'
element

,-[ibid.]
|
| In a CDATA section, character data is any string of characters not
| including the CDATA-section-close delimiter, "]]>".

That `</' (ETAGO) or an end tag character sequence (here: `</script>') is
_always_ indicative of the end of character data, is an SGML parsing rule
that is not adopted by XML.
And Michael, please stop using name prefixes for your quotations, and do
reduce their indentation to zero, so that the maximum number of characters
are visible within an 80-columns window. Use an attribution line instead.
TIA.
PointedEars
--
Alcohol and Math don't mix. So please don't drink and derive!