[whatwg] Spellchecking mark III

[Calogero Alex Baldacchino]

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 <mjs at apple.com 
>> <mailto:mjs at apple.com>> 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