HTML 5

Welcome back to my semi-regular column, "The Road to HTML 5," where I'll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.

The feature of the day is spell checking, by which I mean client-side in-browser checking of text in standard <textarea> and <input type=text> elements. Several browsers support this out-of-the-box, including Firefox 2 and 3, Safari 3, Opera 9, and Google Chrome. However, each browser has different defaults of which elements get spell-checked, and only a handful allow the web author to suggest whether browsers should offer checking on a particular element.

In this article:

• A brief history of the spellcheck attribute
• Examples
• Browser support
• Detecting support for the spellcheck attribute
• Conclusion

A brief history of the spellcheck attribute

That last bit, by the way, is why this is relevant to HTML 5. Browser features are interesting, but are mostly outside the purview of spec-land. But the idea of a markup hint to suggest turning spell-checking on or off has been bounced around for years. To wit:

• May 2006: Mozilla bug 339127 - Provide a way for a web page to enable/disable spell checking on a given field. Brett Wilson outlines the thinking, and a potential algorithm, for using the accept attribute to trigger spell-checking.
• May 2006: Ian Hickson mentions <input type="text" accept=""> on the WHATWG mailing list, triggering a long discussion (continued in June archives). This discussion resulted in...
• June 2006: Spellchecking proposal #2, which argued against the more-general accept attribute and in favor of a more-specific spellcheck attribute. More discussion ensued, which led to...
• June 2006: Spellchecking mark III, which, unsurprisingly, led to even more discussion, but no resolution.
• December 2008: "the [spellcheck] attribute has seen very little interest outside of Google ... I have therefore not added this feature to HTML5 for the time being. If there is more interest in this feature, please speak up." Anne van Kesteren (Opera) immediately replied, "Opera wants to support this feature as well in due course." Maciej Stachowiak (Apple) stated, "WebKit by default spellchecks (and grammar checks) all editable parts of the document, and it is not obvious to me why one would want to force it off for particular form controls or editable HTML areas." More vigorous discussion (continued in January 2009 archives).
• February 2009: Ian Hickson announces, "I have added spellcheck="" to the spec." Followups mostly focus on what the attribute should be called, and what values it should take. (More on this in a minute.)
• February 26, 2009: "Based on the interest (not uniform interest, but interest nonetheless) on this topic, I've left the feature in the spec." Yeah, February 29th -- that was last week. So don't in any way consider this the final word on the subject.

Examples

Getting down to the technical details, the spellcheck attribute is a bit of an oddball. Most boolean attributes (such as <option selected>) are false if they are absent, true if they are present, and true if they are present with a value the same as the attribute name (e.g. <option selected=selected>). The spellcheck attribute is not like that; instead, it requires an attribute value of either true or false.

So this is valid:

<textarea spellcheck="true">

And this is valid:

<textarea spellcheck="false">

But this is not valid:

<textarea spellcheck>

Browser support

Browser support is currently... limited.

Markup	Firefox 3.0.6	Google Chrome 1.0.154.48	Safari 3.2.1	Opera 9.62
<input type=text>	offer on right-click	no check	check as you type	offer on right-click
<input type=text spellcheck=true>	check as you type	no check	check as you type	offer on right-click
<input type=text spellcheck=false>	offer on right-click	no check	check as you type	offer on right-click
<input type=text spellcheck> invalid	offer on right-click	no check	check as you type	offer on right-click
<input type=text spellcheck=spellcheck> invalid	offer on right-click	no check	check as you type	offer on right-click
<input type=text spellcheck=on> invalid	offer on right-click	no check	check as you type	offer on right-click
<input type=text spellcheck=off> invalid	offer on right-click	no check	check as you type	offer on right-click
<textarea>	check as you type	check as you type	check as you type	offer on right-click
<textarea spellcheck=true>	check as you type	check as you type	check as you type	offer on right-click
<textarea spellcheck=false>	offer on right-click	check as you type	check as you type	offer on right-click
<textarea spellcheck> invalid	check as you type	check as you type	check as you type	offer on right-click
<textarea spellcheck=spellcheck> invalid	check as you type	check as you type	check as you type	offer on right-click
<textarea spellcheck=on> invalid	check as you type	check as you type	check as you type	offer on right-click
<textarea spellcheck=off> invalid	check as you type	check as you type	check as you type	offer on right-click

In other words:

• In the absence of the spellcheck attribute, Firefox offers as-you-type spellcheck <textarea> elements but not <input type=text> elements. It treats the spellcheck attribute with a true or false value as a signal to offer as-you-type spellcheck (or turn it off where it defaults to on). All invalid markup variations are ignored, in the sense that they do not change Firefox's per-element-type defaults. It lets the user turn spellcheck on and off on a per-element basis, which overrides both the spellcheck attribute and the browser's per-element-type defaults.
• Google Chrome offers as-you-type spellcheck on <textarea> elements but not <input type=text> elements. It ignores the spellcheck attribute entirely. It does not offer the end user the option to change the default behavior or manually check individual fields.
• Safari 3 offers as-you-type spellcheck on <textarea> and <input type=text> elements. It ignores the spellcheck attribute entirely. It allows the user to toggle as-you-type spellcheck globally, which immediately affects all elements of all types. It does not offer the end user the option to change the default behavior or manually check individual fields.
• Opera 9 offers spellcheck from the context menu on <textarea> and <input type=text> elements. It ignores the spellcheck attribute entirely. It does not offer as-you-type spellcheck.

Detecting support for the spellcheck attribute

Browsers that support the spellcheck attribute will always reflect the attribute in the .spellcheck property of the element's DOM node, even if the spellcheck attribute does not appear in the page markup. You can use this to construct a simple test to check whether the browser supports the spellcheck attribute:

if ('spellcheck' in document.createElement('textarea')) {
    alert('browser supports spellcheck attribute');
  } else {
    alert('browser does not support spellcheck attribute');
  }

This will pop up an alert stating "browser supports spellcheck attribute" in Firefox 2 and 3, or an alert stating "browser does not support spellcheck attribute" in Safari 3, Opera 9, Google Chrome, and Internet Explorer.

Note: Internet Explorer will reflect any attribute present in the page markup. If you include a spellcheck attribute on an element and then test whether that element's DOM node contains a .spellcheck property, IE will always return true. The safest way to check is to create a new element in script, like the example above, instead of testing a pre-existing element on your page.

Conclusion

You can start using the spellcheck attribute today, but it only affects the behavior of Firefox. However, it has no adverse effects in other browsers. Be sure to use either spellcheck="true" or spellcheck="false", as these are the only values supported by Firefox (and the only valid values according to the HTML 5 spec as it stands today).

This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license