[whatwg] Spellchecking mark III

[Sander Tekelenburg]

At 23:56 +0000 UTC, on 2006-06-29, Ian Hickson wrote:

[...]

> 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.

Agreed.

[...]

> On Thu, 15 Jun 2006, Sander Tekelenburg wrote:
>>
>> [...] 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.

I don't see how allowing authors to abuse one thing is an argument to give
them more things to abuse :)

I'm well aware that *everything* can be abused, but when something is useful
enough then its potential for abuse is a downside you choose to live with.
When something is not useful enough, the abusability argument should win.

[...]

> 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?

Of the user input you mean? Good point. But then what if a page is in english
but accepts input in any language? The author should still indicate the
content's language, thereby triggering the wrong spellchecker for those who
wish to input text in another language. In turn, the result may well be that
authors set no lang attribute at all for the page. Surely a spec shouldn't
push authors in that direction?

A solution might be to make this a *must* and allow lang="*", so the author
can state lang="en" on the body, and lang="*" on the input field. I still
seriously doubt authors will use this as intended though...

>> > IMPLEMENTATION REQUIREMENTS
>> >
>> > All elements can have spellchecking enabled or disabled. UAs may allow
>> > the user to set this flag
>>
>> Why "may"? Why not "must"? [...]
>
> 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.

Good point. But if I'm not mistaken HTML 4.01 already says that some things
do not apply to UAs that can't implement them. I think you should at least
change this to a "should", and add a note to the spec that explains that this
means user-agents that can should, and only those that can't are excused.

(To be clear: my argument is that the spec should do its best to avoid giving
user-agents an excuse to not bother giving the user (easy) control.)

[...]

> 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.

Not meaning to be disrespectful, but "can't" suggests it's simply too
difficult technically, while it could just as well be that they prefer to
take the easier way out, for instance because they can't afford spending the
necessary resources on this. That can be a perfectly valid argument for an
individual browser vendor, but it's hardly a solid basis for a HTML spec.
Especially when the request comes from a single browser vendor and everybody
else seems to see more problems than benefits.

[...]

>> > 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?

I can't follow this. If a site uses 2 types of content within the same field
and wants one of those types to be spellchecked, and the other not, how is a
|spellcheck| attribute going to help? They'll need to split those 2 types of
content into 2 different fields.

(That aside, I don't see how users would have a problem with spellcheckers
indicating spell errors on email addresses or names. Surely they're already
used to ignoring that.)

[...]

> 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. :-)

I don't understand how from 1 browser vendor saying they need it you reach
the conclusion that browser vendors need it. Especially when (AFAIK) the only
other browser vendor expressing an opinion here doesn't sound very positive:
"I think it's totally inappropriate for a Web page to have any control over
spell checking settings." (Maybe Dave really meant *control* and would be
happy to implement something that accepts author suggestion while leaving the
user in control, but to me his "any" suggests otherwise -- which makes sense
to me, as one of Safari's strengths is its bare-bones UI and configurability.)

[...]

> On Fri, 23 Jun 2006, L. David Baron wrote:

[...]

>> 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.

I don't see how |spellcheck| solves that. Won't |spellcheck| simply be even
easier for them to trigger inappropriately and thus likely to be triggered
inappropriately even more often?

[...]

> 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.

What do you mean with "that field"? That specific field or that sort of
field? And what sort of persistence? Should UAs remember the setting for
specific fields in specific webpages so they can apply that same state the
next time the user visits that page? Or just until the next page is loaded,
or (part of) the same page's content is changed (through AJAX or whatever)?

[...]

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

Potential author abuse (in combination with users not being able or
understanding how to regain control).

Author abuse is one of the main problems of today's Web. Abusing TABLE for
non-tabular data, abusing CSS to convey meaning, etc. I don't see why
|spellcheck| won't simply be the next item on that list. (Sure, the potential
for abuse alone is no reason to outlaw something, but to spec it there should
be some very strong positive arguments. I see those for TABLE and CSS.)

[...]

> 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.

I would change that to "The "on" value requests that spellchecking be
enabled, the "off" value requests that spellchecking be disabled."


     +++++

My feeling is that a much more useful way to go about this is for UAs to
provide users with an easy way to persistently overrule their spellchecker's
default state on a per field per page basis -- that the UA remembers the
user's preferences for that specific field on that page when it is visited
again. You would need that anyway to ensure users have both intelligent
spellchecking and true control over authors' |spellcheck| values.


-- 
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>