[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