This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When a spellcheckable field is loaded with preexisting content, browsers don't spellcheck it immediately, because they don't want to annoy the user about misspelled words that the user didn't enter. Test-case: data:text/html,<!doctype html><textarea>dhe kso</textarea> Firefox 19.0a1 and Opera Next 12.50 internal only displays squiggles when the textarea is first focused. Chrome 23 dev only displays them when you start typing (not sure of the exact algorithm). IE10 Developer Preview seems to only display them for words the user has actually modified. However, some authors would like spellcheck to take effect immediately on load no matter what. Real-world use-cases: https://bugzilla.mozilla.org/show_bug.cgi?id=364914#c58 https://bugzilla.mozilla.org/show_bug.cgi?id=799475#c8 In both cases, users are presented with text for proofreading other users' text. Squiggles should appear immediately even though they didn't enter it. There should be some mechanism (either declarative or scripted) to request that the text in the field all be spellchecked immediately. I've gone back and forth, but the most obvious solution to me at this point is to add a new spellcheck value, such as spellcheck="immediate". The fallback for this isn't ideal -- per spec, it will default to the same as not specifying spellcheck="" at all in old UAs. But a) this isn't a problem for textareas, since UAs all spellcheck those by default; b) you should theoretically be able to work around it by wrapping in <div spellcheck="true"> (I don't know if this works in all UAs); c) if all else fails you can feature-detect easily from JS. It seems better than alternative solutions I've thought of.
(In reply to comment #0) > I've gone back and forth, but the most obvious solution to me at this point > is to add a new spellcheck value, such as spellcheck="immediate". It just occurred to me that this doesn't work at all with a boolean reflected attribute. But it's the best I came up with.
Interesting. So first, the spec should probably suggest not doing the spelling checking for existing content. For the immediate checking thing, how about a method that triggers it?
Concretely, I propose we add to "must only consider the following pieces of text as checkable" a requirement that the text in question have been touched by the user, and that we add a method: HTMLElement.forceSpellCheck(); ...that marks the entire contents of the element as having been touched by the user for the purposes of this feature.
(In reply to comment #3) > Concretely, I propose we add to "must only consider the following pieces of > text as checkable" a requirement that the text in question have been touched > by the user, and that we add a method: > > HTMLElement.forceSpellCheck(); > > ...that marks the entire contents of the element as having been touched by > the user for the purposes of this feature. The forceSpellCheck method seems fine to me, but I'm not sure why we would force the UAs to only spell check the stuff that the user has touched. That's going to create inconsistent UA behavior and the meaning of "stuff that user has touched" isn't really quite clear (what if they edit a piece of text to correct a spelling mistake and then undo their edit, for example)? I'd be a lot more comfortable if the spec calls for the UA to check the entire content of the element.
(In reply to comment #4) > The forceSpellCheck method seems fine to me, but I'm not sure why we would > force the UAs to only spell check the stuff that the user has touched. > That's going to create inconsistent UA behavior and the meaning of "stuff > that user has touched" isn't really quite clear (what if they edit a piece > of text to correct a spelling mistake and then undo their edit, for > example)? I'd be a lot more comfortable if the spec calls for the UA to > check the entire content of the element. UAs already have inconsistent behavior here. Do you think we need to mandate a single behavior at this point? I think it's fine to let browsers experiment here for a while, perhaps indefinitely. I do think the spec should advise browsers not to spellcheck things the user hasn't interacted with yet, but for now browsers should be able to decide what "interact" means. (Gecko has the most liberal interpretation -- no other browser seems to spellcheck fields that were merely focused.)
I have an implementation on the Mozilla bug that works for textarea/<input type=text>, but not contenteditable yet. So I'm waiting on exact spec text to be checked in before I finalize it and push it to Firefox 19. Ryosuke, do you have any feedback? I dunno about Hixie, but I'd like at least one other implementer to look at this and agree it's reasonable before we ship this in production. (I don't plan to prefix it, if it's up to me.) Hixie, I'd also like to write some tests for this. Is there any good place to put them in WHATWG-land? Or are we using the W3C's html repo for this, or what? More importantly, do you have any ideas on *how* to test it? Mozilla currently uses reftests for this sort of thing, but that's hard to do acceptably in a standards test, because the criteria for when to display squiggly lines aren't standard. For our own purposes, we'd make the reference by doing .focus() then .blur(), but nothing says that has to make the squiggly lines appear cross-browser (and in fact it doesn't).
(In reply to comment #6) > > Ryosuke, do you have any feedback? I dunno about Hixie, but I'd like at > least one other implementer to look at this and agree it's reasonable before > we ship this in production. (I don't plan to prefix it, if it's up to me.) More input is certainly encouraged here. > Hixie, I'd also like to write some tests for this. Is there any good place > to put them in WHATWG-land? Or are we using the W3C's html repo for this, > or what? jgraham is the one to ask for this. If support is needed in WHATWG land let me know, we can set something up. > More importantly, do you have any ideas on *how* to test it? Strictly speaking, it's untestable, since user agents are allowed to use any UI for their spelling checkers as they want, including none whatsoever. At one level up from that, one could have a non-automated test that asks the user to type something misspelt, and then report whether they were told about it. If one needs to automate it, then a negative test is probably the way to do it: have two pages, one with spelling checking enabled and one with it disabled, and check that they aren't rendered in identical ways when one should be reporting a spelling error. Feel free to reopen this bug if the patch is deficient.
Checked in as WHATWG revision r7471. Check-in comment: Provide a forceSpellCheck() method. http://html5.org/tools/web-apps-tracker?from=7470&to=7471
The changes make sense to me. Thanks a lot, Hixie!
I suggest using the W3C repo for tests.