Before you type your doc, know your Doctype!
When it comes to web standards, valid code, there is no source which holds more authority and credibility than the World Wide Web Consortium. When it comes to deciding whether your own html or xhtml source code will be valid at the end of your project, it is imperative that you begin with the proper <!DOCTYPE> and then follow the rules of valid markup under that <!DOCTYPE>. I offer a link to what I consider to be the quintessential resource for <!DOCTYPE> definitions. Along with several different document type definitions, the W3C also offers a singular template which, if you use it to begin your own document, follow the rules of the doctype embedded within that template, you will have no worries when it comes time to validate. The resource is located here, at the World Wide Web Consortium: http://www.w3.org/QA/2002/04/valid-dtd-list.html
the image is one of many different w3c logos you which appear on those web sites which claim to have validated their source code
A Note on HTML Forms and Tables 2
A commonly misused combination of HTML elements is the <table> and <form> combination. When we present forms to our visitors, we want them to be structured in a neat, orderly manner– so the user can easily understand the intended or natural progression of the questionnaire, interview, or whatever might be the topic of the form fields. This is precisely the reason i make my cheat sheets for these little easy-to-forget rules of thumb.
One of my favourite on-line references for such HTML rules is the Web Design Group at http://htmlhelp.com . Taken from the larger F.A.Q. on HTML Web Authoring, i’ve borrowed this snippet as a quick-reference on how to properly combine forms and tables as a means to the end of authoring valid XHTML.
According to the Web Design Group:
Small forms are sometimes placed within a
TD element within a table.
This can be a useful for positioning a form relative to other content, but
it doesn’t help position the form-related elements relative to each other.
To position form-related elements relative to each other, the entire
table must be within the form.
You cannot start a form in one TH or
TD element and end in another.
You cannot place the form within the table without placing it inside a
TH or TD
You can put the table inside the form, and then use the table to position
SELECT, and other form-related elements, as
shown in the following example.
<form action="[URL]"> <table border="0"> <tr> <th scope="row"> <label for="account">Account:</label> </th> <td> <input type="text" name="account" id="account"> </td> </tr> <tr> <th scope="row"> <label for="password">Password:</label> </th> <td> <input type="password" name="password" id="password"> </td> </tr> <tr> <td> </td> <td><input type="submit" name="Log On"></td> </tr> </table> </form>
If you use forms and tables a lot in your own code, please feel free to bookmark this page as your own quick reference cheat sheet. I hope it’s proved helpful.
(a.k.a.: x-html; x html; XHTML) XHTML is HTML trying to fit into XML shoes. HTML, XML, and XHTML are all Markup Languages derived from SGML. XHTML itself is developed to be generally accepted an an extensible markup language, like XML, however it retains the HTML specifc markup language elements which by default limits the true extensibility of XHTML. In order for it to be parsed as an extensible markup, certain familiar HTML elements are transformed to adopt extensible markup rules. Still essentially identical in every one the standard element tags, from the familiar block-text tag <p> to its modified closed <img /> tag, XHTML more closely resembles HTML than it does XML.
the Very-quick Reference:
a few things to remember
the Chicken or the Egg: Regarding Valid Markup for HTML Forms and Tables
The FORM, once begun, must NOT be broken in any way by a TABLE element– except when the TABLE itself is contained inside of the form, where appropriate for the purpose of a structured layout of that FORM’s INPUT elements. In this case, the table must be opened AND closed within a singular FORM. The TABLE must open AFTER the FORM begins, it will contain INPUT elements of the FORM, and the TABLE will CLOSE, all before reaching the close of the FORM.
There is one exception to the dysfunctional relationship which exists between the HTML TABLE and FORM elements. Because of the inherent segregated nature of TABLE DATA CELLS (i.e. <td>), a FORM may be opened and closed within a <td> tag– where it becomes a completed form within a singular table CELL; where the FORM can safely begin, and end without fear of being broken by other element tags.
Think of the FORM as an SAT exam: The SAT (and other forms like it) are rigidly structured. You are seated at one table and as time passes, you might be issued more than one form, but you never go to a new table in the middle of that form. Once started, the forms must be finished, and you are never allowed to break, or go to another form, nor may you go back to other forms if you finish early. You most certainly may not separate the exam forms by passing them to different tables.
[okay, i admit i'm stretching it with that Analogy, but if it is helpful for remembering how to code valid markup, then maybe we can let it pass?]
Unofficial Excerpts: W3C Recommendation HTML 4.0
What follows is intended ONLY to be used as a private reference and should not be duplicated as it this author does NOT wish to misrepresent the official W3C text. This is meant to be used only as a quick reference, and absolutely nothing more. Please read the Resource citations which follow
at should the tag be?”
“Consult the W3C!” ⇒ All you need is the “Mini – T. O. C.“!
the power of the X
XHTML is an amazing thing. By simply using XHTML (which is essentially HTML meets XML), now commonplace, and nothing much more than a slight variation on the vastly-familiar HTML markup code which itself once might have been only viewable in Internet Explorer, Netscape, Firefox, Opera, and other Web Browser user agents, this extensible version of HTML can be viewed in everything from web browsers to cell-phones, i-Pods, and many other readers in between. With the goal of universal accessibility in mind, i pose the question: What’s more challenging?: To provide a complete, comprehensive guide to deprecated HTML, or to provide current resources for valid, Extensible HTML? I struggle with the issue.
HTML: Deprecated elements†
The following elements are deprecated: APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, S, STRIKE, and U.
The following elements are obsolete: LISTING, PLAINTEXT, and XMP. For all of them, authors should use the PRE element instead.
Unicode, NCR’s, & HTML Entities
As part of my on-going quest for accuracy, and valid, universal accessibility (including universal code), i discovered this handy resource for testing Unicode support in browsers. Because i’ve encountered situations in which the use of a “named” entity vs a “decimal” encoded entity, vs a “hexidecimal” encoded character references, i am cautious of which format i use when attempting to author my markup for i18n, while wishing to ensure a proper match between my declared document content-type Charset, and that of the character encoding used for saving the file (eg. ASCII, UTF-8, ISO-8859-15, etc.).
Non-standard characters, may include the (fairly common to Western charset encodings) ampersand (&), or less common “control character” codes (themselves, often not possible to recognize visually) — those characters which control cursor functions as in “carriage return” and “line feed” which, when used properly can mean significant formatting perfection, such as the difference between one or two spaces, or none at all.
†HTML 4.01 Specification
W3C Recommendation 24 December 1999
Section 10.3: HTML Forms, Web Authoring FAQ; Darin McGrew:the Web Design Group; Rev. April 26, 2007. Available at: http://htmlhelp.com/faq/html/forms.html#form-tables . Accessed: May-22, 2007