Re: Recommendations for JavaScript drop-down menu code

Brian Adkins wrote:
On Sep 29, 10:12 pm, Peter Michaux wrote:
On Sep 29, 6:35 pm, Randy Webb wrote:
<snip>
If you don't serve it as XHTML then it isn't XHTML. And no
DTD (or any other element/tag/code in the page) will make
the browser interpret it as XHTML. Even your Firefox is
interpreting it as HTML. Serve it with a proper MIME type
and see what IE does with it.

I'd think these quotations would be justification enough.

http://www.webdevout.net/articles/beware-of-xhtml#quotes

Yes, I find those quotes signficant.

I see what Randy was trying to say in his initial post - the
subtlety was lost on me. I was ignorant of the fact that my
carefully crafted XHTML 1.0 Strict code was being handled as
as HTML. I think I figured the 'text/html' content type was
simply to placate IE and that the XHTML capable browsers would
obey the doctype.

Which means that you were also not aware that there is a distinction
between HTML DOMs and XHTML DOMs. If you are scripting a DOM absolutely
the last thing you would want is to be scripting one type of DOM in one
browser and another type in the next.

From my research today, it's clear that this is an all too
common misconception.

All too common, and such that sufferers from the misconception are
extremely resistant to being corrected.

Bad book authors :)

Yes, but not only. Bad web page authors (directly, and those writing
pages on writing web pages) are probably more guilty (by weight of
numbers) , along with the participants in small circulation web forums,
mailing lists and other web development 'communities'.

This is certainly a heavily debated topic, but I've personally
been unable to find enough evidence to justify serving XHTML
up as HTML, so unless I turn up something significant in the
next few days, I think I'll switch to HTML 4.01 Strict and
continue to code in an XHTML style. At least I feel better
informed now.

While you are judging the 'significance' of what you find consider the
consequence of scripting such a document. Since almost no non-trivial
scripts will operate successfully with both and HTML DOM and an XHTML
DOM and a document served as text/html will result in the browser
exposing an HTML DOM to be scripted, will it ever make sense to be
marking-up a document as XHTML and then scripting with the pre-requisite
that it will _never_ be interpreted as being an XHTML document by a web
browser.

There certainly seems to be a strong trend in moving to XHTML
with a 'text/html' content type,

There certainly is a strong trend towards seeing increasing quantities
of XHTML-style mark-up in documents (whether they be XHTML or not). It
is most obvious that fundamental miscomputations are driving this trend
when you observe the number of documents where <br> appears alongside
<br /> (or when you see things like <BR />).

so it appears that either a lot of major site operators are
misinformed, or I've yet to get all the relevant facts about
this.

The general standard of technical understanding, even on 'major sites',
is so low that 'misinformed' is probably pushing things too far. To be
misinformed you need to be (in some sense) 'informed' in the first
place. Plain old endemic ignorance is a much better explanation; these
people just don't know why they are doing what they are doing.

Much of the time when we get into this XHTML/HTML discussion here it
quickly obvious that the individuals being asked why they are using
XHTML-style mark-up while scripting an HTML DOM not only don't know that
there is a distinction between the types of DOM, but don't actually know
what an HTTP content-type header is. These is no informed decision
making in what they do, just the random outcome of the aggregation of an
extended sequence of 'learnt' mystical incantations.

The depth, and pervasive nature of, that endemic ignorance is best
illustrated by the current set of 'popular' javascript libraries. Where
people who don't know any better are importing the ignorance of others
into their own projects.

On Monday morning I have been asked to analyse why an 'AJAX' web
application written by one of our subsidiary companies runs so badly on
IE6 as to be non-viable. I have not seen the code yet and the only
things I know about it are that it was written by experienced Java
programmers (so I am expecting them to have made all the mistakes I made
when moving from Java to javascript) and that they have used to
'popular' dojo library. In preparation I thought it would be a good idea
to have a look at the dojo library code, so I spent a few hours
yesterday doing that, to discover (as I expected I would) that its
authors were not particularly knowledgeable about javascript or browser
scripting. To illustrate:-

From a file called "dojo.js" (re-wrapped for newsgroup posting):-

| document.write("<scr"+"ipt type='text/javascript' src='"+
| spath+
| "'></scr"+"ipt>"
| );

In the mark-up string being presented to the - document.write - method
you will see two string concatenation operations being used to
'split-up' the SCRIPT opening and closing tags. This is a mystical
incantation that ignorant script authors chant in the face of a real
issue. The real issues is that when an HTML parser encounters an opening
SCRIPT tag it must determine how much (if any) of the following material
is script code that should be sent to a script engine for processing and
when it should resume processing the input stream as HTML mark-up. The
obvious signal for the end of contents of a SCRIPT element would be the
closing SCRIPT tag. However, the HTML parser has no means of seeing the
characters in the input stream as anything other than characters so if a
javascript string contains the character sequence '</script>' the HTML
parser is going to see that as the character sequence it is interested
in; the end of the contents of the SCRIPT element. Resulting in an
unterminated string literal error in the javascript source and gibberish
text content in the HTML document.

There is also a formal issue that differs slightly form the real issue.
The HTML specification clearly states that CDATA contents of an element
(SCRIPT element contents are CDATA in HTML) may be terminated by the
first occurrence of the character sequence '</'. In practice no browsers
are known to follow this aspect of the HTML specification to the letter,
but a knowledgeable HTML author would have no excuse for complaint if a
future browser did terminate CDATA sections at the point of first
encountering the character sequence '</'.

So the things that make the above code a mystical incantation are:-

1. The string concatenation operation in the opening SCRIPT
tag is a needless runtime overhead to do something that
has no relationship to either the real issue or the formal
issue. It just should never have appeared in any code.
2. The string concatenation operation in the closing SCRIPT
element may deal with the real issue but it does not address
the formal issue. While any approach that did address the
formal issue by breaking up the '</' sequence would also
break up the '</script> sequence.
3. A concatenation operation is a poor approach to this issue
as the HTML parser is only able to see the raw source text
characters. Breaking up the problematic character sequences
with escape (backslash) characters would be just as effective
at concealing them form the HTML parser but would do so in a
way that had no consequences beyond the point where the
string literal was converted into a string primitive value
(during the compiling of the script into an executable). That
is, there is no need for the runtime overhead of two (or
four in this case) string concatenation operations. The
recommended approach is to turn the sequence '</script>' in
string literals into the sequence '<\/script>' and so address
the real and formal issues without any runtime overhead.
4. The code is actually in an external javascript resource and
so will never be presented to an HTML parser for examination.
Neither the real nor the formal issues apply to this code at
all.

Another illustration is to be found in dojo's 'dom.js:-

| if(
| elem == null ||
| ((elem == undefined)&&(typeof elem == "undefined"))
| ){
| dojo.raise("No element given to dojo.dom.setAttributeNS");
| }

Using the type-converting equality operator (- == -) there are precisely
two values that are equal to null. They are null (unsurprisingly) and
the undefined value. In the above tests whenever - elem - is null or
undefined the - elem == null - expression is true and the - ((elem ==
undefined)&&(typeof elem == "undefined")) - expression is not evaluated.
So whenever the - ((elem == undefined)&&(typeof elem == "undefined")) -
expression is evaluated the value of - elem - must be neither null nor
undefined. But if - elem - must be neither null nor undefined then -
(elem == undefined) - must always be false (as only undefined and null
equal (by type-converting equality) undefined), and as - (elem ==
undefined) - must be false the - (typeof elem == "undefined") - can
*never* be evaluated.

We are looking at code where the author has written the test
expression - elem == null - without understanding the operation being
performed and made that ignorance self-evident by following it with a
test that can only have one outcome in its context, and a third test
that can never be evaluated (though if it were evaluated the result
would be as predictably false as the - (elem == undefined) -
expression).

The annoying part of this nonsense is that in its normal use, when - elem - will be a reference to a DOM Element, that - (elem == undefined) - is going to be evaluated, and it is going to produce its predictably false result. Just another avoidable runtime overhead, included for no reason other than ignorance.

It is unlikely that dojo is the work of a single individual, but we can be certain that of everyone involved the individual with the greatest knowledge of the subject does not know javascript well enough to understand how the code written is going to behave (or enough to distinguish between chanting mystical incarnations and browser scripting). However, you find that the authors of these 'popular' libraries acquire a strange status in the eyes of (presumably even more ignorant) others, get invited to speak at conferences, feel themselves qualified to instruct others on how they should be writing javascript, and so on.

So yes we do live in a world where the operators of 'major sites' are misinformed, and likely to stay that way because the odds are that the next person to 'inform' them will likely be as misinformed themselves.

Richard.

.

Relevant Pages

  • Re: how to run scripts after a page has already loaded and been sent to a users browser?
    ... > It's because PHP is a server side scripting language, ... > do stuff before you send stuff to user's web browser. ... As we've discussed on this newsgroup before, if a script starts ... that is after the last HTML is sent to a web browser. ...
    (alt.php)
  • Re: Web Layout
    ... There is absolutely no advantage to using XHTML over HTML, and it will certainly not help in this instance. ... You need to serve valid and compliant HTML and CSS to the browser, and in 99% of cases, you will not have problems. ... It is certain that Opera and FF are correctly rendering the code, and that IE is doing its best to make sense out of invalid code. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: IE no doing "onload" function?
    ... attempted to apply the illusion of XHTML to an HTML ... created by the browser to be scripted. ... This makes it very important for script authors to be very clear about ...
    (comp.lang.javascript)
  • Re: The XHTML Factor
    ... Well, XHTML 1.0 has nothing more to offer than HTML 4.01 has, it has ... And indeed the browser with the most market share, MS Internet Explorer, ... deliberate nesting error, and the other iframe containing exactly the ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Form spam? What to do?
    ... >> now serving many new pages in true xhtml 1.1 using the correct mime ... > Your script will serve application/xhtml+xml to a browser with an Accept ... On contrast IE6 accepts the html 4.01 strict code as you can ...
    (alt.html)