[webkit-dev] Newline translation issue with textareas

Darin Adler darin at apple.com
Mon Jun 20 13:07:53 PDT 2005


On Jun 20, 2005, at 1:00 PM, Kevin Ballard wrote:

> 1) We translate the text whenever it gets set from anywhere so that  
> all line endings are \n. This has the benefit of making the cursor  
> position and selection accessors much easier to write, since the  
> internal text storage is the same as what's exposed to the outside.  
> However, this has the problem of requiring translation on all the  
> different ways text can get into the NSTextView
>
> 2) We translate text set up in HTMLTextAreaElementImpl whenever  
> it's set from there (or we force a updateFromElement and then  
> invalidate the cache so that the next access will get it from  
> KWQTextArea). This has the benefit of being pretty easy to do, with  
> the negative of requiring the cursor position and selection  
> accessors to be aware of \r\n sequences and treat them as a single  
> char
>
> 3) We stop translating the text. This is probably not desired,  
> because at least Firefox always translates \r\n sequences to \n (I  
> don't have any way to test WinIE) and compatibility with other  
> browsers is a good thing. Given that, I'm not actually aware of any  
> spec that says line endings should be coerced to \n.

I like (1) best long term. But I think it's fine to do (2) first.  
It's likely we'll be reimplementing <textarea> to use HTML editing  
rather than QTextEdit some time soon anyway, so we can take care of  
(1) at that point.

     -- Darin




More information about the webkit-dev mailing list