[whatwg] Spellchecking mark III

[Ian Hickson]

I believe this answers all outstanding e-mails on the subject, please let 
me know if I missed one. I include a new proposal (still with a 
spellcheck="" attribute, based mostly on implementation feedback from the 
Mozilla guys) at the end of the e-mail.


On Sun, 11 Jun 2006, Robert Græsdal wrote:
>
> How about something like cascading behaviour sheets?
> 
> <style type="text/cbs">
> #first-name {
> 	inputmode: user startUpper;
> 	spellcheck: enabled;
> }
> .cplusplus {
> 	spellcheck: disabled;
> 	autoindent: C++;
> 	highlight: C++;
> 	auto-evaluate: disabled;
> }
> .math {
> 	spellcheck: math;
> 	inputmode: math;
> 	highlight: math;
> 	auto-evaluate: enabled;
> }
> </style>
> 
> I'd hate to have to specify all those attributes to every single input 
> field for sure.

Well, it wouldn't be stylistic per se, so I don't think it would belong in 
the stylesheet. Even if you disable the styles, the spellcheck settings 
still apply.


> By the way - Hello everyone, this is my first post to the list.

Welcome!


On Sun, 11 Jun 2006, Matthew Raymond wrote:
>
> If, however, we're really just talking about adding words to the UA 
> dictionary temporarily and for a specific site, couldn't we just do that 
> with <meta> using the same format as we do with keywords?
> 
> | <meta name="vocabulary" lang="en-us"
> |  content="HTML5, WHATWG, WF2, WA1, WD1, CSS3-UI, TARDIS, ZPM, DHD">
> 
> Are there actually situations where different controls would need 
> different vocabulary?!?

That's an interesting idea, but I'd shy away from doing this for now. 
Let's start small and build up...


On Sun, 11 Jun 2006, Alexey Feldgendler wrote:
>
> Maybe features like spellckeching, syntax highlighting and so on should 
> be controlled via CSS? That way, they can be fine-tuned to any degree of 
> precision without complicating the HTML schema. This will also reduce 
> verbosity of <input> elements because they would otherwise have the same 
> repeated attributes.

While I certainly sympathise with the concern of heavy input elements 
(that's why I was against the spellcheck="" attribute in the first place), 
I don't think this is stylistic. Maybe we need another kind of macro 
capability, such as XBL, for this problem.


> Information like "this input field should have autoindent" is 
> presentational.

Yeah, but you'd have to say "auto-indent this like C++", which isn't. 
IMHO.

You should raise this in the www-style list, though, if you do think it 
is appropriate.




On Sun, 11 Jun 2006, Lachlan Hunt wrote:
> 
> No, spell checking is a user agent feature that should be controlled by 
> the UA and the user.  Authors should have no explicit control over it. 
> Besides, spell checking *is not* presentation, it is UA functionality 
> and so it does not belong in the presentation layer.

I agree that it isn't presentation, but I disagree that the author 
shouldn't be able to suggest whether or not to enable it. More on this 
below.


On Sun, 11 Jun 2006, Alexey Feldgendler wrote:
> > 
> > Besides, spell checking *is not* presentation, it is UA functionality 
> > and so it does not belong in the presentation layer.
> 
> Visual elements      <=> Presentation
> Interactive elements <=> Behavior
> 
> I think these are similar relationships. BTW, isn't the "cursor" CSS 
> property about behavior?

The "behaviour" vs "presentation" debate is a rat hole. The key thing is 
"should this continue to work if you disable the author stylesheet" and 
"should this continue to work if you stop using a screen".

It is clear, IMHO, that spellchecking being enabled or not is independent 
of both whether the author's stylesheet is enabled or not and whether the 
content is being displayed on a screen or not.


On Sun, 11 Jun 2006, Alexey Feldgendler wrote:
> > > 
> > >  One can also say that authors should not have explicit control over 
> > > whether hyperlinks are underlined or not.
> > 
> > The difference is that underlining is presentation, spell checking is 
> > not. The functionality of a link cannot be changed with CSS, likewise 
> > spell checking shouldn't either.
> 
> Enabling or disabling spell checking doesn't change the functionality of 
> an input.

Sure it does. It changes whether or not the user's typos will be flagged 
to the user or not. That seems like quite a big difference.


> It can still be used to submit arbitrary text to the server.

By that argument. type=text vs type=password is a presentational aspect. 
Or even more, type=text vs type=checkbox.


> But misspelled words in an input with spellchecking enabled are 
> underlined with a wavy red line (and the underlining style could even be 
> changed by CSS), and that's presentation.

I agree that the line itself should be stylable in CSS (if at all), but I 
disagree that the presence or absence of the line is a stylistic matter.


On Mon, 12 Jun 2006, Lachlan Hunt wrote:
> 
> While the core functionality of allowing the user to enter text isn't 
> changed, I'd consider spell checking to be part of the control's 
> functionality, and so disabling it would change the functionality for 
> the user.

Agreed.


> Arguably, yes, but allowing authors to alter the presentation of 
> misspelled words from the UAs default settings would only introduce 
> usability problems. Users may not easily recognise any presentation set 
> by the author as representing a missplled word.  UAs may provide a way 
> for the user to set their preferred presentation using some UA-specific 
> means, but there's no need at all for the author to have any control 
> over it.

I agree, I don't think we need to give authors control over this, unless 
they really go out of their way to make wacky different input controls.

In any case, that is out of scope for this group. How to style spelling 
errors should be discussed in the CSS lists.


On Mon, 12 Jun 2006, Alexey Feldgendler wrote:
> 
> There's nothing really bad in allowing CSS to control behavior to some 
> extent.

CSS is the part of the document that can be disabled/replaced. If 
disabling the author styles changes the functionality of the page, then 
that's bad.


> CSS is a good rule-based language, and there is a use case -- why not 
> reuse the CSS engine (selectors, cascading etc)?

There certainly is a good argument to say that the selector system should 
be used for defining element implementations, and indeed XBL2 uses 
selectors for exactly this purpose. But that is separate from using style 
sheets themselves.


On Mon, 12 Jun 2006, Matthew Raymond wrote:
> 
> CSS:
> | binding: url('example.xbl#binding1');
> 
> XBL2:
> | <?xml version="1.0"?>
> | <xbl xmlns="http://www.mozilla.org/projects/xbl/xbl2.html">
> |   <binding id="binding1">
> |     <handlers>
> |       <handler event="click" button="0" action="LeftClick();"/>
> |       <handler event="mouseup" button="1" action="MiddleUp();"/>
> |       <handler event="click" button="2" action="RightClick();"/>
> |     </handlers>
> |   </binding>
> | </xbl>

Or just:

XHTML:
   <?xbl href="example.xbl"?>

XBL2:
   <xbl xmlns="...">
     <binding elements=".foo">
       ...
     </binding>
   </xbl>

...with no CSS in sight (for those cases where the binding is not 
presentational but functional).


On Sun, 11 Jun 2006, Lachlan Hunt wrote:
> >
> > The original use case, as I understand it, was roughly "authors want 
> > to disable spell checking on some textareas".
>
> Authors should not have such control.  Spell checking is a user agent 
> feature for the *user* and the UA should allow the user to turn it on or 
> off whenever they like.  Why should the author have any say about that?

See below.


> For other unknown fields, browsers could use some Artificial 
> Intelligence (AI) to learn what a user typically enables and disables 
> spell checking for.  e.g. If a user constantly disables spell checking 
> for fields with <input name="address1"> or a <label>Address</label> 
> associated with the control (or similar variations), the AI could use 
> that to determine that spell checking wouldn't be desired for similar 
> fields.

Heuristics are historically a pain in the ass in this kind of context. 
(See, e.g., the failed experiments at making "form autofill" features. The 
password manager aspects are all that survived that.)


On Thu, 15 Jun 2006, Sander Tekelenburg wrote:
> 
> I do see the use for allowing authors to indicate what language 
> submitted content should be in, so that a user-agent can offer 
> spell-/syntax checking if the user wants to. But I don't see at all why 
> you would want to allow authors to flat out state that a spellchecker 
> should be on or off. Just like authors cannot know what font size is 
> best for a user they cannot know whether a spellchecker is useful or a 
> nuisance.

But they can suggest what font-size might be most appropriate. The 
suggestion is not to have spell checking be "on" or "off" at the user's 
whim; the choice is over whether or not, *if the user has given no 
indication of preference*, the spelling checker should be on or off.


> (That aside, you can't rely on user-side validation anyway. You need to 
> do that server-side, after the data has been submitted. Thus by allowing 
> authors to state that a spellchecker must be on, you could end up in a 
> stupid 'loop' when the spellchecker guides the user to do one thing, and 
> the server wants another thing.)

For spelling, that seems unlikely. In general, though, authors have voted 
with their feet in favour of having client-side prechecking (in addition 
to the security-required server-side postchecking).


On Fri, 23 Jun 2006, Sander Tekelenburg wrote:
> 
> 	[AUTHOR REQUIREMENTS]
> 
> > Authors should set the document's language information, to enable user 
> > agents to accurately determine which dictionary to use when checking 
> > the spelling or grammar of user input.
> 
> IMO this "should" should be a "must".

What about if the author doesn't know the language?


> > IMPLEMENTATION REQUIREMENTS
> >
> > All elements can have spellchecking enabled or disabled. UAs may allow 
> > the user to set this flag
> 
> Why "may"? Why not "must"? Given that the argument for the spellcheck 
> attribute appears to be "to aid users"... If you allow user-agents to 
> implement a spellcheck attribute the user has no control over, you're 
> handing control to authors. That's generally a bad idea on the Net, but 
> it's especially bad in a case like this.

Because you can't require a particular UI. For example, the UA could be a 
kiosk-style system, where the user is not to have any ability to do 
anything but enter his text and hit submit.


On Sat, 24 Jun 2006, Alexey Feldgendler wrote:
> 
> Even worse: when entering text in textarea, the user actually has a 
> choice which language to write in. I think the user agent should 
> provide, besides just the control to turn spellchecking on and off, a 
> choice of languages.

Agreed.


On Fri, 23 Jun 2006, Lachlan Hunt wrote:
> 
> I don't particularly like giving the authors any control over spell 
> checking. For the majority of cases, I think browsers should become 
> smart enough to know whether or not to enable/disable spell checking 
> without any explicit author input, based on various heuristics (as I've 
> written about before [1]).  In other words, for most cases, authors 
> should not need to use this attribute.

The request for this attribute came from a UA in the first place. This 
would seem to suggest they can't find a way to be smart enough, and would 
like author input.


> > UAs may allow the user to set this flag, and may have defaults that 
> > vary based and various heuristics or user preferences.
> 
> That's good, but it really should be a *should* or a *must*.

See above.


> > Ok, so how can we ensure that spell checking is enable for GMail's To: 
> > line but enabled for its Subject line?
> 
> Ordinarily, <input type="email"> would handle no spell checking for 
> email addresses, but given that Gmail uses a textarea that contains both 
> people's names and email addresses, that may be one case where 
> heuristics may not give optimal results.

Indeed. So how should we do it, if not using an attribute to hint to the 
UA whether it should be enabled or not?


> If it were just e-mail addresses, it wouldn't particularly matter 
> because spell checkers can already recognise e-mail addresses and not 
> mark them as errors.  But in this case (and others like it), the user 
> should be able to very easily disable spell checking and have the 
> browser remember that preference.

This would give a bad experience for the user until the user learnt how to 
turn off spell-checking. This isn't really acceptable to authors of 
applications like GMail.


> Do you think that that one small use case is strong enough to warrant 
> the use of a spellcheck attribute?

Here are other use cases:

   google.com home page:
     would like spellchecking enabled for the field.
   google.com accounts pref page:
     would like spellchecking disabled for all fields.
   GMail:
     would like it enabled for the search field, disabled for the invite 
     and contact boxes, disabled for contact search, enabled for subject 
     and e-mail body, disabled for the To:, Cc: and Bcc: fields, enabled 
     for the Event: field, enabled for the Where: field, disabled for the
     date fields, enabled for the Event Description field, disabled for
     the guest list field, disabled for the first two filter search 
     options, enabled for the others...

...the list goes on. Similarly for all the other Web applications out 
there. Half the fields need it on, the other half off, and I really can't 
see much that a UA could use to work out which it should be in each case.


> Roughly what percentage of all use cases would you expect heuristics and 
> user preferences to give suboptimal results, and thus require the 
> author's suggestion?

A lot. (I haven't looked at this carefully, but the Mozilla trunk's 
current heuristics get just under half of the ones I mentioned above 
correct, which is far too low a rate for users to be happy.)


> Is it really a major usability issue if a browser enables spell checking 
> for a field where the user wouldn't want it, considering it can be 
> easily disabled (or vice versa)?

Yes, IMHO. (Your definition of "easily" is not mine, though.)


> For contenteditable use cases, roughly what percentage of them would 
> need the author to turn on or off spell checking?  Given that the user 
> can add semantics to their content using elements, browsers should be 
> able to enable and disable spell checking for different sections.  e.g. 
> if a user starts entering <code> into a contenteditable section, UAs 
> should be able to automatically disable spell checking for that content, 
> while still checking the surrounding text.

I don't have any data on this.


On Sat, 24 Jun 2006, Alexey Feldgendler wrote:
> 
> IMHO we should not rely on unspecified heuristics. In some browsers, 
> they work rather well, in some they might constantly fail. Leave 
> heuristics for invalid pages, quirks mode etc -- or document these 
> heuristics.

In general I agree, but for spellchecking I don't know what we should 
document, exactly.


On Sat, 24 Jun 2006, Lachlan Hunt wrote:
> 
> Generally, that's true.  But since spell checking is only a user agent 
> feature intended for the user (it doesn't affect the page or author in 
> any way) and interoperability between one browser's heuristics and 
> another is not required. Browsers should be allowed to innovate as much 
> as they like so they can come up with the best method that suits their 
> users.

I agree.


On Sat, 24 Jun 2006, Alexey Feldgendler wrote:
> 
> Once again, a CSS/XBL based approach would be better here. Unless 
> something is specified explicitly, the user agent can implement any kind 
> of logic in its default rules.

I'm not really sure how this would differ from just having spelling have 
UA default rules in the absence of the author's attribute.


On Sat, 24 Jun 2006 mail at jorgenhorstink.nl wrote:
>
> I've read this discussion,but i do not understand exactly why this 
> should be denoted in markup.i do not understand why it is needed 
> anyway.is the lang attribute not sufficient? what about denoting every 
> paragraph in a document should be spellchecked,and denoting every del 
> not? what do spellchecking attributes say about the structure of the 
> document?why not let the browser vendors determine what suites their 
> needs on this issue.

In general I'd agree, but since the entire discussion here was spawned by 
one such browser vendor saying "we need a way for authors to control 
this!", I would suggest that browser vendors have determined that they 
need a way for authors to control this. :-)


On Sun, 25 Jun 2006, Anne van Kesteren wrote:
> 
> May be I wasn't clear. I was not proposing more properties to CSS. 
> Having a separate language that can take care of the more behavioral 
> things that are easily expressed.

I've often been tempted to go there, but I fear most authors would just 
find this very confusing. Authors have enough trouble just understanding 
the separation of CSS and HTML.


On Fri, 23 Jun 2006, L. David Baron wrote:
> 
> The problem with heuristics is not that they might be better in some 
> browsers and worse in others.  The problem is that heuristics are only 
> heuristics when they operate on input written without knowledge of the 
> heuristics.  When the input was written with knowledge of the 
> heuristics, they become de facto standards.
> 
> In other words, authors will figure out what the heuristics are and then 
> write markup to match the heuristics rather than to match the semantics 
> of their content.  Authors will learn what triggers spellchecking (or 
> not) in Mozilla, and write whatever markup, however inappropriate, gives 
> the choice of spellchecking that they want.  Then other browsers will be 
> forced to copy whatever Mozilla did.
> 
> So if we're going to end up with a standard anyway, why not admit it and 
> figure out what it should be rather than ending up there accidentally?

Indeed.


On Sat, 24 Jun 2006, J. Graham wrote:
> 
> Only if copying whatever Mozilla do provides a significant improvement 
> in usability for the users of those other browsers.

You'd be surprised how small a difference there needs to be for authors to 
consider it significant enough.


> The best reason I see to implement a specific attribute (or other 
> mechanism) to control whether spellchecking is enabled or disabled on a 
> particular control is to prevent abuses of e.g. the accept attribute so 
> that authors use text/plain in order to enable spellchecking in Mozilla 
> but, in doing so, break e.g. syntax highlighting in some future version 
> of Konqurer which relies on a correct value for @accept. However I 
> believe the implementation of any such attribute should be optional (as 
> in "a UA MAY implement a spellckeck attribute to allow spellchecking to 
> be enabled or disabled on an element"), but, if it is implemented, 
> allowing the user to override the author should be a MUST or, if that is 
> seen as being too dictatorial about UI, at least a SHOULD requirement.

Indeed, there's no way the spec will _require_ support for spellchecking.


On Sun, 25 Jun 2006, Lachlan Hunt wrote:
> 
> The main problem with providing an explicit spell checking switch to the 
> author is the potential for abuse.  History has shown that authors will 
> attempt to disable anything they don't like for any reason whatsoever, 
> regardless of the usability benefits such features provide for users.

Indeed, users should always be able to override an author's "disable 
spellchecking" hint.


> We've seen that already with all of the following:
> 
> * IE's smart tags: <meta name="MSSmartTagsPreventParsing" content="True">
> * Google AutoLink (Some scripts were developed to workaround this)
> * IE's image toolbar: <meta http-equiv="imagetoolbar" content="no"> and <img
> gallery="no">)
> * AutoComplete (autocomplete="off")
> * Context menus (JavaScripts intercepting right click)
> * Showing link URLs in status bar (using window.status)
> * Removing browser chrome (in popups)
> * View Source (includes attempts to obfuscate source code with JS, disabling
> context menus, etc.)
> * Disabling printing (Some JS, works in IE only)
> * Disabling Save As..., (Some JS, works in IE only)
> * Disabling caching
> * And anything else they can get their grubby little hands on!

A very good point.


> I'd like to see some research done to find out exactly what kinds of 
> input authors use <input type="text">, <texarea> and contenteditable 
> for, beyond those already mentioned earlier in the thread.  I'd also 
> like to see research into the <label>s, name="", id="" and other 
> identifying information, commonly given to such fields, which can be 
> used for developing heuristics.

Could you elaborate on exactly what kind of research you mean?


On Sun, 25 Jun 2006, Matthew Paul Thomas wrote:
> 
> But realistically, browsers won't "allow the user to easily override it 
> if they want to", because any interface for doing that would be absurd. 

The interface would just be a checkable context menu item "Check 
spelling", which initially is in the author-hinted or UA-default state,
but which, once set, persists for that field. Why is that not enough?


> Bottom line, browser vendors will either ignore the attribute, or 
> they'll make it configurable in a really obscure place (about:config or 
> equivalent), and leave 99.9% of people wondering vaguely why 
> spellchecking works on some pages and not others.

It should be noted once more that the existence of this discussion is 
directly related to a request from the Mozilla guys for how they can 
provide for authors to give a hint, while still leaving users firmly in 
control.


On Sun, 25 Jun 2006, Lachlan Hunt wrote:
> 
> I'm starting to think we just need to define the attribute in a way that 
> is semantic, and possibly come up with a new name to match.  And also 
> give non-normative guidelines about how other attributes may be used to 
> improve the logic.  For instance, the attribute could be defined like 
> this:
> 
> | The |on| value indicates that the expected user input will
> | primarily comprise natural human language.  The off value
> | indicates that the expected user input will not.  If the
> | attribute is not specified, user agents are free to use any
> | algorithm they like in order to determine the type of the
> | expected user input.
> |
> | User agents may use this to determine whether or not to
> | provide spell checking for the content by default.  User
> | agents should provide a way for the user to override this
> | decision.

That's certainly an interesting way of doing it. However, especially 
considering contenteditable, I think it's important that we define it in 
more detail than that. Inheritance, in particular, is key here.


On Tue, 27 Jun 2006, Matthew Paul Thomas wrote:
> 
> Perhaps a useful analogy: HTML5 is about making Web applications easier, 
> and in Web applications dataloss often results from going back to 
> previous pages, so there should be a backbuttonallowed= attribute that 
> can be set to "false" for the <html> element. And we'll let the user 
> easily override it if they want to.

There are better ways to address this (such as the first draft of session 
history stuff now in the spec).


On Mon, 26 Jun 2006, Gervase Markham wrote:
>
> Alexey Feldgendler wrote:
> > Check spelling:
> > ( ) Never
> > (*) As the page author suggests
> > ( ) Always
> 
> But that really brings out the foolishness of the idea. I can imagine a 
> user looking at that option and thinking "Duh - how on earth is the page 
> author ever going to know when and how I want spelling checked?"

Well, the author wrote the page, he's the first person who _would_ know 
whether or not the field is likely to be one where one wants spelling to 
be checked.


> What use cases did we come up with where there might be a <textfield> or 
> <textfield type="text/plain"> where having spell checking always on 
> would cause problems? Surely the worst that could happen would be some 
> inappropriate red squiggly underlines. Hardly a disaster.

Enough of an annoyance, apparently, that your team's developers want to be 
able to let authors turn it off.


On Mon, 26 Jun 2006, Gervase Markham wrote:
> 
> How about a scheme where the UA never spellchecks <input type="text">? 
> Those who have sufficient trouble with spelling a single sentence (the 
> subject line) can right-click and choose "Check Spelling"?

There are surprisingly many one-line text fields where spelling checking 
would be desired, and in many cases they occur in batches. It would be a 
pain to check each one.

Also, I have the same trouble spelling a single sentence as I do spelling 
a single sentence that is part of a bigger block of text. I don't see why 
the number of sentences matters.


> If this whole attribute rigmarole is merely about trying to distinguish 
> between an <input type="text"> containing email addresses and one 
> containing a subject line, then it seems like a storm in a teacup to me. 
> Either people have to manually request it for subject lines, or the 
> email addresses get red squiggly underlines - deal with it. :-)

People want it to happen automatically (by author hinting), and frankly I 
see no reason not to allow that. What's the harm?


On Mon, 26 Jun 2006, Matthew Raymond wrote:
> > 
> > So Google is using a <textarea> for email addresses.
> 
> They can work around this by using the repetition features in Web
> Forms 2.0:

Well, we could, but in general I think we prefer free-form text input for 
this kind of thing.


> Are email addresses common enough for an "email" type??? They seem 
> pretty common to me, but we might be overloading the |type| attribute a 
> bit if we add a new value that's so close to being text. Also, that 
> doesn't help the above scenario, because I think Google allows names 
> from an address book in the place of addresses.

...and as noted higher up in this e-mail, it's just one example out of 
many.


On Fri, 23 Jun 2006, J. King wrote:
> > 
> > Ok, so how can we ensure that spell checking is enable for GMail's To: 
> > line but enabled for its Subject line?
> 
> If we are to assume that the first "enabled" is supposed to read 
> "disabled", wouldn't this be a simple, intelligent way of doing it?
> 
> <label>To: <input type="email"></label>
> <label>Subject: <input type="text"></label>

The To: line in GMail takes more than one address. It also takes names, if 
the name is in the address book.


On Fri, 23 Jun 2006, Anne van Kesteren wrote:
> > 
> > Ok, so how can we ensure that spell checking is enable for GMail's To: 
> > line but enabled for its Subject line?
> 
> By having something like type="email" for multiple e-mail addresses? (Or 
> reusing type="email" in some way would work as well I suppose.)

The To: line in GMail takes more than just addresses.


On Fri, 23 Jun 2006, Michel Fortin wrote:
> 
> Maybe having the possibility to set the lang attribute to a value 
> meaning "not a language" would be enough to disable spellchecking when 
> the content isn't a human language. And if you want to explicitly tell a 
> field to use spellcheck you'd use any valid language code, or the empty 
> string which currently mean unknown language. Would this make sense?

While that does make sense, it would break another major use case for 
lang="", which is letting screen readers know what language to base their 
reading on. English names are in English, even if they aren't in the 
dictionary. Similarly, Perl should be read as English, even though it 
isn't English by anyone's definition.


On Fri, 23 Jun 2006, Matthew Raymond wrote:
> 
> First of all, a |spellcheck| attribute, as conceived, is inconsistent 
> across web sites. An address input should have the same spell check 
> settings on every web page I go to, regardless of what the author wants.

Fair enough; how would you do this?


> If you use |spellcheck| as an initial hint, then the first site you 
> visit will determine the settings for all other sites that use the same 
> input fields. This may or may not be desired. It would be nice for 
> authors to be able to provide hints for spell checking in rarely used 
> fields, but I don't see that as being the primary use case.

I think the "long tail" of input field types works against us in this 
case.


> Also, having a boolean value for spell checking prevents further 
> innovation down the road. For instance, if you're writing a script in a 
> <textarea>, you may want it to only spell check comments and quotations, 
> so you'd want to have an attribute value for this kind of spell 
> checking. Then again, it may be your intent for |spellcheck| to be used 
> in combination with |accept|. Is that the idea?

This hasn't really come up yet. It certainly would be something to 
consider in the future.


> Another problem is |pattern|. Any spell checking mechanism will have to 
> conform to the pattern value provided, which means either a really 
> creative spell checking algorithm or turning spell checking off. I think 
> the latter is probably the best idea, but it probably shouldn't be 
> "must".

That's up to the UA, IMHO.


> Overall, I think |accept| and UA spell checking settings that are tied 
> to |name| or |class| eliminate most use case for |spellcheck|.

That sounds a little too unpredictable to me, given the arguments that 
were raised against accept="".


On Sat, 24 Jun 2006, Alexey Feldgendler wrote:
>
> On Thu, 22 Jun 2006 23:04:51 +0700, Ian Hickson <ian at hixie.ch> wrote:
> 
> > All elements can have spellchecking enabled or disabled. UAs may allow
> > the user to set this flag, and may have defaults that vary based and
> > various heuristics or user preferences. Spellchecking can be enabled
> > on an element while its children have it disabled. However, by
> > default, user agents should enable spellchecking for an element if it
> > is enabled for its parent element and not explicitly disabled for the
> > child.
> 
> Do you mean that there should be some inheritance rules? They are not
> described in your algorithms.

I'll fix that, thanks.


On Sat, 24 Jun 2006, Matthew Raymond wrote:
> 
>    I might be persuaded to allow an author to specify whether or not to 
> enable spell checking in the event that the user has not specified the 
> setting themselves for a specific type of input field. However, if, for 
> instance, you enable spell checking for address fields, the author 
> should not be able to turn it off. Furthermore, the user shouldn't have 
> to know CSS or HTML in order to configure spell checking preferences.

Sure.


On Sun, 25 Jun 2006, Andrew Fedoniouk wrote:
> 
> Spellchecker looks like pure behavioral entity.

I'm not sure what this means.


> So I would define this as:
> 
> <style>
> #myeditor
> {
>    white-space:pre; overflow: auto; ...
>    behavior: textarea spellchecker;   /* textarea editor and spellchecker */
> }
> </style>

I disagree that it is stylistic, for the reasons given earlier in this 
e-mail.



Here's a new proposed spec:


AUTHOR REQUIREMENTS

Elements may have a new attribute specified, "spellcheck".  If
specified, it must have either the value "on" or the value "off"
(exactly, case-sensitive). The "on" value indicates that spellchecking
is to be enabled, the "off" value indicates that spellchecking is to
be disabled. The attribute is inherited. By default, the UA and user
preferences decide if spelling checking is enabled.

There is also a "spellcheck" DOM attribute on all elements that may be
used to quickly set the value of the content attribute dynamically, or
to check the default value for an element.

Authors should set the document's language information, to enable user
agents to accurately determine which dictionary to use when checking
the spelling or grammar of user input.


IMPLEMENTATION REQUIREMENTS

The HTMLElement interface has one new DOM attribute:

  attribute boolean spellcheck;

On getting, the "spellcheck" DOM attribute returns a value as
determined by the following algorithm.

 * If the element has a "spellcheck" content attribute with the exact
   literal value "on", then the DOM attribute must return true.

 * Otherwise, if the element has a "spellcheck" content attribute with
   the exact literal value "off", then the DOM attribute must return
   false.

 * Otherwise, it must return the UA default value for that element.
   Note: This might not reflect the actual spellchecking state, because
   the actual spellchecking state depends on the parent element's
   spellchecking state if the content attribute is missing, as well as
   on the user's preferences.

The the DOM attribute is set, the element's "spellcheck" content
attribute must be set to the literal value "on" if the attribute is
being set to the "true" value, and "off" otherwise.

To determine if a word, sentence, or other piece of text is to have
spelling and/or grammar checking enabled, the UA must use the
following algorithm:

 1. If the text in question is the value part of an input element or
    textarea element, and that element is disabled or readonly, then
    the checking is disabled.

 2. Otherwise, if the text in question is part of a text node or
    attribute that is not user-editable, then the checking is
    disabled.

 3. Otherwise, if the user has disabled the checking for this text,
    then the checking is disabled.

 4. Otherwise, if the user has forced the checking for this text to
    always be enabled, then the checking is enabled.

 5. Otherwise, if the element with which the text is associated has a
    "spellcheck" content attribute, then: if that attribute has the
    literal value "on", then checking is enabled; otherwise, if that
    attribute has the literal value "off", then checking is disabled;
    otherwise, move on to the next step.

 6. Otherwise, if the element with which the text is associated has an
    ancestor element with a "spellcheck" attribute set to one of the
    literal values "on" or "off", then, if the nearest such ancestor
    has its attribute set to the literal value "on", then checking is
    enabled; otherwise, if the nearest such ancestor has its attribute
    set to the literal value "off", then checking is disabled;
    otherwise, move on to the next step.

 7. The UA default for this element must be used. The UA default can
    vary based on heuristics.

For text that is part of text or CDATA nodes, the element with which
the text is associated is the element that is the immediate parent of
the start of the word, sentence, or other piece of text. For text in
attributes, it is the element with which the attribute is
associated. For text in text fields, it is the relevant input or
textarea element.

Examples:

   The element with id "a" in the following example would be the one
   used to determine if the word "Hello" is spell-checked. It this
   example, it would not be.

      <div contenteditable="on">
        <span spellcheck="off" id="a">Hell</span><em>o!</em>
      </div>

   The element "b" in the following example would have spell checking
   enabled (not disabled, because of the leading " " character, and
   not the UA default, because the grandparent explicitly enables it).

      <p spellcheck="on">
       <label>Name: <input spellcheck=" off" id="b"></label>
      </p>

If the checking is enabled for a word/sentence/text, the UA should
indicate spelling and/or grammar errors in that text. UAs should take
into account the other semantics given in the document when suggesting
spelling and grammar corrections. UAs should use the language of the
element to determine what spelling and grammar rules to use. (Language
information can come from the "lang" and "xml:lang" attributes,
Content-Language HTTP headers, or other sources. q.v.) UAs should use
input element attributes such as pattern to ensure that the resulting
value is valid.

If spellchecking is disabled, the UA should not indicate spelling or
grammar errors for that text.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'