This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the spellcheck attribute is defined as causing the checking of “the value of input elements to which the readonly attribute applies, whose type attributes are not in the Password state, and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled)”. Formally, this means that when spellcheck is set, the value of the value=... attribute (which is the value of the element) is to be spellchecked, in the case of <input type=checkbox ...> or <input type=radio ...>. Browsers that support spellchecking don't seem to do such checks, and it is difficult to see why they should do so and how they could do so. It is also difficult to see why and how spellcheck should apply to <input type=range> for example. It would probably be best to specify a positive list: the spellcheck attrite should cause the value of <input type=text> or <input type=search> to be checked, under the given conditions. Alternatively, if spellcheck is really mean to cause other values to be checked, this should be specified explicitly for clarity, and some hint of the intended implementation should be given. For example, how should a browser report the spelling error in <input type=checkbox value=fjnggkj>, given that the value is normally not displayed to the user and is not really meant for human consumption?
The readonly attribute doesn't apply to type=checkbox, type=radio, and type=range.
The issue is the spellcheck attribute; the readonly attribute wasn’t even mentioned in the question.
(In reply to comment #2) > The issue is the spellcheck attribute; the readonly attribute wasn’t even > mentioned in the question. Sorry, I was confused. It was mentioned in the quote. I now see the idea, but I still think it’s confusing to have spellcheck applied only to elements to which readonly applies. It’s not logical to couple these things, and making spellcheck apply e.g. to email address controls is hardly a good idea; normally, an email address is just a string of a particular format, without having its components, still less it as a whole, something that should pass normal spelling and grammar check. So please excuse my confusion, and consider making the rules for spellcheck on input elements specified by a positive list, as applying to input elements in specific states (and states other than text and search hardly qualify – or it should at least be described what spelling checks mean when applied to data that is not expected to be normal text in a human language).
I agree that enabling it for type=email is kind of weird, but I don't think it's harmful, and its meaning for implementations isn't ambiguous. Defining things in terms of other attributes applying is something the spec does in a number of places, it's intended to minimise the fallout when new types are added. Would it help maybe if "applies" was a cross-reference to the non-normative table summarising which attributes apply in what states?
I'll assume yes; reopen if more is needed. Thanks.
Checked in as WHATWG revision r8011. Check-in comment: Try to be clearer about what 'applies' means for these input-related attributes. http://html5.org/tools/web-apps-tracker?from=8010&to=8011