The usefulness - or not - of XHTML and XHTML validation

[Robin Richmond]

The purpose of this particular post is to argue that is not useful to run the XHTML validation to assure compliance with XHTML's idiosyncratic syntax, although that running the validator is often useful for finding mismatched tags, nesting errors, misspelled tags and attributes that would be errors in any version of HTML.

I will follow-up with messages about the HTML doctype and ways that TNG already does not conform to the XHTML standard.)

FWIW, I used to teach college classes on HTML and web development, and in XHTML's heyday, I taught students to use XHTML's syntax and how to take advantage of XML. And, in the first couple of XHTML assignments, I required them to turn in validator output. But you can be sure that, in the early days of XHTML, I also taught them about HTML4 because I knew that most pages they saw would use HTML4, and later, I taught them some HTML5 because it was so damn useful. Of course, the first couple of validator assignments assured that they would use that idiosyncratic syntax correctly, but, maybe about mid-semester, I would note that the idiosyncratic syntax was not important and that the most meaningful use of the validator was to find errors that were not specific to XHML.

Notably, since most HTML code in TNG pages is generated by PHP code, and non-XHTML-specific errors are often the result of PHP logic errors,  validators (of any version of HTML) are very useful as a PHP debugging tool.

XHTML validation in TNG

I do not think that the TNGv14 display glitch that prompted Darrin to declare that TNG sites needed to use the XTML doctype was the result of a validation error. Rather, it seems to be the result an unknown interaction between the Doctype and style cascading in some browsers. If it had been caused by a Doctype compliance error, I have to think that the error would have been flagged by the validator and a straightforward fix would have been publish.

Actually, I cannot recall any other situation where the Doctype made a meaningful difference in the behavior of a web page. Of course, there are other cases, and I'm sure that I've seen them in the past, but I seriously doubt that I've seen any during the 9 years that I've insisted on using the HTML5 doctype in TNG.

Simply put, validation does not imply correctness, nor do validation error imply that a page will not work perfectly.  After all, no matter what a web page declares its Doctype to be, all widely used web browsers have to handle variations such as one-sided tags that do and don't self-close, and new form field types such as email, number and date.  And I just can't accept the notion of removing features that XHTML doesn't like but are both newer and distinctly useful.

In summary, my view is that
Yes, using a validator to find misspelled, mismatched, and "mis-nested" tags is a very useful debugging technique, but
No, using a validator simply to be able to say "This page passed validation" is not useful. 

- Robin

[Robin Richmond]

Moving on from the XHTML Doctype
As I noted in the posting above, the Doctype doesn't barely makes a difference in whether or how a page works.  And I've said many times that Darrin's devotion to the principle "If ain't broke, don't fix it" has served us well. But I don't think that the "If it ain't broke..." principle applies to the XHTML Doctupe any more. After all,

• XHTML was superseded by the HTML5 standard in 2008!
• A tremendous number of important HTML features are not accepted by XHTML validation, and are, frankly, underutilized in TNG.  I hate that thought that HTML5 form tags and semantic markup have been held back by the use of the XHTML Doctype.
• I really can't think of any benefit of specifying the XHTMNL doctype other than that it fixes one display glitch,
• Since numerous TNG sites been using it for years, we already know it that the HTML5 Doctype works in TNG!
• Thus, we could move to it with minimal testing, and finally
• TNG isn't XHTML-compliant in the first place. (I'll cover that point in a separate posting)

What would come next

As far as I can tell, switching to <!Doctype html5> wouldn't force any code changes, but just specifying that Doctype would be a meaningful statement about TNG's technology.  The new HTML5 Doctype should at least encourage more use of modern HTML tags and attributes. And when we do run the W3c validator for debugging purposes, I'd certainly prefer to

• See and toward the elimination of) errors such as ""The type attribute is unnecessary for Javascript resources", "The border attribute on the table element is obsolete", and "Trailing slash on void elements has no effect" rather than
• See and refuse to eliminate errors such as "required attribute type not specified" (on <script> tags), and "end tag for 'link' omitted, but OMITTAG NO was specified" and "there is no attribute 'placeholder'"

Going forward, it would be great to work toward removing many of the syntactic elements that HTML5 doesn't like, such as element-closing slashes, <script> mime types, and tag attributes (especially on <table>) that have been superseded by CSS attributes. (Of course, edits of this type can be thought of as violating "If it ain't

It is also important to be sensitive to the "If it ain't broke principle",  the question of whether all such changes should be tested, and the potential hassle of updating mods. Of course, the practical effects could be mitigated by not changing all files in a single TNG upgrade.

On the other hand,  multiple-file search-and-replace operations or a PHP script could easily make most of the necessary edits in PHP files, and a another script could edit selected %target files in mods and update mod version numbers in the process!

- Robin

[Robin Richmond]

Again, FYI - Some aspects of TNG that do not comply with XHMTL

(I am not trying to be critical with this admittedly picky (albeit incomplete) list. I'm just illustrating the notion that TNG isn't really XHMTL-compliant in the first place.)

1. The Doctype system variable defined in the full TNG release omits "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
2. adminlib.php is hard-coded to generate that not-quite-correct Doctype when the Doctype system variable is empty, but genlib.php specifies <!DOCTYPE html>
3. It doesn't place Javascript code in HTML comments.
4. It doesn't close all one-sided tags or define all required tag attributes
5. It generates some mixed-case tag attributes like onChange

Notably, the validator doesn't flag all of these conditions. On the other hand, we could be more proactive about fixing nesting errors that both the XHTML and HTML5 validators do report.

- Robin

[Robin Richmond]

Just FYI, here are a few aspects of HTML that may not comply with the specified Doctype but that web browsers must support no matter what he Doctype is. 

1. One-sided tags that do and don't self-close,
2. Uppercase, lowercase, and mixed case tags and tag arguments,
3. So-called HTML5  form field type such as email, number, telephone, url, and date,
4. So-called semantic block elements such as <header>, <nav>, <article>, and <footer>,
5. Deprecated tags such as <basefont>, <big>, <b>, <frame>, and <font>,
6. Anchors defined by the deprecated <a> tag name as well and those defined by id attributes,
7. Tag attributes such as selected and checked with and without values,
8. <script> and <style> elements that are placed anywhere on the web page, not just in the header,
9. <script> and <style> tags with or without mime types,
10. Non-standard tag attributes such as those required by JQuery and other libraries - even Javascript code that I've put in mods.
11. The presence or absence of <thead> and <tbody> elements, 
12. and many more

- Robin

[RickM]

Just caught up with this @Robin Richmond

A Damned fantastic read and explanation (as per your usual standard) <Smile>

Most of my own personal Mods have removed almost all of the obsolete attributes etc and I don't seem to have any issues.. It would indeed be an arduous task to get TNG up to HTML5 / CSS3 standards, but as you say half a dozen files per update, major or minor, would not be that difficult to keep up with. Even for those Mod Devs who have quite a few Mods to maintain.

Utilising modern standards may mean that Browsers may at some point deprecate some of the 'required' aspects of HTML you mention above, thus continuously improving the end user experience. It would also make styling changes a little easier IMHO.

I for one would be keen to see TNG updated in this respect, and I would be happy to lend a hand doing some of the heavy lifting.