This Week Day in HTML 5 – Episode 23
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group. The pace of HTML 5 changes has reached a fever pitch, so I'm going to split out these episodes into daily (!) rather than weekly summaries until things calm down.
The big news for February 12, 2009 is the minting of the the spellcheck
attribute, which web authors can use to provide a hint about whether a particular form field expects the sort of input that would benefit from client-side spell checking. r2801 lays it out:
User agents can support the checking of spelling and grammar of editable text, either in form controls (such as the value of
textarea
elements), or in elements in an editing host (usingcontenteditable
).For each element, user agents must establish a default behavior, either through defaults or through preferences expressed by the user. There are three possible default behaviors for each element:
- true-by-default
- The element will be checked for spelling and grammar if its contents are editable.
- false-by-default
- The element will never be checked for spelling and grammar.
- inherit-by-default
- The element's default behavior is the same as its parent element's. Elements that have no parent element cannot have this as their default behavior.
The
spellcheck
attribute is an enumerated attribute whose keywords aretrue
andfalse
. Thetrue
keyword map to the true state. Thefalse
keyword maps to the false state. In addition, there is a third state, the inherit state, which is the missing value default (and the invalid value default).
Starting with version 2, Mozilla Firefox has offered built-in spell checking of <textarea>
elements (on by default) and <input type=text>
elements (off by default). You can change the default behavior by setting the spellcheck
attribute. (test case)
The other big news of the day is the addition of the <form autocomplete>
attribute, while lets web authors provide a hint about whether they would like browsers to save the form's contents and pre-fill the form the next time the user encounters it. r2798:
When an
input
element's resulting autocompletion state is on, the user agent may store the value entered by the user so that if the user returns to the page, the UA can prefill the form. Otherwise, the user agent should not remember the control's value.... A user agent may allow the user to override the resulting autocompletion state and set it to always on, always allowing values to be remembered and prefilled), or always off, never remembering values. However, the ability to override the resulting autocompletion state to on should not be trivially accessible, as there are significant security implications for the user if all values are always remembered, regardless of the site's preferences.
<form autocomplete>
is commonly used on sensitive login forms where the site does not want users to be able to store their password in their browser (which is generally done in an insecure way). Most browsers honor these hints by default, although there are ways to override them if you dislike the idea of web authors disabling useful bits of your browser's functionality.
Other interesting changes of the day:
- r2802 allows external Javascript files to contain a BOM to facilitate identifying scripts in non-ASCII-compatible character encodings.
- r2796 adds some examples of using the unloved
<small>
element.
Discussion of the day: Gregory J. Rosmaita gives details on report of PFWG HTML5 actions ("PFWG" = Protocols and Formats Working Group). The original post was about accessibility issues, specifically a response to the <image alt>
attribute becoming optional and the omission of the headers
and summary
attributes in the HTML 5 table model. But the thread was quickly hijacked by a discussion of the fact that the W3C published another working draft of HTML 5 on February 12.
Wait... what? Oh yes, in true "burying the lede" fashion, I suppose I should mention that the biggest news of February 12th is that the W3C published another working draft of HTML 5. Except that readers of this series will find it uninteresting, since it's just a snapshot of the progress-to-date. (The spec is "published" on whatwg.org every time it changes anyway.) Working drafts have no formal status; they are merely intended to encourage early and wide review. Still, the rest of the world might think it's important, so be sure to bring it up at this weekend's cocktail parties.
Tune in... well, sometime soon-ish for another exciting episode of "This Week Day In HTML 5."
[…] new W3C Working Draft of HTML 5 is out. As I’ve mentioned before, this is just a snapshot of progress-to-date. By its very nature, it is out of date as soon as it’s […]
can you clarify this bit
“which is the missing value default ”
how would you enter spellchecks default behaviour?