[whatwg] Spellchecking mark III

[Calogero Alex Baldacchino]

Peter Kasting ha scritto:
> On Wed, Jan 21, 2009 at 7:38 PM, Calogero Alex Baldacchino 
> <alex.baldacchino at email.it <mailto:alex.baldacchino at email.it>> wrote:
>
>     Why not to let the user choose the language, as it happens in word
>     processors? A UA can't choose accurately whether, for instance,
>     "color" is a correct American English, a wrong British English, or
>     even a correct (truncated) Italian word, while a human can do it
>     better, thus a UA could provide an interface to change the
>     language for a selection spellchecking, or even for each mispelled
>     word, starting from a hint language, which could be the value of
>     an element "lang" attribute (beside a default value and a
>     user-preference "forced" one - the latter bypassing any authored
>     value). Also, using the "lang" attribute value as the start
>     language to check (if not in contrast with a user preference)
>     would allow an interactive interface with a script changing that
>     value according to a user's choice (UAs could also expose a list
>     of supported languages).
>
>
> I'm not sure I fully grasped everything here, but what I did grasp 
> sounds very much like a cross between what Chromium is doing today and 
> what we want to do in the future (I imagine similar things are true 
> for other browser vendors).  User specification and page hints are 
> both useful tools for a UA.
>
> But I still claim that all of those aspects are outside the scope of 
> the "spellcheck" attribute, and fall into the realm of "things that 
> should not be in the HTML5 spec" as they're very much UA-specific 
> behavior.
>
> PK

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 think that a control over the language to check can improve 
spellchecking at the same grane as the spellcheck attribute, whereas it 
can't harm end users more than a wrong assumption on spellchecking. A 
user would notice a wrong checking not matching the language he's using, 
and could disable it or do whatever else a UA allows him to do (though 
being annoying); on the other hand, a user might not notice 
spellchecking is disabled on a certain area, and could not beware his 
errors, unless the UA informed him somehow (about spellchecking being 
turned off). Therefore, a special care by UAs is needed in both cases, 
yet both features can improve webapps providing a rich and/or 
specialized editor (such as a code editor, where disabling spell 
checking but for comments may make sense), so why not consider both of 
them, since they're related?

Also, implementation and usages experience could suggest whether it is 
worth to expose UAs' supported languages through DOM APIs (e.g. to allow 
a webapp to create a dynamic list of checking-available languages, to 
avoid static lists being either incomplete, or too long and possibly 
including unsupported languages), and this would affect either the 
Window or the Navigator interface (or something else in HTML5 scope).

Everything, IMHO.

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 Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8547&d=22-1