Maciej Stachowiak ha scritto:
On Dec 31, 2008, at 12:26 PM, Robert O'Callahan wrote:
On Thu, Jan 1, 2009 at 4:15 AM, Maciej Stachowiak <[email protected]
<mailto:[email protected]>> wrote:
2) The proposal Hixie linked seems way overengineered for this
purpose. First, it allows spellchecking to be explicitly turned
on, potentially overriding normal defaults, but that seems wrong;
an <input type="email"> should never spellcheck regardless of the
page author says. I can't see any valid use case for the author
turning spellchecking on regardless of UA defaults or user
preferences.
It allows you to have a region of text where spellchecking is
disabled via the spellcheck attribute, but containing subregions
where spellchecking is enabled.
It seems to me you would have to have a lot of custom code to maintain
the boundaries between such regions during editing operations for this
to ever work right. Normal text editing would easily lead to text
moving across the boundaries. There would have to be strong motivating
examples to justify such a hard-to-use feature.
Do you mean a lot of code for a UA or for a webapp developer? As far as
I can tell (and guess), in both cases one could make things easy, just
ckecking for mispelled words basing on where a bounch of text is pasted
in, using an element with a certain behaviour as a fixed boundary (as
when some text is copied and pasted from a box to another after the user
has disallowed, for some reason, spell checking for only one of them -
if allowed by the UA). As far as boxes are styled and described in order
to make it clear for the user what's going on (and the UA provides a
mean to bypass an author's choice -- as it happens when users don't
allow a script to intercept right clicks), that should work fine.
Otherwise, if a finer granularity in felt as necessary to correctly
implement such (e.g. to allow a user to modify a certain region
boundaries), I think that's not very different than changing a random
selection style in a rich text editor (= same algorithms might be used
to determine boundaries).
Second, it allows spellchecking to be controlled at a finer
granularity than editability, for which again I think there is no
valid use case. Both of these aspects make the feature more
complicated to implement and harder to understand, compared to
just having a way to only disable spellchecking at the same
granularity as editing.
A use case is editable program code, where spellchecking is disabled,
but where spellchecking is enabled inside comments. Maybe that sounds
a little far-fetched for today's Web applications, but some IDEs
(e.g. Eclipse) support this so it seems like something we'd want in
the future.
This sounds like a pretty ill-conceived feature. It is very common for
comments to include code, or fragments of code (such as variable
names) mixed with natural language. (I was unable to find any evidence
of spellchecking comments in the copy of Eclipse I downloaded, so I
can't comment on the details.)
Well, a few outlined words shouldn't be so bothering as (almost)
everything you write being marked as misspelled while writing one's
code... Anyway, either the editor interface or the UA (bypassing it)
might allow the user to change the default/authored behaviour at will,
thus one might first wright a comment, then enable spell checking to
verify no words other than code fragments are misspelled, and lastly
disable it to make any annoying underscore disappear.
Furthermore, a user might be allowed to turn off any checking for a
certain word (in its first occurrence, or for the whole document), as it
happens in wordprocessors when ignoring a misspelled term, and which may
be a natural evolution for UAs' spell checkers. Or, perhaps, a code
fragment might be put inside a further, unchecked subregion created by
mean of some option in the editor interface.
Furthermore, other IDEs generally don't attempt to do this, and I
can't think of other application categories that would do something
similar.
Well, historically IDEs didn't had a built-in spell checker, while
latest browsers do have, thus such might be or become a value added in a
web-based IDE, if used "cum grano salis".
However, I have no strong feeling for "spellcheck" vs "nospellcheck", as
proposed by Kornel Lesiński, I can see a few use cases for both, and
perhaps possible solutions to thecnical problems implementing them. I
think a bit of control over spell checking may be useful, and spell
checking might be worth to be takent into account by standards as a
feature going to be widespread in current and future web browsers. I
guess introducing such an attribute (or the alike) would have
consequences for styling, and perhaps influence CSS, for instance by
suggesting the introduction of a ":misspelled" pseudo element (or the
alike) to allow a proper styling of mispelled words (according to an
editable element style) -- though such might be proposed independently;
I'm just considering there are reasons to take spell checking into
account for web related standards, since browsers are implementing such
a feature.
Best regards and happy 2009,
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:
Prova il servizio di Email Marketing di Email.it, incrementi la visibilita'
della tua azienda e trovi nuovi clienti.
* Liste a partire da 10.000 contatti per soli 250 Euro
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8351&d=1-1
