Hi Trevor,
Of course, I don't *have* to perservere. The "if it ain't broke" rule
could be applied, but that would spoil the fun of getting it right
)
A man after my own 'eart! ;-)
The difference in browsers vis a vis HTML standards, which are relatively
new, is daunting. It becomes even moreso with the addition of CSS and
JavaScript into the mix Fortunately, standards organizations like the W3C
and ECMA are providing some sanity to the mix, but new software takes time
to develop. Currently, the big software vendors are agreeing in principle to
adhere to the standards, and most browsers are more or less caught up with
the latest. However, Internet Explorer has been at version 6 for about 3
years now, and has fallen seriously behind. The good news is that IE 7 is
slated to come out within the next 6 months! As a guess, I would have to
venture that the slowness is due to its integration with Windows, and the
major overhaul that the next version of Windows (Vista) has undergone.
I'm surprised that several browser manufacturers (at least) haven't yet
thought of the idea of making a browser that is smart enough to read the
DTDs for itself, but I wouldn't be surprised to see that happen sometime in
the near future. After all, if I've thought of it, better minds than mine
must have!
The good news, as far as you're concerned, is that validators are not "The
Internet Police." Don't get me wrong; validators are extremely useful tools
for double-checking your code. But standards are not requirements. Let me
explain.
The chief purpose of standards is to remedy the problem of
cross-platform-compatibility with regards to client applications that work
with data such as web pages, database data, email, newsgroups, and all kinds
of other data that may be exchanged over the Internet. Standards at an
"above-protocol" level are, as I mentioned, relatively new. As an example,
I'll discuss HTML and browsers a bit. As you know, the greatest problem with
HTML today is getting it to look and behave the same in all browsers.
Standards are an effort to provide a voluntarily-followed set of known HTML
document structure, JavaScript language and structure, Style Sheet language
and structure, and so on, which browser vendors can adhere to, and thus
present users with information that is easier to use, as it looks and
behaves more or less the same in whatever software one chooses to have and
use.
JavaScript is a particularly problematic aspect of all this. HTML, as you
recall, was originally developed as a markup language for documents.
JavaScript (together with HTML and CSS) is used to create a user interface
out of an HTML document, and a user interface is quite a different animal
than a document. For one thing, it is interactive. It changes in its
appearance and behavior. The HTML DOM (Document Object Model) has had to
undergo some serious tranformations to accomodate this interactivity, with
the enhancements of, for example, properties and events being added to the
various types of elements, so that the "document" (or, perhaps more
accurately, "user interface") can react to different types of user
interaction. The standards organizations have been slow to upgrade the DOM
and the JavaScript standard, for whatever reasons, and browsers, though most
of them support almost the entire existing DOM, have had to implement
non-standard DOM extensions of their own to satisfy the demand. The vendors
have agreed between themselves to certain of these extensions, but
identifying them, and accomodating the differences between browsers, is
still a monumental effort.
XHML is an attempt to solve a slightly different aspect of this problem,
that being extensibility. As HTML was/is not easily extensible, and has
evolved, the rules for HTML have become increasingly complex and therefore
hard to understand and for developers to work with. XHTML is by nature
easily extensible, as XML is self-describing (via DTDs (Document Type
Definitions), XSD (eXtensible Schema Definition), and so on. And it will no
doubt supplant HTML - eventually.
This does not restrict sfotware vendors from coming up with their own
extensions, proprietary enhancements, etc. It simply provides a core set of
standards which enable a developer to adhere to for cross-platform
compatibility. This is an extremely important point.
Now back to the validators. What this leaves is a set of core standards
which software vendors are working to adhere to, but have yet to do so
completely, and a variant set of proprietary extensions that exist on
different browsers for different proprietary purposes. Internet Explorer,
for example, MUST support certain OS user interface interaction that is not
related to HTML or web sites. As long as these proprietary enhancements do
not overrule the standards, it will be entirely possible for developers to
breathe a sigh of relief, and develop web pages and web application
interfaces with much less difficulty.
What the validators are designed for, then, is a way of checking what *is*
standardized, and informing developers of any inconsistencies with the
standards that exist in their work. This makes the development process much
easier, and enables the developer to be more productive. In other words,
validators are tools that simplify and streamline the development process.
They warn the developer of areas that may need attention, things in their
code that *may* cause issues on different browsers.
In many cases, these are not issues at all. For example, there is an
"element" object in the DOM. It represents all document elements (tags that
are delimited with <less than/greater than> characters). These tags
represent objects in the DOM. There is not, however, an existing method in
the standard DOM for scrolling a scrollable window or scrolling element to
the position of any given element. There are, however, a couple of methods
in almost all browser implementations for doing this. The most common one is
the "scrollTo()" method of the element object. It can be safely used in any
HTML document without fear of any major browser not supporting it. But it
will not validate, as it is not yet part of the W3C Document Object Mode.
So, if you were validating an HTML page which contained this particular
code, it would tell you that there was a violation in the page. Would this
mean that you should not use this in the page? Certainly not. If you needed
such functionality, there is no standard that provides it as of yet.
In other words, validators are not Internet "Meter Maids" that will give you
a ticket if you don't meet all the standards. They are there for the
*convenience* of developers. They are *not* a substitute (yet) for knowing
what is supported in which browsers. They do not even (yet) serve as
guidlines regarding any "Best Practices," except where there are standards
that exist and are more or less universally supported.
This is important to keep in mind, as it is not well understood, and the use
of these validators has derailed many a well-meaning but uneducated
developer and/or client from completing a task or project.
Of course, this makes things very difficult at present for developers like
you and me, to make sense of the output of these validators. One cannot
simply look at a warning message and say "I need to fix this," or "the right
thing to do here is to do this." Instead, if one wants to "get it right,"
one must often do some serious and difficult research. This is particularly
true in the case of DHTML (JavaScript combined with CSS and HTML). Finding
the correct information regarding what JavaScript is supported by what
browsers is difficult, to say the least.
I tend to stick to making it work in FireFox, and IE6, which covers most
existing browsers. The FireFox JavaScript documentation is pretty bad,
though. Fortunately, FireFox comes with tools for inspecting the DOM of any
HTML document loaded, both as HTML, and with regards to JavaScript
scripting. And the Microsoft MSDN library has an excellent section of DHTML,
which includes not only the Microsoft object model, but identifies whether
or not certain things are standardized. So, when deciding on what objects,
properties, and methods to use, a look into the Microsoft reference provides
a suggested solution, and a look at the DOM in FireFox either confirms or
denies that such an object, property, or method will be supported in most
othe browsers.
In addition, FireFox has a JavaScript console, which provides some basic
information about JavaScript exceptions thrown, and more importantly,
Internet Explorer comes with JavaScript debugging capabilities.
Okay, now to your specific questions. I cannot give you an authoritative
answer without testing myself, which I don't have the time to do, but
hopefully I can provide some guidance.
<![if !IE]>..............<![endif]>
This is a conditional comment. Conditional comments are only recognized by
IE 5 and IE 6, and not by any other browser. This serves as a hack for
JavaScript detection, in that anything inside it will be ignored by any
other browser than IE, and therefore, will only be executed *by* IE. You can
read more about Conditional Comments, and their use in hacking IE, at:
http://www.quirksmode.org/css/condcom.html
NOTE: IE 7 is a valiant attempt by Microsoft to adhere to all existing
standards. It will fall *slightly* short of the mark, due, according to
Microsoft, to time constraints. However, conditional comments, which are not
part of any standard, will no longer be supported. Something to keep in
mind, as there is already quite a hubbub of activity out there to prepare
existing hacked web pages for the new version of IE.
Error Line 68, column 85: document type does not allow element "body" here
I suspect this is because you're referencing the Frameset DTD in your page,
rather than either the Strict or Transitional DTDs (there are three
different ones for differing purposes). The Frameset DTD is for Framesets,
and the page in question is not a frameset. It is simply an XHTML document.
The fact that it is, in this case, loaded *into* a frameset, is irrelevant.
The frameset is the document containing the frame definitions, and a
frameset can load any web document into these frames.
Still, as I say, plenty to read and avenues to explore. I'll start by
changing the DTD to Transitional and then maybe start with a very much cut
down page - just <head> and a blank <body> and see what happens
An excellent idea, and one that I often use myself, when better methods are
not available, for debugging purposes of all kinds. Strip away as much as
possible, and begin adding it back in by degrees until an exception occurs.
Deal with each exception piecemeal in this way. Rather than trying to
swallow the whole elephant, bit off a chunk at a time to avoid indigestion!
;-)
You may also benefit from the following link. DTDs are written to be
concise, not easily read (at least by human beings!). They define shorthand
terms and names, and then refer to these shorthand terms and names
throughout the document. While this is certainly as concise as possible, it
makes for very difficult reading. The following link is a "crash course" on
reading DTDs:
http://www.autisticcuckoo.net/archive.php?id=2005/05/01/art-of-reading-dtd
Good luck, my friend!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Complex things are made up of
Lots of simple things.
Trevor L. said:
Kevin,
Fantastic and lots to read and explore.
I didn't think my main page was so heavily loaded with lots of extras, but
I guess it is - it has grown like topsy.
I didn't think I had any browser detection. My detect() function is to
redirect to the root page if a visitor enters directly.
Of course I do have the code
<!--[if gte IE 4]>...........<![endif]-->
and
<![if !IE]>..............<![endif]>
which a different type of browser detection - not JS but conditional
comments.
Is this code unique to MS, in particular IE?
If so, I may have to ditch it or revert to some type of browser detection
in JS.
I assume XHTML objects to the conditional comments and also to <embed>.
I'll have to find a way around the <embed> problem - I thought this was
fairly common usage for adding sound and video (and also Flash - not that
I have the Flash editor to create anything with).
The point that I would like to crack first is why does the validator say:
Error Line 68, column 85: document type does not allow element "body" here
Still, as I say, plenty to read and avenues to explore. I'll start by
changing the DTD to Transitional and then maybe start with a very much cut
down page - just <head> and a blank <body> and see what happens
Of course, I don't *have* to perservere. The "if it ain't broke" rule
could be applied, but that would spoil the fun of getting it right
)
--
Cheers,
Trevor L.
Website:
http://tandcl.homemail.com.au
(see website to send email)
