[Tickets #11863] Re: HTML format breaks

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/11863
------------------------------------------------------------------------------
  Ticket             | 11863
  Updated By         | scott at troutnet.org
  Summary            | HTML format breaks
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


scott at troutnet.org (2012-12-12 02:14) wrote:

Hm.  Yes, I'm replying via HTML.  HTML formated email is the  
contemporary standard.  You may ignore this bug but solving it should  
be extremely simple.  The spell-check-on-send feature just needs to  
render the html content before spell checking, which would even work  
in the example you provided.  But if you and the rest of the Horde  
staff prefer to market your product exclusively to users who use only  
plain ASCII emails, I wish you luck.  It's not 1992 anymore.

Actually, the spell check on send itself is a pretty stupid feature  
since the advent of SCAYT (spell check as you type),which I have yet  
to figure out how to enable in Horde.  I'm feeling like I need to make  
my own webmail client (lol?)

Cheers

>> This bug may seem a low priority but due to the nature of email
>> conversations and the continuous back and forth replying, emails
>> quickly fill with  a tremendous amount of junk.
>
> So you are 1) replying via HTML and 2) then doing spellcheck on this  
> replied message?  That seems extremely un-useful.
>
> First, you are going to be catching spell errors in the original  
> message (which are irrelevant).  And its doubtful that all  
> misspelled words will be caught (and there will probably be false  
> positives) since it is pretty much impossible to determine discrete  
> "words" in HTML data.  For example:  
> <span>t</span><span>e</span><span>e</span><span>s</span><span>t</span>.   
> Boom: there's a misspelled word (teest) that won't be caught.
>
> You are right: this shouldn't be low priority, this should be zero  
> priority.  In fact, thinking about this... we should probably  
> totally disable spellchecking for any HTML data NOT created via IMP.  
>  That's the only way of guaranteeing some semblance of acceptable  
> spellchecking performance.