Thomas said:
The practical aspects of the situation do not diminish the worth of
Matt's comment. The HTML as proposed demonstrates a serious flaw in the
design of the NOSCRIPT element. And your browser that does not support
javascript but does understand and execute scripts is IE, with the
JScritp dll removed from the system and the VBScritp dll (or an
alternative) still available. maybe not a common configuration but a
possible one.
The example attempts to prove the inadequacy of the
`noscript' element,
It does no such thing. That example is straight from the HTML spec. It
attempts to illustrate the use of the NOSCRIPT element (and since it is
from the spec it is theoretically the correct use of the NOSCRIPT
element that it attempts to illustrate).
but, due to its design, it fails to do that.
It certainly does fail, but it reveals a design flaw in the NOSCRIPT
element.
The example is bogus since, as you correctly stated,
it is highly improbable that such a script element
using text/tcl or another non-JavaScript/JScript/ECMAScript
(in the following: JS) client-side scripting language will
be contained in an (X)HTML document;
The W3C have never mandated that ECMAScript is to be the only scripting
language to be supported in Internet UAs. If they did there would be no
point in having TYPE attributes on SCRIPT elements, or specifying a
default language for intrinsic events. From their point of view it makes
perfect sense to produce examples that use various scripting languages.
It is just a pity that they seem to have overlooked the consequences of
this policy then it comes to NOSCRIPT elements.
Thus, so far the `noscript' element has only been proven
to be inadequate when used with another script language
than the default scripting language -- dare I say JS?
-- of the used UA.
No, it has been pointed out that NOSCRIPT elements contribute nothing
when scripting is enabled but the browser's environment does not support
the features required by the script. It is that consideration that has
the real practical implications.
<snip>
| <script type="text/javascript">
| <!--
| if ((parent.frames.length == 0) || OP) {
| document.write(
| "<h2>STARFLEET PERSONNEL FILE<\/h2>",
| "<h3>DATA<\/h3>"
| );
| } else if(parent.frames.ufpdb_banner)
| parent.frames.ufpdb_banner.RotateUFPLogo(true);
| //-->
| </script>
| <noscript>
| <h2>STARFLEET PERSONNEL FILE</h2>
| <h3>DATA</h3>
| </noscript>
Runtime Error: "parent.frames is not an object" Line 24.
The script errors-out so the document.write is never executed and
because scripting is enabled the NOSCRIPT element is never used.
That does not qualify as a satisfactory outcome by your own standards.
And, yes there are scriptable browsers that do not support frames, and
so have no reason to implement a - frames - collection (indeed, not
implementing that object is a good suggestion to the script author that
the browser does not support frames).
And so, as I have been saying all along, when scripting is supported but
the browser does not support the features required by the scrip the
NOSCRIPT element is not sufficient to address the problems and instead
it is necessary do carry out proper feature detection and design for
clean degradation.
Not using the `noscript' element would have resulted
in including duplicate headings.
In what sense are the two sets of H2 and H3 elements (plus whatever
would have been in the other frame) not duplicate headings?
Not anything and not always. This absolutism is the core
flaw of your argument.
(Pot - Kettle)
I have asked for examples of non-trivial scripts that demonstrate value
in the NOSCRIPT element. They are not forthcoming. And your example was
pretty trivial in attempting nothing more than document.write, yet it
still stuffed up and made my point for me instead.
What I saw was an illustration of the point I was making.
Richard.
