[webkit-dev] Newline translation issue with textareas
kevin at sb.org
Mon Jun 20 13:25:42 PDT 2005
On Jun 20, 2005, at 4:07 PM, Darin Adler wrote:
>> 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
> 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.
Ok, sounds good.
In terms of actually doing #2, I would suggest that forcing an
updateFromElement and then invalidating the cache is the best way to
do it, so we don't have the translation happening in 2 different
places. However, I'm not sure about actually implementing this, since
I'm not really familiar with how it gets called in the first place.
When I looked at it, setting text in HTMLTextAreaElementImpl calls
setChanged(true), which basically just walks up the tree and tells
each element that one of its children has changed, yes? And then how
does that translate into an updateFromElement call later? Or, more
importantly, would there be any problem with simply calling
updateFromElement directly after the setChanged call, and then
setting m_valueIsValid to false so the next access will get the
translated value from KWQTextArea?
kevin at sb.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2378 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20050620/ebbb7723/smime.bin
More information about the webkit-dev