Common XHTML Validation Issues
From Textbook
Contents
|
Overview
Web page validation is an important part of good Web site design. It is easy to find out if your various page locations in Textpattern validate; simply go to the World Wib Web Consortium's Markup Validation Service, load your page URL, and see if your page validates successfully or not. Because of the unique way Textpattern manages content, there are a number of validation "issues" that people frequently have, especially when trying to achieve Strict validation. Hence, this documentation tries to cover these various validation issues with Textpattern as much as possible, as well as any validation issues that come from using certain third-party plugins, with a focus on XHTML Strict validation.
Validation Problems with ASCII Characters
One of the requirements of XHTML-Strict validation is to code certain characters in ASCII syntax. Below is a list of characters and the ASCII equivalents that must be used to achieve proper validation. This list is meant as a starting point, add to it as you find necessary:
Ampersands
Ampersands (&) must be encoded as HTML entities...
&
Note this is also applies for ampersands used in URLs as well.
Validation Problems with Block Elements Using Standard XHTML Markup
Because of the way Textpattern manages content output, there is a common tendency for block elements such as divs, blockquotes, and lists to output in unexpected ways. The situation is often due to a page author trying to use stanadard XHTML syntax in the Article being drafted, and the result is published markup that will not validate correctly.
The problems are not because standard XHTML syntax is being used, but rather with how it is being used within a Textpattern Article. The following examples serve to illustrate these issues, as well as provide remedies.
Block Elements Wrapped by Paragraph Elements
This is a common problem when adding block elements to your draft Article using normal XHTML syntax. The problem is consistent across many block elements, but for simplicity we will demonstrate the problem and solution using just two, the division (div) element and a list element -- in this case, an unordered list (ul).
In both cases, the scenario could begin like this: You have two paragraphs in an article, and you want to add another block element (div, ol, ul, blockquote, etc.) between them; so essentially resulting in three block elements in normal flow (note: paragraphs are block elements).
Normal tendency is to left-align all the block elements as you draft your article in the Write tab, with a single line space between each block element. This is perfectly fine under normal circumstances, but with Textpattern, you need to do one more thing with the non-paragraph block element; you need to add a single blank whitespace before it. The following two examples demonstrate this situation. Again, remember we are talking about non-paragraph block elements that are being added directly to your article in standard XHTML syntax (not Textile syntax).
Example 1: Division Element (div)
Or first example demonstrates the problem using a division (div) block element; if you add a div element between two paragraph elements with all three elements left-aligned, as follows...
Start of first paragraph....end of paragraph. <div>...content here...</div> Start of second paragraph....end of paragraph.
...the output will appear as follows (note you can see this for yourself if you have a real example, simply click the "HTML" tab at the right of your text editing box in the Write tab)...
<p>Start of first paragraph....end of paragraph.</p> <p><div>...content here...</div></p> <p>Start of second paragraph....end of paragraph.</p>
The problem of course is the paragraph tags surrounding the division tags, which is not semantically correct, and therefore will not validate.
The solution is easy: you simply add a single blank whitespace before the first division element tag in your draft article. You can do this by hitting your space bar once, so your article draft will look like this...
Start of first paragraph....end of paragraph. <div>...content here...</div> Start of second paragraph....end of paragraph.
which will produce markup output exactly as it should be (which will validate perfectly as XHTML Strict), like this...
<p>Start of first paragraph....end of paragraph.</p> <div>...content here...</div> <p>Start of second paragraph....end of paragraph.</p>
Example 2: Blockquote Element
Here is the same scenario but this time using a blockquote element...
Start of first paragraph....end of paragraph. <blockquote>Some very profound quote here.</blockquote> Start of second paragraph....end of paragraph.
and the output will appear as follows, which will not validate because of the paragraph ("p") tags that surround the blockquote element...
<p>Start of first paragraph....end of paragraph.</p> <p><blockquote>Some very profound quote here.</blockquote></p> <p>Start of second paragraph....end of paragraph.</p>
But if you add the single space before the opening blockquote tag, like this...
Start of first paragraph....end of paragraph. <blockquote><p>Some very profound quote here.</p></blockquote> Start of second paragraph....end of paragraph.
then the resulting markup will output as follows (which will validate perfectly as XHTML strict)...
<p>Start of first paragraph....end of paragraph.</p> <blockquote><p>Some very profound quote here.</p></blockquote> <p>Start of second paragraph....end of paragraph.</p>
You can also use the Textile syntax "bq." to produce the correct blockquote automatically.
Block Elements Wrapped by Paragraph Elements and Laced with Break Elements
Cetain block elements, particularly lists that are composed of multiple types of XHTML tags, have a tendency to be laced with non-semantic break elements in addition to being wrapped in the paragraph element as described for divisions and blockquotes above. Again, this is due to the way standard XHTML syntax is used in a Textpattern Article, but dealing with it is slightly different than before.
Example 1: List Elements (Using an Unordered List)
If we created an Article with three block elements as we did before using standard XHTML markup, but this time use an unordered list (instead of a division or blockquote) we might intuitively do so like this...
Start of first paragraph....end of paragraph. <ul> <li>List item one.</li> <li>List item two.</li> <li>et cetera</li> </ul> Start of second paragraph....end of paragraph.
As before, Textpattern will add the additional paragraph tags around the non-paragraph block element, but note that is also throws in some nasty, non-semantic break tags as well when this markup is served online...
<p>Start of first paragraph....end of paragraph.</p> <p><ul><br /> <li>List item one.</li><br /> <li>List item two.</li><br /> <li>et cetera</li><br /> </ul></p> <p>Start of second paragraph....end of paragraph.</p>
The above markup will definitely not validate. However, you can get the standard XHTML markup to work in the article by again adding a needed blank whitespace, but this time you need to add a space before each of the list complex tags that start a new line; specifically, you will add a blank whitespace before the opening and closing list tag (ul), and before each of the opening list item (li) tags, like this...
Start of first paragraph....end of paragraph. <ul> <li>List item one.</li> <li>List item two.</li> <li>et cetera</li> </ul> Start of second paragraph....end of paragraph.
Note the whole list complex, from open to closing list tag, is indented in the article by a single blank whitespace. This will result in perfectly fine and valid markup as...
<p>Start of first paragraph....end of paragraph.</p> <ul> <li>List item one.</li> <li>List item two.</li> <li>et cetera</li> </ul> <p>Start of second paragraph....end of paragraph.</p>
The examples provided above explain how to manually added standard XHTML syntax to an article so the resulting markup output will validate correctly. However, there are two other methods for achieving markup that validates. One is to use the upm_quicktags plugin, and the other is to use Textile. Which one you may find to be more effective for you will depend on how comfortable you are with writing syntax. If you (or the someone else using the Textpattern site) are more comfortable with text editing tools as opposed to manual development, then the upm_quicktags plugin might be right for you. On the other hand, if you are comfortable with XHTML, or simply want to do things in the easiest, cleanest way possible, then the suggested method is Textile. Both of these approaches are discussed in the next two sections.
upm_quicktags Plugin: A Button Solution for XHTML Syntax Editing
If you do not trust yourself with writing standard XHTML syntax markup, the upm_quicktags plugn can do the job for you.
- Get the plugin from the Textpattern Resources site, right here.
- Read the documentation that comes with the plugin, and install the plugin in the Plugins tab in your site administration area.
Textile: The Easiest and Cleanest Solution for Non-paragraph Block Elements
Textile offers a much easier and cleaner way of adding block elements to your articles; not only does it eliminate the need to add blank spaces before the block element tags, it also is a lot easier to write and read. If you use Textile to add block elements, Textpattern will understand the Textile syntax slightly differently, essentailly realizing that the indicated block elements are indeed non-paragraph elements, and therefor will not wrap them in paragraph element tags or add unnecessary break elements. You are higly encouraged to learn about Textile if you have not already.
Below is another demonstration of the scenario above for the list element, but this time instead of using standard markup, we use Textile to solve our validation dilemma.
We begin by first drafting our article as follows...
Start of first paragraph....end of paragraph. * List item one. * List item two. * et cetera Start of second paragraph....end of paragraph.
The first thing you should realize is how much easier that is to write, and how much cleaner the text looks. The Textile part is simply the three asterisks that start each of the list item lines. No space is added before the asterisks, but a single space is used between them and the line content. Textile is designed to know that when this sequence of syntax is used, the following should be output (which in fact is what happens)...
<p>Start of first paragraph....end of paragraph.</p> <ul> <li>List item one.</li> <li>List item two.</li> <li>et cetera</li> </ul> <p>Start of second paragraph....end of paragraph.</p>
The Textile syntax is automatically converted to standard XHTML -- without the paragraph element wrapping problems and break tags -- and validates perfectly when tested with the W3C validator (assuming there are no other problems with the page).
Textpattern Comments Form
Can anyone help fill in the details here. --Destry 13:43, 9 Jun 2005 (GMT)
This is an important issue because Comments are a popular feature built into Textpattern itself. Comments are either enabled in Textpattern globally in the Basic_Preferences tab, or on an article-by-article basis in the Write tab. Either way, when Comments are enabled for an Article, they are output to the page as an XHTML Web form. There are a number of things that must be in place for a Web form to be XHTML Strict compliant.
The Problem
Identified problems that prevent the Comments form from validating as XHTML strict include:
- The input elements, which are single tag elements (
<input />) should always have at least the "name" attribute specified (where "text" is a name of your choosing)...<input name="text" />
- The textarea form element (
<textarea />), which defines the comment message box, should have at least the "name", "rows" and "columns" attributes specified (where "n" is a number)...<textarea name="namehere" rows="n" cols="n" />
Now this in itself is not a problem, because we could easily add these various attributes as needed if the form elements were accessible. The problem is that because Comments are built into Textpattern, we don't have access to these elements.
The Remedy
(needed)
Zem_Contact Plugin Form
Anyone want to help fill in the details here. --Destry 13:43, 9 Jun 2005 (GMT)
The Problem
(details needed)
The Remedy
(needed)
