This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At 8.6.5 Spelling and grammar checking, several types of <input> elements are described as being checkable when spellcheck=true. Checking is said to be “checking of spelling and grammar of editable text” (where “or” might be more adequate than “and”, since these are different things, and spelling checks are much easier and more probably implemented). This is reasonably clear for <input type=text>, less clear for <input type=search>, and not clear at all for other types of <input>. (For <input type=search>, we might well wish to have spelling checks enabled, but hardly grammar checks, as the search words normally do not constitute a sentence. However, there is currently no way to distinguish these.) There’s the statement “User agents should take into account the other semantics given in the document when suggesting spelling and grammar corrections.” This might be seen as implying that e.g. for <input type=email>, the checking should really consist of checking the syntactic validity of the input as an email address. This is rather different from “checking of spelling and grammar”. If this is the intent, then what is the point, since the input is assumed to be checked anyway, as part of the very definition of <input type=email>? Would <input type=email spellcheck=true> add something to the normal checks, and would <input type=email spellcheck=false> disable them? Since the checking is said to apply to the value of the <input> element, would <input type=date spellcheck=true> really apply to the ISO 8601 conformant value assigned to the element? Or would it apply to the data as input by the user (even though that data will normally not become value of the element as such)?
> Checking is said to > be “checking of spelling and grammar of editable text” (where “or” might be > more adequate than “and”, since these are different things, and spelling > checks are much easier and more probably implemented). In English, "or" is generally interpreted as an exclusive or. Checking of both is the intent here. Naturally, since the spec doesn't define what grammar checking actually is, you could check both by having your grammar checking be trivially useless. > This is reasonably > clear for <input type=text>, less clear for <input type=search>, and not > clear at all for other types of <input>. (For <input type=search>, we might > well wish to have spelling checks enabled, but hardly grammar checks, as the > search words normally do not constitute a sentence. However, there is > currently no way to distinguish these.) Even when checking is enabled, user agents may opt to not report spelling or grammar errors in text that the user agent deems the user has no interest in having checked. > There’s the statement “User agents should take into account the other > semantics given in the document when suggesting spelling and grammar > corrections.” This might be seen as implying that e.g. for <input > type=email>, the checking should really consist of checking the syntactic > validity of the input as an email address. On the contrary. If I type "ina@hixie.ch", and the browser knows my e-mail address is "ian@hixie.ch" and has never heard of "ina@hixie.ch", it would be entirely useful for it to raise this as a possible spelling error. > Since the checking is said to apply to the value of the <input> element, > would <input type=date spellcheck=true> really apply to the ISO 8601 > conformant value assigned to the element? The readonly="" attribute doesn't apply to type=date, so spellcheck="" doesn't do anything in this case. I've made some minor tweaks to the text, but in general I don't see a problem with the text here.
Checked in as WHATWG revision r8034. Check-in comment: Minor tweaks of spellcheck='' text. http://html5.org/tools/web-apps-tracker?from=8033&to=8034
(In reply to comment #1) > > Checking is said to > > be “checking of spelling and grammar of editable text” (where “or” might be > > more adequate than “and”, since these are different things, and spelling > > checks are much easier and more probably implemented). > > In English, "or" is generally interpreted as an exclusive or. Many people say so, and use the artificial “or both” phrase or the “and/or” pseudo-connective to get inclusive or, but in actual usage in English, “or” is inclusive unless the context clearly implies otherwise. “Today, I would like to swim or to walk in the woods” by no means implies or suggests that I could not do both. “Do you want tea or coffee?” suggests exclusion, but only because people usually don’t have tea and coffee at the same time. But “Do you want ham or cheese on your sandwich?” is different; you would well respond “Both, please.” In an attempt to avoid the imaginary exclusiveness, the use of “and” means definitive inclusivess. Hardly a good idea, since we know that current software performs, at most, spelling checks and since for many input types, grammar checks would not make sense. > Checking of > both is the intent here. Naturally, since the spec doesn't define what > grammar checking actually is, you could check both by having your grammar > checking be trivially useless. That sounds artificial, almost as artificial as it would be to add “and checks for factual correctness”, with the remark that browsers could have their factual correctness checking be trivially useless (i.e., accept everything as correct). If this sounds too weird, you could consider style checks – some word processors do such things, and they could be performed by browsers, too The key issue here is that spelling and grammar checking is not defined at all. In normal language, “spelling checks” mean checking words against a set of words in a human language (using dictionaries and possibly algorithms that generate or analyze inclined forms of words). Similarly, “grammar checks” means checking the text against some grammar rules of a human language. If you mean something very different, or something that could be very different, like checking e-mail addresses against an address book, I think you should use different words or explain what “spelling checks” and “grammar checks” mean. > Even when checking is enabled, user agents may opt to not report spelling or > grammar errors in text that the user agent deems the user has no interest in > having checked. This sounds a bit of too futuristic. On what grounds could a browser reasonably make decisions on such things? > > There’s the statement “User agents should take into account the other > > semantics given in the document when suggesting spelling and grammar > > corrections.” This might be seen as implying that e.g. for <input > > type=email>, the checking should really consist of checking the syntactic > > validity of the input as an email address. > > On the contrary. If I type "ina@hixie.ch", and the browser knows my e-mail > address is "ian@hixie.ch" and has never heard of "ina@hixie.ch", it would be > entirely useful for it to raise this as a possible spelling error. I don’t think browsers will perform such checks anytime soon, but if you think it is useful to refer to such possibilities, then I think it should be spelled out what “spelling and grammar checks” for e-mail controls could consist of. Ditto for other types of input. Perhaps it would be better to use an expression like “input checks” or something equally abstract, if the intent is that there checks could vary greatly by input type and by browser. This would make the attribute name (spellcheck) somewhat odd, but it already is, if the checks may contain grammar checks too. (“I has a idea” may fail a grammar check, but not a spelling check.) > The readonly="" attribute doesn't apply to type=date, so spellcheck="" > doesn't do anything in this case. According to the table in 4.10.7 The input element, as well as the normative text in 4.10.7.1.8 Date state (type=date), the readonly="" attribute applies to type=date. Yucca
(In reply to comment #3) > > That sounds artificial It's a spec. It's entirely artificial. :-) What we want is spelling and grammar checking. That browsers only currently attempt one is really neither here nor there, as far as I can tell. I don't see what the problem is. > The key issue here is that spelling and grammar checking is not defined at > all. I don't understand why this is an issue. Interoperability on exactly how spelling and/or grammar checking works is not necessary. > If you mean something very different, or something that could be > very different, like checking e-mail addresses against an address book, I > think you should use different words or explain what “spelling checks” and > “grammar checks” mean. What words would you suggest? What I mean is "check that the text is spelt correctly and has understandable grammar, such that the text is readable to other people and is likely free of the kind of literacy mistakes that the author may wish to avoid making". But I don't see why "spelling and grammar" is not a sufficiently clear briefer version of this. > > Even when checking is enabled, user agents may opt to not report spelling or > > grammar errors in text that the user agent deems the user has no interest in > > having checked. > > This sounds a bit of too futuristic. The spec is aspirational. Think big, man! Let's not limit our goals when we have no reason to. > On what grounds could a browser reasonably make decisions on such things? For example, when the text is a quotation and the user agent recognises the quotation as being one from an earlier e-mail sent by another user, it would not need to flag mistakes. > > On the contrary. If I type "ina@hixie.ch", and the browser knows my e-mail > > address is "ian@hixie.ch" and has never heard of "ina@hixie.ch", it would be > > entirely useful for it to raise this as a possible spelling error. > > I don’t think browsers will perform such checks anytime soon, but if you > think it is useful to refer to such possibilities, then I think it should be > spelled out what “spelling and grammar checks” for e-mail controls could > consist of. Ditto for other types of input. I don't see much point in going into detail here. Interoperability of user interface features isn't necessary. Browsers are welcome to innovate as they wish in this area. The role of the spec in such matters is just to allow it and get out of the way. > Perhaps it would be better to use an expression like “input checks” or > something equally abstract, if the intent is that there checks could vary > greatly by input type and by browser. This would make the attribute name > (spellcheck) somewhat odd, but it already is, if the checks may contain > grammar checks too. Making it more abstract would not lead to implementors having a greater understanding of the section. Phrasing it as it is phrased today does not lead to implementors having a more limited view of what can be implemented. So I don't see the problem with the current text. > > The readonly="" attribute doesn't apply to type=date, so spellcheck="" > > doesn't do anything in this case. > > According to the table in 4.10.7 The input element, as well as the normative > text in 4.10.7.1.8 Date state (type=date), the readonly="" attribute applies > to type=date. Woops. Thanks. Fixed.
Checked in as WHATWG revision r8044. Check-in comment: Make spellcheck='' not apply to controls like <input type=date> that don't have usefully checkable content. http://html5.org/tools/web-apps-tracker?from=8043&to=8044
(In reply to comment #4) > What we want is spelling and grammar checking. That browsers only currently > attempt one is really neither here nor there, as far as I can tell. I don't > see what the problem is. What “we” want should not be decisive here. What matters is what authors may conceivably want to achieve. The spellcheck attribute is supposed to control whether some checks are performed or not. It surely matters to authors what those checks are. For example, for <input type=search>, spelling checks (in the normal, limited sense) may well be desirable, if users are expected to enter natural language words. Grammar checks would generally be undesirable. Not to mention whatever other checks might be allowed according to some vague description. It is clearly best to limit spellcheck to spelling checks, which is what (some) browsers are currently capable of doing and which are often desirable. We can worry about grammar checks, or semantic checks, or other checks as they become realistic options. Then other attributes would presumably be needed, or maybe just one attribute with a list of keywords as value. > Interoperability on exactly how > spelling and/or grammar checking works is not necessary. Interoperability, at some conceptual level at least, is crucial when an author uses an attribute to request for checks. When I ask for spelling checks, for example, I need to accept the situation that some browsers won’t perform them. But it would be unacceptable to have the perform some completely different checks. > What words would you suggest? > > What I mean is "check that the text is spelt correctly and has > understandable grammar, such that the text is readable to other people and > is likely free of the kind of literacy mistakes that the author may wish to > avoid making". But I don't see why "spelling and grammar" is not a > sufficiently clear briefer version of this. If you want that, then the attribute name should preferably be different. But what you want is very unrealistic for a long, long time. What’s worse, such a definition would allow all kinds of “heuristic” checks that go far beyond spelling checks and would not be what authors wanted. For example, understandability and readability are very broad and very vague concepts and could easily be interpreted as flagging long or learned words, complicated grammatical structures, and mere sequences of words (that people typically enter in search boxes). > Interoperability of user > interface features isn't necessary. Browsers are welcome to innovate as they > wish in this area. The role of the spec in such matters is just to allow it > and get out of the way. Browsers may add checks, but regarding HTML attributes that turn checks on or off, the key question is whether authors can know which checks they would affect.
> What “we” want should not be decisive here. What matters is what authors may > conceivably want to achieve. By "we" I meant everyone, including authors. > The spellcheck attribute is supposed to control > whether some checks are performed or not. It surely matters to authors what > those checks are. Does it? I don't think so. I mean, it doesn't matter to authors whether my local dictionary has the word "embiggen" in it or not, does it? > For example, for <input type=search>, spelling checks (in the normal, > limited sense) may well be desirable, if users are expected to enter natural > language words. Grammar checks would generally be undesirable. Not to > mention whatever other checks might be allowed according to some vague > description. Sure. User agents should do whatever is useful for users. > It is clearly best to limit spellcheck to spelling checks, which is what > (some) browsers are currently capable of doing and which are often > desirable. I disagree with the premise here. Grammar checking is IMHO "clearly" a desirable feature. I don't see any reason why we'd want to prevent user agents from implementing it. > We can worry about grammar checks, or semantic checks, or other > checks as they become realistic options. There's nothing unrealistic about grammar checking. Tools have been doing this for years, decades even. > Then other attributes would presumably be needed, or maybe just one > attribute with a list of keywords as value. I don't see why. It seems highly undesirable to me to have a large API surface area here. What would the default value for a hypothetical "grammarcheck" attribute be? Enabled? But then fields that the authors wanted to disable spelling checking for would have grammar checking, which is unlikely to be what authors want. Disabled? But then there'd be no grammar checking by default, which would be pointless — I certainly want grammar checking on this comment text field, for example. Whichever way you slice this, it doesn't work. > > Interoperability on exactly how > > spelling and/or grammar checking works is not necessary. > > Interoperability, at some conceptual level at least, is crucial when an > author uses an attribute to request for checks. Sure. That's what the spec defines. > When I ask for spelling checks, for example, I need to accept the situation > that some browsers won’t perform them. But it would be unacceptable to have > the perform some completely different checks. Why? > > What words would you suggest? > > > > What I mean is "check that the text is spelt correctly and has > > understandable grammar, such that the text is readable to other people and > > is likely free of the kind of literacy mistakes that the author may wish to > > avoid making". But I don't see why "spelling and grammar" is not a > > sufficiently clear briefer version of this. > > If you want that, then the attribute name should preferably be different. That ship has sailed. > But what you want is very unrealistic for a long, long time. It's not unrealistic at all. It's widely implemented, just not in browsers. Google Docs, for example, will point out the error in "I sea the see". Microsoft Word has had a grammar checker for years. There are online tools that do punctuation and capitalisation checks. I don't understand why you think this is science fiction. > What’s worse, such a definition would allow all kinds of “heuristic” checks > that go far beyond spelling checks and would not be what authors wanted. That's not a bad thing. It's a good thing. That's the whole point. > For example, > understandability and readability are very broad and very vague concepts and > could easily be interpreted as flagging long or learned words, complicated > grammatical structures, and mere sequences of words (that people typically > enter in search boxes). Yes, type=search should be an indicator to a user agent that precise grammar may not be the most useful feature to enable in that text field. > > Interoperability of user > > interface features isn't necessary. Browsers are welcome to innovate as they > > wish in this area. The role of the spec in such matters is just to allow it > > and get out of the way. > > Browsers may add checks, but regarding HTML attributes that turn checks on > or off, the key question is whether authors can know which checks they would > affect. The check that this attribute enabled is "literacy". I see no reason why authors would have any trouble with this.
(In reply to comment #7) > > The spellcheck attribute is supposed to control > > whether some checks are performed or not. It surely matters to authors what > > those checks are. > > Does it? I don't think so. I mean, it doesn't matter to authors whether my > local dictionary has the word "embiggen" in it or not, does it? It could, but this is really about bigger issues. It does matter to authors whether only spelling checks are performed or grammar (or style) checks are made, too. For example, if a textarea is for free-form user feedback, authors probably prefer having it grammar checked too. If it is for a list of food names, it should normally be spelling checked if possible, but not grammar checked – it would be pointless to let software report that the words do not constitute a sentence, when it is not supposed to. > > It is clearly best to limit spellcheck to spelling checks, which is what > > (some) browsers are currently capable of doing and which are often > > desirable. > > I disagree with the premise here. Grammar checking is IMHO "clearly" a > desirable feature. It may, or it may not, depending on the context and purpose of a control. The point is that the author is expected to know them and thus decide whether the grammar should be checked (if the browser supports that). Please do not confuse the usefulness of options for various checks in a browser with the issue whether such options, when available, should be enabled for some controls. > I don't see any reason why we'd want to prevent user > agents from implementing it. Neither do I. The issue is whether authors have control over this, so that e.g. grammar checks won’t be used for text is not expected to be grammatical sentences. > > We can worry about grammar checks, or semantic checks, or other > > checks as they become realistic options. > > There's nothing unrealistic about grammar checking. Tools have been doing > this for years, decades even. The current state of the art is that grammar checking software is available for a few important languages, with varying levels of quality, but no browser applies such technologies. The software tends to be proprietary, so you can get it if you buy a license for Microsoft Office or specialized language processing program, but it is unrealistic to expect that such features will be in browsers anytime soon. > > Then other attributes would presumably be needed, or maybe just one > > attribute with a list of keywords as value. > > I don't see why. It seems highly undesirable to me to have a large API > surface area here. There are clearly different checks that may be performed, and authors should be able to specify which of them are applied. > What would the default value for a hypothetical "grammarcheck" attribute be? The spellcheck attribute already has browser-dependent default values for various elements. I think the defaults should be defined in a specification, but that’s a different issue. The question of defaults should not be regarded as an objection to having grammar checks separately settable. Considering the future, it might be best to specify an attribute, with a name like “check” and with a space-separated list of keywords as value, specifying the checks to be performed. And “spellcheck” could be made a synonym for check="spell". It would not create a massive API surface area to have the option of setting check="spell grammar style". This would correspond to the way you can control in MS Word what kinds of checks are performed on texts in English. > > When I ask for spelling checks, for example, I need to accept the situation > > that some browsers won’t perform them. But it would be unacceptable to have > > the perform some completely different checks. > > Why? Because the expected data could be a list of words or isolated phrases, so that grammar and style checks would surely make browsers flag “errors”, confusing the user. > > What’s worse, such a definition would allow all kinds of “heuristic” checks > > that go far beyond spelling checks and would not be what authors wanted. > > That's not a bad thing. It's a good thing. That's the whole point. The whole point of an HTML attribute is to express the author’s intentions, not disable or enable things that he did not even consider. > Yes, type=search should be an indicator to a user agent that precise grammar > may not be the most useful feature to enable in that text field. So you are more or less saying that browsers are expected to infer, from the type of an input control, that grammar should not be checked, even if spelling checks are enabled. What I have been saying is that authors should have such control for all elements that might be checked. It is usually not desirable to have grammar checks for type=search, but if the search clause is really expected to be a natural language sentence (like some search systems have: the user should enter a question sentence). The browser cannot guess this; so give authors the chance to inform it. > > Browsers may add checks, but regarding HTML attributes that turn checks on > > or off, the key question is whether authors can know which checks they would > > affect. > > The check that this attribute enabled is "literacy". I see no reason why > authors would have any trouble with this. I can’t see what you mean by that. It seems that you are saying that authors should be happy with an attribute that enables or disables some unspecified checks for “literacy” or “goodness”. Yucca
Actually, turns out this is even less academic than I thought. Chrome seems to already do this. Type "I sea the noehi" into the "whiteboard" field on this page. I get the word "sea" underlined in green, and the word "noehi" underlined in red. Given that browsers are already doing this, where's the uproar from Web authors? If they don't want this, you'd expect to see some. > It could, but this is really about bigger issues. It does matter to authors > whether only spelling checks are performed or grammar (or style) checks are > made, too. For example, if a textarea is for free-form user feedback, > authors probably prefer having it grammar checked too. If it is for a list > of food names, it should normally be spelling checked if possible, but not > grammar checked – it would be pointless to let software report that the > words do not constitute a sentence, when it is not supposed to. Well, I tried typing a list of food names in the whiteboard field above, and Chrome didn't complain. So I guess the shipping state of the art already handles this case fine. > The point is that the author is expected to know them and thus decide > whether the grammar should be checked (if the browser supports that). Please > do not confuse the usefulness of options for various checks in a browser > with the issue whether such options, when available, should be enabled for > some controls. I think it would be perfectly reasonable in the future to provide more fine-grained control, sure. The way we build the Web is by starting with coarse features, and adding more fine-grained control over time _as needed_. This helps ensure that we don't add features that aren't needed. > Neither do I. The issue is whether authors have control over this, so that > e.g. grammar checks won’t be used for text is not expected to be grammatical > sentences. I don't see evidence that this is yet a real problem. > The current state of the art is that grammar checking software is available > for a few important languages, with varying levels of quality, but no > browser applies such technologies. Chrome apparently does. Today. > So you are more or less saying that browsers are expected to infer, from the > type of an input control, that grammar should not be checked, even if > spelling checks are enabled. Yeah. Not only expected; they apparently already do. > The browser cannot guess this; so give authors the chance to inform it. It's not clear to me that the browser can't guess it. > It seems that you are saying that authors should be happy with an attribute > that enables or disables some unspecified checks for “literacy” or “goodness”. Yes. I think the problem raised here is theoretical at best, and has no supporting evidence to suggest it's a real problem. I don't want to fix problems that aren't real. We have bigger fish to fry.
(In reply to comment #9) > Actually, turns out this is even less academic than I thought. Chrome seems > to already do this. Type "I sea the noehi" into the "whiteboard" field on > this page. I get the word "sea" underlined in green, and the word "noehi" > underlined in red. Not in my Chrome (29beta, language and spelling check language set to US English and spelling checks of text fields enabled); only “noehi” is underlined in red. I wonder if there is some add-on or special setting in your Chrome. Anyway, the “whiteboard” has no “spellcheck” attribute. Whether Chrome checks the field depends on browser settings. Regarding HTML, the relevant question is: what is the effect of HTML attributes in situations where they can have any effect (i.e., they are not overridden by browser settings)? Actually, it seems that Chrome does not honor the attribute at all: its operation depends on the browser setting (both regarding to whether checking is done and regarding to the spelling check language). > Given that browsers are already doing this, where's the > uproar from Web authors? If they don't want this, you'd expect to see some. I have seen a number of questions about disabling/enabling spelling checks at StackOverflow, reflecting some frustration. But the issue is whether authors can safely use “spellcheck” attribute when they really want just spelling checks. > Well, I tried typing a list of food names in the whiteboard field above, and > Chrome didn't complain. So I guess the shipping state of the art already > handles this case fine. I wonder what your Chrome is doing. > > So you are more or less saying that browsers are expected to infer, from the > > type of an input control, that grammar should not be checked, even if > > spelling checks are enabled. > > Yeah. Not only expected; they apparently already do. I don’t think browsers can read the minds of authors. > > The browser cannot guess this; so give authors the chance to inform it. > > It's not clear to me that the browser can't guess it. If you were a browser, would you think that grammar checking should be applied to <input type=text name=arvaapamikätämäon class=jotainkivaa> and on what grounds would you do that?
Check if you have "Use a web service to help resolve spelling errors" in your settings. I expect that's how the grammar checking is done. > > Given that browsers are already doing this, where's the > > uproar from Web authors? If they don't want this, you'd expect to see some. > > I have seen a number of questions about disabling/enabling spelling checks > at StackOverflow, reflecting some frustration. Please do cite these. That's exactly the kind of data that directly drives decisions here. > If you were a browser, would you think that grammar checking should be > applied to > > <input type=text name=arvaapamikätämäon class=jotainkivaa> > > and on what grounds would you do that? I've no idea. Do you have a concrete page on a real site where the browsers are doing something different than what the author wants, where the author can't currently control it?
(In reply to comment #11) > Check if you have "Use a web service to help resolve spelling errors" in > your settings. I expect that's how the grammar checking is done. Thank you, this was interesting information. The setting is apparently off by default, and it seems to work oddly (it magically stopped working for me today; somewhat like IE 10 which reportedly loses its spelling checking at times). In any case, it seems that it’s not grammar checking at all. A grammatically malformed sentence does not trigger errors. Rather, it seems that the service does some contextual checking: after “you”, “see” is very common, whereas “sea” hardly ever appears. > > I have seen a number of questions about disabling/enabling spelling checks > > at StackOverflow, reflecting some frustration. > > Please do cite these. That's exactly the kind of data that directly drives > decisions here. Searching StackOverflow for html5 spellcheck shows confusion of many kinds, e.g. http://stackoverflow.com/questions/9390429/html5-spellcheck (lack of browser support) http://stackoverflow.com/questions/4162124/html5-spellcheck-attribute-question (what is the default value?) http://stackoverflow.com/questions/5601431/spellcheck-false-on-contenteditable-elements (setting spellcheck off does not remove indications of errors detected) > > If you were a browser, would you think that grammar checking should be > > applied to > > > > <input type=text name=arvaapamikätämäon class=jotainkivaa> > > > > and on what grounds would you do that? > > I've no idea. Then I rest my case. If an educated human person like you cannot decide that, then how could a browser do so? > Do you have a concrete page on a real site where the browsers > are doing something different than what the author wants, where the author > can't currently control it? The question about the meaning of the spellcheck attribute is about preventing confusion if/when browsers start applying more advanced (or just different) checks than simple spelling checks. There is enough confusion around the attribute due to implementations and inevitable technical difficulties. It is therefore best to avoid adding a risk of confusion (what will browsers *really* check if I set spellcheck=true?) that can easily be avoided by limiting spellcheck to the meaning suggested by its name. This would in no way prevent browsers from adding other checks. It would just mean that application of those other checks is not affected by the spellcheck attribute.
(In reply to comment #12) > > In any case, it seems that it’s not grammar checking at all. It's not just spelling checking either. It's "literacy checking". Is "My columns is gooder" bad spelling or bad grammar? Maybe I just misspelt "is" and "better". Maybe I misspelt "word". > http://stackoverflow.com/questions/9390429/html5-spellcheck > http://stackoverflow.com/questions/4162124/html5-spellcheck-attribute- > question > http://stackoverflow.com/questions/5601431/spellcheck-false-on- > contenteditable-elements None of these indicate any problem with the idea of "spellcheck" doing more than simple spelling checking. > Then I rest my case. If an educated human person like you cannot decide > that, then how could a browser do so? Maybe it has context, e.g. every other user that went to this page typed things with grammar and spelling errors and didn't correct them when prompted, and therefore it likely isn't useful to point them out. I'm certainly not going to write the spec on the assumption that no browser authors are able to come up with anything I can't come up with! The whole point is to make it possible for browser developers to build _better_ things. > > Do you have a concrete page on a real site where the browsers > > are doing something different than what the author wants, where the author > > can't currently control it? > > The question about the meaning of the spellcheck attribute is about > preventing confusion if/when browsers start applying more advanced (or just > different) checks than simple spelling checks. There is enough confusion > around the attribute due to implementations and inevitable technical > difficulties. I disagree that there is sufficient confusion to preemptively attempt to limit the feature's usefulness so as to limit the additional confusion later. I also disagree that browsers doing more elaborate checking will cause substantial confusion sufficient to justify making the feature less powerful. I also disagree that splitting the feature into multiple features so that different aspects of literacy checking are controlled by different attributes or values would reduce confusion. Based on the above, I'm marking this WONTFIX. Please feel free to reopen this if you think you have additional information that impacts the above reasoning or if you think there are aspects of previously-presented information or reasoning that have not been considered to their fullest extent.