Peter Kasting ha scritto:
On Wed, Jan 21, 2009 at 7:38 PM, Calogero Alex Baldacchino
<alex.baldacch...@email.it <mailto:alex.baldacch...@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
