better way to dynamically link to an external js file?

[Nick]

Right now I'm using

document.write("<script language='javascript' src='jsFile" + i +
".js'></script>");

It works -- I have a lot of data in each file and only want the
visitor to have to download the necessary file. Is there a better way
to do this?

Just curious because the page doesn't validate in HTML validators.

[David Dorward]

Nick wrote:

document.write("<script language='javascript' src='jsFile" + i +
".js'></script>");
....
the page doesn't validate in HTML validators.

http://validator.w3.org/docs/help.html#faq-javascript

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Yvon Kephren]

vc*******@spamcop.net (Nick) wrote in message news:<37**************************@posting.google. com>...

Right now I'm using

document.write("<script language='javascript' src='jsFile" + i +
".js'></script>");

It works -- I have a lot of data in each file and only want the
visitor to have to download the necessary file. Is there a better way
to do this?

Just curious because the page doesn't validate in HTML validators.

Yes I had the same problem and I decided to use the
document.createElement so as for an example of how you would do this.

var newScript = document.createElement("script");
newScript.setAttribute("language","javascript");
newScript.setAttribute("src","jsFile" + i + ".js");

Now depending on what browser you are useing some options are
avaliable here.
For mozilla you can do
document.body.appendChild(newScript);

otherwise you can do this
document.documentElement.appendChild(newScript);

but what I decided to do is
document.getElementById("scriptBase").appendChild( newScript);

If you have alot of these scripts like you say you can make an array,
for loop and a tester to see if its the right client

[Mike Foster]

On 15 Jun 2004 18:13:52 -0700, Nick <vc*******@spamcop.net> wrote:

Right now I'm using

document.write("<script language='javascript' src='jsFile" + i +
".js'></script>");

It works -- I have a lot of data in each file and only want the
visitor to have to download the necessary file. Is there a better way
to do this?

Just curious because the page doesn't validate in HTML validators.

Hi Nick,

The xhtml will be invalid if the javascript has '<' or '&',
and there are a few other details - check out the link David posted
(which will lead you to: http://www.htmlhelp.com/tools/validator/problems.html).
Also check out the xhtml spec.

Here's another idea - one which is very cross-browser and
will also allow your xhtml file to validate :-)

* In your xhtml file...

<script type='text/javascript'>
var jsFileNumber = 1;
</script>
<script type='text/javascript' src='loader.js'></script>
* In loader.js...

document.write("<" + "script type='text/javascript' src='jsFile" + jsFileNumber + ".js'><" + "/script>");

[Richard Cornford]

Mike Foster wrote:

Nick wrote:

Right now I'm using

document.write("<script language='javascript' src='jsFile" + i +
".js'></script>");

<snip> * In your xhtml file...
I didn't notice anything about the code provided above that would
suggest that it is XHTML, indeed the use of a language attribute would
suggest otherwise.
<script type='text/javascript'>
var jsFileNumber = 1;
</script>
<script type='text/javascript' src='loader.js'></script>
* In loader.js...

document.write("<" + "script type='text/javascript' src='jsFile" +
jsFileNumber + ".js'><" + "/script>");

As Mozilla browsers do not implement the W3C HTML DOM - HTMLDocument -
interface on the document object in their XHTML DOM there is no -
write - method to use in that environment, so this could not be a good
plan in an XHTML document.

But within an HTML document it is only necessary to obscure the
character sequence - </ - to validate, though concatenation is an
extreme approach when inserting an escape character to give - <\/ - will
achieve the desired effect for no additional operations.

document.write("<script type='text/javascript' src='jsFile" +
jsFileNumber + ".js'><\/script>");

External JS files do not need any escaping/masking of the - </ -
sequence because they go strait to the javascript interpreter and are
never considered by HTML or XML parsers.

Richard.

[Mike Foster]

Richard Cornford said:

I didn't notice anything about the code provided above that would
suggest that it is XHTML, ...

Oops, I assumed wrong ;-)

Richard Cornford said:
As Mozilla browsers do not implement the W3C HTML DOM - HTMLDocument -
interface on the document object in their XHTML DOM there is no -
write - method to use in that environment, so this could not be a good
plan in an XHTML document.
I've heared others say that, but I don't understand it because it does work
in Mozilla (I've provided a little test case at the end of this post). I
can't find it in the XHTML 1.0 spec. Is it in the 1.1 spec? Is that why it
works in my test case? Its confusing to me that a markup language spec would
have anything to say about objects exposed by a scripting engine.

Richard Cornford said:
But within an HTML document it is only necessary to obscure the
character sequence - </ - to validate, though concatenation is an
extreme approach when inserting an escape character to give - <\/ - will
achieve the desired effect for no additional operations.
...
External JS files do not need any escaping/masking of the - </ -
sequence because they go strait to the javascript interpreter and are
never considered by HTML or XML parsers.

Good clarifications - thanks.

Test case for using "document.write" in XHTML 1.0:

* The XHTML file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<script type='text/javascript' src='xhtml_docwrite.js'></script>
</head>
<body>
<script type='text/javascript'>
sayHi();
</script>
</body>
</html>

* The Javascript file:

function sayHi()
{
document.write("<h1>Hello World!</h1>");
}

[Richard Cornford]

Mike Foster wrote:

Richard Cornford said: <snip>

As Mozilla browsers do not implement the W3C HTML DOM - HTMLDocument
- interface on the document object in their XHTML DOM there is no -
write - method to use in that environment, so this could not be a
good plan in an XHTML document.

I've heared others say that, but I don't understand it because it
does work in Mozilla (I've provided a little test case at the end of
this post).

The illusion that it works is brought about by writhing to XHTML 1.0
_Appendix_C_ and serving the pages as text/html. But Appendix C defines
a strategy for creating XHTML files that can be interpreted as (or, more
realistically, error-corrected into) HTML, and content type herders of
text/html tell the browser that what it is getting is HTML, so it
interprets it as such. From the point of view of a script the type of
document is decided by the browser's interpretation of the document, not
its author of the document.

So upon receiving a document that asserts that it is HTML (with its
headers) and can be interpreted as HTML (although littered with apparent
mistakes and syntax errors that need fixing) the browser, not
unreasonably, treats it as an HTML document and builds an HTML DOM from
it.
I can't find it in the XHTML 1.0 spec. Is it in the 1.1
spec?
From the scripting point of view the pertinent specification is the W3C
HTML DOM specification. It defines numerous interfaces that may be
implemented in hypertext document object models and notes the ways in
which XHTML implementations should differ from HTML implementations
(mostly concerning the handling of namespaces and case sensitivity).

However, the Mozilla XHTML DOM implementation does not include all of
the interfaces defined in the W3C HTML DOM specification. Specifically
they have decided to omit the HTMLDocument interface, and that means
there are no document level "convenience" properties (forms, plugins,
etc) and no write or writeln methods. Opera's XHTML DOM implementation
does include the HTMLDocument interface on the document object, it just
doesn't provide any means of running an imported or inline script (event
handlers only).

So it is not a matter that XHTML DOMs are not allowed a write method, it
is just that the most common scriptable XHTML DOM implementation does
not support it (a purely practical consideration).
Is that why it works in my test case?
If you send the document with text/html headers the only person who
thinks it is XHTML is its author, every other part of the system thinks
it is (erroneous) HTML.
Its confusing to me that
a markup language spec would have anything to say
about objects exposed by a scripting engine.
They don't.

<snip> Test case for using "document.write" in XHTML 1.0:

* The XHTML file:

<?xml version="1.0" encoding="UTF-8"?> <snip><script type='text/javascript' src='xhtml_docwrite.js'></script> <snip> * The Javascript file:

function sayHi()
{
document.write("<h1>Hello World!</h1>");
}

If I put the page on a server that sends application/xhtml+xml headers
with it (as per XHTML specs) Mozilla 1.7rc1 interprets the page as
XHTML, builds an XHTML DOM for it, and errors with:-

Error: uncaught exception:
[Exception... "Object cannot be created in this context"
code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)"
location: " [...] /xhtml_docwrite.js Line: 3"]

(error messages vary slightly on earlier Mozilla versions but no
Mozilla/Gecko XHTML DOM will execute a document.write call.)

Scripting Appendix C XHTML 1.0 served as text/html as if it was HTML
(because for all practical purposes it is) will work apparently reliably
at present. I don't think it is a good idea to do so because there is
always a chance that a browser might see "<?xml ... >" at the start of a
page and decide to override the content type header in its favour,
leaving a document that might result in either an XHTML DOM or an HTML
DOM[1], and because logic alone suggests that if you want to script an
HTML DOM you should create an HTML document. I also cannot see it as a
good idea to be sending out a document for which you know the receiving
browser is going to have to put a lot of extra work into
error-correcting.

I suspect that any confidence gained from apparent success scripting
Appendix C (text/html) XHTML 1.0 will be very rudely shattered if it
ever becomes practical to use real XHTML on the Internet.

Richard.

[1] I have read a report on Usenet of a browser that did this, but it
was not a scriptable browser so its decision will not impact in this
context. It does serve to demonstrate the risk exists (assuming that the
report was accurate, it was Usenet after all).

[Mike Foster]

Richard Cornford said:

The illusion that it works is brought about by writhing to XHTML 1.0
_Appendix_C_ and serving the pages as text/html. But Appendix C defines
a strategy for creating XHTML files that can be interpreted as (or, more
realistically, error-corrected into) HTML, and content type herders of
text/html tell the browser that what it is getting is HTML, so it
interprets it as such. From the point of view of a script the type of
document is decided by the browser's interpretation of the document, not
its author of the document.

So upon receiving a document that asserts that it is HTML (with its
headers) and can be interpreted as HTML (although littered with apparent
mistakes and syntax errors that need fixing) the browser, not
unreasonably, treats it as an HTML document and builds an HTML DOM from
it.
...
I had read appendix C before, but that part didn't make sense - it does now.
I'll be going back to using an HTML 4.01 doctype.

Richard Cornford said: ...
So it is not a matter that XHTML DOMs are not allowed a write method, it
is just that the most common scriptable XHTML DOM implementation does
not support it (a purely practical consideration).
...

I see :-)

Great explanations Richard. Thanks!

[Nick]

Mike,
Sorry for the loooong delay in the response. Thank you very much!!

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

Mike Foster wrote:

I can't find it in the XHTML 1.0 spec. Is it in the 1.1 spec?
From the scripting point of view the pertinent specification is the W3C
HTML DOM specification. It defines numerous interfaces that may be
implemented in hypertext document object models and notes the ways in
which XHTML implementations should differ from HTML implementations
(mostly concerning the handling of namespaces and case sensitivity).

As its Abstract says, the W3C DOM Level 2 HTML Specification is for
HTML 4.01 and XHTML 1.0 documents only.
However, the Mozilla XHTML DOM implementation does not include all of
the interfaces defined in the W3C HTML DOM specification. Specifically
they have decided to omit the HTMLDocument interface, and that means
there are no document level "convenience" properties (forms, plugins,
etc)
The two properties you mentioned *are* provided by the Gecko DOM.
Yes, with application/xhtml+xml.
and no write or writeln methods.

Those methods are provided as well, yet I am to see them to have an
effect different from an exception in the JavaScript console.
PointedEars

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote:

Mike Foster wrote:

I can't find it in the XHTML 1.0 spec. Is it in the 1.1 spec?

From the scripting point of view the pertinent specification is the
W3C HTML DOM specification. It defines numerous interfaces that may
be implemented in hypertext document object models and notes the
ways in which XHTML implementations should differ from HTML
implementations (mostly concerning the handling of namespaces and
case sensitivity).

As its Abstract says, the W3C DOM Level 2 HTML Specification is for
HTML 4.01 and XHTML 1.0 documents only.

It does not say 'only'.

However, the Mozilla XHTML DOM implementation does not include all of
the interfaces defined in the W3C HTML DOM specification.
Specifically they have decided to omit the HTMLDocument interface,
and that means there are no document level "convenience" properties
(forms, plugins, etc)

The two properties you mentioned *are* provided by the Gecko DOM.
Yes, with application/xhtml+xml.

Yes, they appear to have been added between versions 1.3 and 1.4. Along
with an almost complete implementation of the HTMLDocument interface on
the - document - object. Chronologically, that would have been shortly
after we last discussed this subject in detail. It is certainly a move
in the right direction as it means that the nonsense of accessing forms
with - getElemetnById - in XHTML DOMs can be totally dismissed in favour
of the specified collections. And a lot more code can be viably written
for HTML documents with the anticipation that it will also work with
XHTML documents (namespace handling and case sensitivity considerations
still stand).

and no write or writeln methods.

Those methods are provided as well, yet I am to see them to have an
effect different from an exception in the JavaScript console.

Looking at the Mozilla 1.4+ HTMLDocument interface I don't think
implementing those methods was a good idea at all. The specification
says "No Exceptions" and they are throwing exceptions. It would be
better for them to be omitted entirely if they are not going to function
as that could easily be noticed through feature detection, while the
current set-up requires try-catch. On the other hand there isn't a good
reason not to be using try-catch in an XHTML document served as
application/xhtml+xml because that type of document will be unknown to
any browser implementing a pre-ECMA 262 3rd edition script engine.

Richard.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote:

Mike Foster wrote:
I can't find it in the XHTML 1.0 spec. Is it in the 1.1 spec?

From the scripting point of view the pertinent specification is
the W3C HTML DOM specification. It defines numerous interfaces
that may be implemented in hypertext document object models and
notes the ways in which XHTML implementations should differ from
HTML implementations (mostly concerning the handling of
namespaces and case sensitivity).

As its Abstract says, the W3C DOM Level 2 HTML Specification is for ^^^^ HTML 4.01 and XHTML 1.0 documents only.

It does not say 'only'.

IBTD:

,-<http://www.w3.org/TR/DOM-Level-2-HTML/>
|
| [...]
| Abstract
|
| This specification defines the Document Object Model Level 2 HTML,
| a platform- and language-neutral interface that allows programs and
| scripts to dynamically access and update the content and structure
| of [HTML 4.01] and [XHTML 1.0] documents. [...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This reads as "for HTML 4.01 and XHTML 1.0 documents only" to me.
If they would have intended to support other document types, they
would have either mentioned them explicitely or would have used a
more general wording.
PointedEars

[Jim Ley]

On Sun, 27 Jun 2004 15:21:32 +0200, Thomas 'PointedEars' Lahn
<Po*********@nurfuerspam.de> wrote:

This reads as "for HTML 4.01 and XHTML 1.0 documents only" to me.
If they would have intended to support other document types, they
would have either mentioned them explicitely or would have used a
more general wording.

They did, in the more normative parts than the abstract, such as 1.1

| This section extends the DOM Level 2 Core API [DOM Level 2 Core]
| to describe objects and methods specific to HTML documents, and
| XHTML documents.

Where HTML is described in the glossary as:

| The HyperText Markup Language (HTML) is a simple markup language
| used to create hypertext documents that are portable from one platform
| to another. HTML documents are SGML documents with generic
| semantics that are appropriate for representing information from a
| wide range of applications

If the reason was the HTML 4.01 and HTML 1.0 restriction you suggest,
why did mozilla not block the objects to other types of HTML?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Martin Honnen]

Richard Cornford wrote:

Opera's XHTML DOM implementation
does include the HTMLDocument interface on the document object, it just
doesn't provide any means of running an imported or inline script (event
handlers only).

Opera 7.50/7.51 do support the <script> element in application/xhtml+xml
meaning your script is executed with those versions.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

On Sun, 27 Jun 2004 15:21:32 +0200, Thomas 'PointedEars' Lahn
<Po*********@nurfuerspam.de> wrote:

This reads as "for HTML 4.01 and XHTML 1.0 documents only" to me.
If they would have intended to support other document types, they
would have either mentioned them explicitely or would have used a
more general wording.
They did, in the more normative parts than the abstract, such as 1.1

Nonsense. The Abstract of a specification is as normative
as the rest of it, unless explicitely specified otherwise.
| This section extends the DOM Level 2 Core API [DOM Level 2 Core]
| to describe objects and methods specific to HTML documents, and
| XHTML documents.
You do not suggest seriously that the Abstract of a specification
defines a *more* strict application than the rest of it, do you?
Where HTML is described in the glossary as: [...]
Whatever your glossary says is completely irrelevant to this particular
specification. It is clearly specified on more than one occasion which
HTML version is referred to when the term "HTML" is used there:

,-<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-1176245063>
|
| [...]
| 1.1. Introduction
|
| This section extends the DOM Level 2 Core API [DOM Level 2 Core] to
| describe objects and methods specific to HTML documents [HTML 4.01],
| and XHTML documents [XHTML 1.0].
| [...]
| The transitional or frameset DTD for HTML 4.01, or the XHTML 1.0 DTDs
| are assumed.
| [...]
| 1.3. XHTML and the HTML DOM
| [...]
| Note: The interfaces provided in this document are only for
| [HTML 4.01] and [XHTML 1.0] documents and are not guaranteed
| to work with any future version of XHTML.

However, the discussion was about what version of XHTML would be
supported, and that is clearly defined as well. It is XHTML 1.0
*only* (because subsequent versions of XHTML are modular and thus
require a modular approach for an adequate DOM).
If the reason was the HTML 4.01 and HTML 1.0 restriction you suggest,
why did mozilla not block the objects to other types of HTML?

Because mozilla.org has either failed to implement the specification
accordingly and instead implemented a partly proprietary DOM (as they
had for HTML 4.01) or there has emerged another W3C DOM Recommendation
for XHTML 1.1 and XHTML 2.0+ documents that do implement these objects
and properties and they follow but I do not know of.
PointedEars

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote: <snip>

As its Abstract says, the W3C DOM Level 2 HTML Specification is for ^^^^ HTML 4.01 and XHTML 1.0 documents only.
It does not say 'only'.

IBTD:

,-<http://www.w3.org/TR/DOM-Level-2-HTML/>
| [...]
| Abstract
|
| This specification defines the Document Object Model Level 2 HTML,
| a platform- and language-neutral interface that allows programs and
| scripts to dynamically access and update the content and structure
| of [HTML 4.01] and [XHTML 1.0] documents. [...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This reads as "for HTML 4.01 and XHTML 1.0 documents only" to me.

That is not how I read it.
If they would have intended to support other document types, they
would have either mentioned them explicitely
Would it have been practical to mention XHTML 2.0 at the time?
or would have used a more general wording.

That is general wording. Specifically; "that allows", speaks of what
should be possible without excluding alternatives.

Richard.

[Richard Cornford]

Martin Honnen wrote:

Richard Cornford wrote:

Opera's XHTML DOM implementation
does include the HTMLDocument interface on the document object, it
just doesn't provide any means of running an imported or inline
script (event handlers only).

Opera 7.50/7.51 do support the <script> element in
application/xhtml+xml meaning your script is executed with those
versions.

Excellent. Now it will be possible to find out if it's documetn.write
method works inline and, if so, how it handles outputting malformed
XHTML.

A quick test on Opera 7.50 Build 3778 has the SCRIPT element recognised
and executed, but the - document.write - call was non-effective (even
with valid XHTML mark-up), but did not actually error.

I can't say I like that outcome, it would be better to be able to know
that the write attempt was futile (or to be deprived the method
entirely).

Richard.

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@nurfuerspam.de> writes:

You do not suggest seriously that the Abstract of a specification
defines a *more* strict application than the rest of it, do you?

No. And I don't expect the abstract to be precise. It's an *abstract*.
It picks out highlights of the entire document. It is not precise enough
to be normative.

If you read the abstract as being more strict than the specification
proper, then you should not enforce the interpretation of the abstract
on the real specification. Rather, you should reread the abstract in
the light of the rest.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@nurfuerspam.de> writes:

You do not suggest seriously that the Abstract of a specification
defines a *more* strict application than the rest of it, do you?
No. And I don't expect the abstract to be precise.

But it *is*, much *more* precise than required for such a section.
[...]
If you read the abstract as being more strict than the specification
proper, then you should not enforce the interpretation of the abstract
on the real specification. Rather, you should reread the abstract in
the light of the rest.

You have not read the Abstract or section 1.1 and following
ones or any other of my postings thoroughly, have you?
EOD

PointedEars

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote:
As its Abstract says, the W3C DOM Level 2 HTML Specification is
for HTML 4.01 and XHTML 1.0 documents only.

It does not say 'only'.

IBTD:

,-<http://www.w3.org/TR/DOM-Level-2-HTML/>
| [...]
| Abstract
|
| This specification defines the Document Object Model Level 2 HTML,
| a platform- and language-neutral interface that allows programs
| and scripts to dynamically access and update the content and
| structure of [HTML 4.01] and [XHTML 1.0] documents. [...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This reads as "for HTML 4.01 and XHTML 1.0 documents only" to me.

That is not how I read it.

As you have mentioned on several occasions here to have problems
with writing, you may have problems with semantic reading as well.
(No offense meant!) See below.

If they would have intended to support other document types, they
would have either mentioned them explicitely

Would it have been practical to mention XHTML 2.0 at the time?

It would not have been possible then and it is not possible to date.
XHTML 2.0 is still but a *Working Draft* and thus it "should in no
way be considered stable, and should not be normatively referenced
for any purposes whatsoever." [1] (see "Status of This Document")

The most recent version of the W3C DOM Level 2 Specification is a
Recommendation dated January 9, 2003. It is the only Recommendation
of it published to date.[2] The first XHTML 1.0 Recommendation is
dated January 26, 2000, and its *update*, the most recent one, is
dated August 1, 2002.[3] The most recent (and currently only)
XHTML 1.1 Recommendation is dated May 31, 2001 [4].

The W3C had pretty much time and the opportunity to update DOM Level 2
HTML to mention either of the XHTML 1.1+ versions but, for reasons
obvious to me (as I have also pointed out in my other posting), they
have not.

[1] <http://www.w3.org/TR/xhtml2/>
[2] <http://www.w3.org/TR/DOM-Level-2-HTML/>
[3] <http://www.w3.org/TR/xhtml1/>
[4] <http://www.w3.org/TR/xhtml11/>

or would have used a more general wording.

That is general wording. Specifically; "that allows", speaks of what
should be possible without excluding alternatives.

No, it is not and it does not. Pay attention to context! The sentence
reads "... allows programs and scripts to dynamically access and update
the content and structure of [HTML 4.01] and [XHTML 1.0] documents."
The specified versions are the objects of this sentence which clearly
limits the applications of the specification to these two versions of
markup languages.

Since we are getting more and more off topic, the W3C mailing lists
or private e-mail appear to be the appropriate place to discuss this
any further, if still necessary (which I do hope it is not).
PointedEars

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote: <snip>

This reads as "for HTML 4.01 and XHTML 1.0 documents only" to me.
That is not how I read it.

As you have mentioned on several occasions here to have problems
with writing,

I have not. I have only stated that I am dyslexic and as a consequence
have problems with spelling. Those problems follow from the fact that my
language perception is primarily auditory and phonetic rather than being
symbolic, combined with English's non-phonetic spelling rules (and
really poor English teaching in British schools from the late 60's
onwards).
you may have problems with semantic reading as well.
(No offense meant!) See below.

And you have occasionally mentioned that English is not your native
language, so you may not be in the best position to judge its semantics
(or nuances).

<snip>

or would have used a more general wording.

That is general wording. Specifically; "that allows", speaks of what
should be possible without excluding alternatives.

No, it is not and it does not. Pay attention to context! The
sentence reads "... allows programs and scripts to dynamically access
and update the content and structure of [HTML 4.01] and [XHTML 1.0]
documents." The specified versions are the objects of this sentence
which clearly limits the applications of the specification to these
two versions of markup languages.

<snip>

That sentence does not limit or exclude ("clearly" or otherwise). It
only states what should be possible.

Richard.