Hal Rosser wrote:
Dr John Stockton wrote:
<snip> for ( D = new Date(), k = -7 ; k++ ; D.setDate(D.get Date()+1) )
document.writel n(D.toString(). fontcolor(D.get Day()?"blue":"r ed"),
"<br>")
Some professors would beat you about the head and shoulders
for using a post-increment operator as a boolean test, and
for placing (code that should be in the body of the loop)
as the "update-Expression" in the top parens of the loop,
or for using a day number as a boolean test.
In loosely-types javascript all values have implicit trueness so it is
not at all unusual to see values that are known not to be of boolean
type in contexts where other languages would require boolean values.
That is also not undesirable as working with a loosely-typed language
places the onus on the programmer to keep track of the types of values
and appreciate the consequences and implications of any implicit
type-conversion.
This wider concept of trueness, extending beyond the Boolean type, is
evident in the language itself, where, for example, the logical AND and
OR operators do not necessarily result in boolean values, instead the
actual value of the pertinent operand is the result.
So a javascript programmer should be expected to able to see a value in
a context where it would be subject to the application of the internal
ToBoolean function and understand what the possible resulting boolean
values will be. That is just part of the discipline of writing with a
loosely typed language.
I'm beginning to see what they mean about your code. my GOD,
man! Have you no shame? hehehe ;-) You ride the rugged edge
of the language specifications (but inside the bounds ).
The terseness of John's code is if occasionally commented upon, but that
is nowhere near the 'ragged edge' of ECMAScript.
Is it no longer "fashionabl e" to try to conform (as much as
practical) to XHTML practices - like using "<br />" ?
It is a lamentable truth that the average standard of technical
understanding possessed by web developers/designers world-wide is
atrocious. If something becomes 'fashionable' the odds are good that it
did not become fashionable for sound technical reasons.
HTML and XHTML are distinct mark-up languages, and in our context of
browser scripting that distinction is manifest in these two different
mark-up languages resulting in two distinct types of DOM being exposed
to be scripted. And the differences between those two types of DOM (by
specification and in practice) are such that very few non-trivial
scripts will be capable of successfully interacting with both types of
DOM. We have the HTML DOM, with its case insensitivity, historical
shortcut features, preference for setting Element properties directly,
and so on. While the XHTML DOM is case sensitive, rarely implements more
than is explicitly specified, prefers to have Elements defined with the
setAttribute (or setAttributeNS) methods, has an interest in namespaces,
and traditionally omit some features commonly used in HTML DOMs such
as - document.write -. If a document is to be scripted it is quite
important to know which type of DOM is being scripted, and advice on
scripting one DOM is likely to get in the way when scripting the other.
The decision as to which type of DOM a browser creates is based entirely
upon the content-type header sent by the server with the document. If
the content-type is text/html then the browser will interpret the
document as HTML and build an HTML DOM. Only when a browser supports
XHTML, receives as well-formed XHTML document and receives a formally
correct XHTML mime type in the content-type header is an XHTML DOM
created, and those are also the only circumstances under which a
document really is XHTML, regardless of the appearance of its mark-up.
Because IE does not support XHTML, and cannot create an XHTML DOM, in
order for a document that had XHTML-like mark-up to be displayed in IE
it must be sent with a text/html content-type header. IE then interprets
that document as HTML and error-corrects all of the XTHML-like mark-up
back into tag soup HTML. That is, serving documents that superficially
resemble XHTML to be displayed by IE imposes an entire extra
error-correction stage on the client for the document to be interpreted
as the HTML that it would have been without the imposing the illusion of
document. With the additional irony that sending this document in this
way to a browser that does understand XHTML, like Mozilla or Opera, will
still result in its being interpreted as HTML, subject to
error-correction, and an HTML DOM being built for it.
All of this error-correction has implications for the resulting HTML DOM
as error-correction rules are not formally specified and browsers are
observed to behave differently while carrying it out, producing
structurally different HTML DOMs to be scripted.
Finally, there is the formal definition of HTML to be contended with. By
specification - <br / - is a shorthand for - <br></br> - in HTML, and
so - <br /> - is equivalent to - <br>> -; a BR element followed by a
'greater than' symbol. Fortunately for the people following this
'fashion' most browsers do not follow this particualr formal rule and
instead regard it as an error to be corrected in HTML mark-up, though
there is always a chance that there are browsers that take the HTML
specification at its word and there the result will undesirable.
So it is not a question of what may or may not be fashionable. The
technically informed will write HTML mark-up when they want to serve a
document as text/html and script and HTML DOM, and XHTML mark-up when
they want to serve a document as XHTML and script an XHTML DOM. And with
IE not supporting the second option at all the former is the sensible
option when authoring in a commercial context. (The only alternative
being content negotiation, but you cannot content negotiate scripts and
attempting to write scripts that will work with XHTML DOMs and HTML DOMs
is double the effort for no tangible benefits, so not a sensible option
in a commercial context.)
Richard.
