[whatwg] Spellchecking mark III

[Calogero Alex Baldacchino]

Kornel Lesiński ha scritto:
>> Probably. However, establishing that the "lang" attribute is the 
>> "first-choice" language to check (which wouldn't prevent the UA from 
>> providing other choices, or just ignoring such behaviour due to a 
>> user preference, or using other dictionaries too -- and that might be 
>> suggested in a note on usability, I guess), I mean, would allow a 
>> webapp to emulate those functionalities to some extent, just setting 
>> a different value for the lang attribute of a contenteditable box and 
>> some of its subregions through a script at the user whim (that is, 
>> let's do it through script until UAs provided a better solution, 
>> which could be hinted by scripting hacks based on the "lang" and 
>> "spellcheck" attributes working together at the same grane).
>
> I don't think that applications need ability to precisely control 
> spell-checking language. Browser knows best which dictionaries are 
> available, and can auto-detect language based on user's preferences, 
> page's language and text itself. You can expect that browsers will 
> have much more sophisticated and reliable language detection than web 
> apps (that's an area where browsers can freely compete).
>

Browsers can't do better than word processors, which are the state of 
the art in... word processing. At most, browsers can do as well, and, 
over some extent, word processors don't use heuristics while you're 
typing, because no heuristics can guess whether you're *purposedly* 
switching between dialects (such as British and American English), or if 
you just mispelled a word (personally, I dislike even the automatic 
correction of common mistakes in w.p.). Word processors make a choice 
when you start writing (or before, basing on your installation language, 
for instance), and let you change it for the whole document or for each 
single word. I don't think any heuristic auto-detection can be better; 
instead, no language detection (and users' explicit choice) is more 
reliable than any sophisticated heuristics.

Turning spelling checking on or off makes sense if one can guess how the 
user agent would behave AND if the user agent can recover misuses, thus 
I believe that "spellcheck" is strictly related to the way a 
spellcheking language is detected and is half of the problem of 
controlling spellcheking. Otherwise, if it's thought that everything 
should be under the control of a UA, let's state spellchecking must be 
always on and peace. Just because being annoyed by a wrong checking 
(e.g. because the heuristics fails, but it would be the same for a wrong 
lang value) is less harmful than thinking one's writing correct text 
because of being unaware that checking has been disabled by the author 
without asking one's permission. Yet, both "lang" and "spellcheck" 
attributes can be useful for the purpose of controlling spellchecking 
and improving a web-based word processor, and in both cases UAs can 
recover from misuses, somehow (e.g. allowing the user to bypass authors' 
choices).

Moreover, I think that interactive and script-aware UAs should act as a 
framework for web-based applications providing as much of a client-only 
application functionalities as possible, thus browsers should include 
new features when possible and reasonable (while trying not to became 
oversized). I agree that spellchecking is a good feature to support in a 
browser; I don't see why a web-based rich text editor should be 
prevented from controlling it on users' behalf, as it happens in word 
processors, givent it's about to support an existing attribute ("lang", 
which could be stated to be triggering UAs heuristics by default when 
unspecified for editable elements) and a new one ("spellcheck") in 
conjunction for this purpose (also a list of supported dictionaries 
would be useful).

I also think that features which are not "core" functionalities for a UA 
should be provided in a basic version (for general use in web pages) and 
as building blocks for web applications, not in a complete version under 
a UA exclusive control (for instance, a UA could allow the user to 
change the language for some selected text through a context menu 
option, but the right place for an option allowing a (starting) choice 
valid for a whole editable element, in a rich text editor, should be the 
editor interface, which shouldn't be provided by a UA, as a whole or in 
part, or, if the UA provides it, it should be exposed to any webapp to 
be customized and enhanced). That's because a specific application can 
focus on a specific task usability better than its underlying, "general 
purpose" framework (like a browser is or should be for a web application).

Furthermore, if you agree that a page's language should be used to 
improve auto-detection, why not to use an element language attribute 
too? With the benefit that it can be changed dynamically to please the user.

> Many of your suggestions are just implementation details, which HTML 
> shouldn't specify precisely (it could force browsers to use method 
> that is suboptimal). HTML just needs to offer reasonable way to 
> implement good heuristics, and I think existing lang, input types and 
> spellchecking attribute are sufficient.
>

Hmm, I thought I was discussing the opportunity to dynamically change a 
spellchecking language for an editable element basing on the element's 
dynamically changed lang attribute, and trying to explain why it's 
related to the problem solved by "spellchek" (I think that's the other 
half of the same problem) and why that's no more harmful, if misused, 
than a misused "spellcheck", and how UAs could maintain usability in 
case of wrong "spellcheck" and "lang" values (I didn't wanted to suggest 
implementation details as an "active" part of the specification, but at 
most as non-normative hints to point out possible usability issuses 
arising from this approach, and possible related solutions - 
non-normative hints shouldn't force suboptimal implementations, unless 
any non-heuristic approach is considered suboptimal, but I strongly 
disagree with such an assumption). Fault of my English.

Back to the point, as a user I don't like even thinking that "good 
heuristics" can make decisions on my behalf which I can't change. As a 
programmer, I think that any heuristics implementations should provide a 
mechanism to fall-back to users' explicit choices, and webapps should be 
allowed to handle such choices to enhance their usability.

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Con Meetic trovi milioni di single, iscriviti adesso e inizia subito a fare nuove amicizie
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8290&d=23-1