Sunday, July 19th, 2009
I see more and more people switch over to HTML5 these days, and to help you make sure you did things correctly, there are some tools at your disposal that might be good to know about.
HTML5 validator
To make sure you didn't misspell any tag or nest elements in a way that is not allowed, or find similar mistakes in your markup, you can use Validator.nu.
Alt text for images
The above-mentioned validator has a feature to help you quality-check your alternative text for your img elements. Check the Show Image Report checkbox.
You can also disable images in your browser or try to use a text-only browser — the information that the images convey should still be available (but in text form). Sometimes an image doesn't convey any further information than what the surrounding text already says, and in such cases you should use the empty value: alt="".
For further advice and examples on how to use the alt attribute, the HTML 5 spec has lots of information on the topic. If you're not going to read it all, just read the section called General guidelines.
Document outline
The document outline is the structure of sections in the document, built from the h1-h6 elements as well as the new sectioning elements (section, article, aside, nav). The document outline is more commonly known as the Table of Contents.
To make sure that you have used the new sectioning elements correctly, you can check that the resulting outline makes sense with the HTML5 Outliner.
If you see "Untitled Section" and didn't expect them, chances are that you should have used div instead of section.
If you have a subtitle of a heading that shouldn't be part of the document outline, you should use the hgroup element:
<hgroup>
<h1>The World Wide Web Consortium</h1>
<h2>Leading the Web to Its Full Potential...</h2>
</hgroup>
In this example, only the h1 will show up in the document outline.
Table inspector
(This only applies to table elements used for tabular data — not for layout.)
HTML tables have two types of cells: header cells (th elements) and data cells (td elements). These cells are associated together in the table: a data cell in the middle of the table can have associated header cells, typically in the first row and/or the first column of the table. To a user who can see, this association seems obvious, but users who cannot see need some help from the computer to understand which cells are associated with which.
You should mark up your header cells with the th element and check that your cells get associated as you intended using the Table Inspector. If it isn't as you intended, you can consider simplifying or rearranging your table, or you can override the default association using scope or headers attributes.
Other tools?
If you know about other tools for helping with quality assurance of HTML5, or if you have made your own, please share!
Posted in Conformance Checking | 4 Comments »
Wednesday, November 15th, 2006
One of the predominate issues raised in the recent call for comments was surrounding
the whole HTML vs. XHTML debate, with many people suggesting that we should
not be extending HTML, but rather focussing on XHTML only.
However, what many people have failed to realise is that HTML5 resolves this issue: The (X)HTML5 specification
is in fact specifying extensions to both HTML and XHTML simultaneously, and
the choice of using either is no longer dependent upon the DOCTYPE.
Many authors use an XHTML 1.0 DOCTYPE and then proceed
to claim they’re using XHTML, but browsers make the decision whether to
treat a document as HTML or XHTML based on the MIME type. (X)HTML5 endorses
dispatching on MIME type: If the document is served as text/html,
it gets parsed as HTML; but if it is served with an XML MIME type, like
application/xml or application/xhtml+xml,
it gets parsed as XHTML.
Document Serializations
HTML5 introduces the concept of serialisations for an HTML document. A serialisation
in this context refers to the physical representation of the essence of the
document—the document tree. (X)HTML5 requires user agents that support scripting
to expose the document tree to the script using the DOM API and data model.
HTML5 uses the HTML serialisation and XHTML5 uses the XML serialisation.
Because of this, the distinction between an HTML and XHTML document is reduced.
In most cases, either serialisation can be used to represent exactly
the same document. The main differences are that the HTML serialisation, due to
backwards-compatibility reasons cannot represent structured inline-level elements (e.g. <ol>, <ul>, etc.)
as children of the <p> element and the XML serialization cannot
represent all possible document trees that may be created as a result of error
recovery in the HTML parsing algorithm. Also, in browsers, some scripting API features and
CSS layout details work differently depending on the serialisation of the document due to
backwards compatibility considerations.
The XML serialisation used by XHTML must be a well-formed XML 1.0 document.
However, unlike previous versions of HTML, the HTML serialisation is no longer
considered an application of SGML, but instead defines
its own syntax. While
the syntax is inspired by SGML, it is being defined in a way that more closely
resembles the way browsers actually handle HTML in the real world, particularly
in regards to error handling.
The HTML5 serialisation and the accompanying parsing algorithm are needed for three reasons:
- The browser that currently holds the majority market share doesn’t support XHTML (that is actually served and processed as XHTML).
- The legacy
text/html content out there needs a well-defined parsing algorithm—something that SGML-based HTML specifications haven’t been able to provide.
- There are content management systems, Web applications and workflows that are not based on XML tools and cannot produce well-formed output reliably. These systems can benefit from new features even though they wouldn’t work reliably with the XHTML serialisation.
On the other hand, thanks to the HTML/XHTML duality, new systems can be built on solid off-the-shelf XML tools internally and convert to and from the HTML5 serialisation at input/output boundaries. Once the installed base of browsers supports application/xhtml+xml properly, these systems can swap the output serialiser and start using XHTML-only features such as lists inside paragraphs.
The New DOCTYPE
In practice, the DOCTYPE serves two purposes: DTD based validation
and (for HTML only) DOCTYPE sniffing. Since HTML is no longer considered
an application of SGML and because there are many limitations with DTD based
validation, there will not be any official DTDs for (X)HTML5.
As a result, in the HTML serialisation, the only purpose for even having a
DOCTYPE is to trigger standards mode in browsers. Thus, because it doesn’t
need to refer to a DTD at all, the DOCTYPE is simply this:
<!DOCTYPE html>
I’m sure you would agree that that is about as simple and easy to remember
as possible. But, for XHTML, it’s even simpler. There isn’t one! Since
browsers have not (and will not) introduce DOCTYPE sniffing for
XML, there is little need for a DOCTYPE.
However, I should point
out that there is one other minor practical issue with DTDlessness in
XML. Entity references which are declared in the XHTML 1.0 DTD will
not be able to be used. However, since browsers don't use validating parsers
and do not read DTDs from the network anyway, the use of entity references
is not recommended. Instead, it is recommended to use character references
or a good character encoding (UTF-8) that supports the characters natively.
Conformance Checking
You’re no doubt wondering, if there are no DTDs, how will one go about validating
their markup. Well, that’s simple. There are in fact other, more robust methods
available for checking document conformance. There are several different schema
languages that can be used, including RELAX NG and Schematron. However, even
they cannot fully express the machine-checkable conformance requirements of
(X)HTML5.
Henri Sivonen is in the process of developing a conformance
checker for HTML5,
which is being designed to report much more useful error messages beyond
those that are possible using just a DTD based approach. For example, the table
integrity checker discussed previously is one feature that is impossible
to implement using DTDs.
Posted in Conformance Checking, Syntax | 6 Comments »