[webkit-dev] Newline translation issue with textareas

Kevin Ballard 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  
>> char
> 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 Ballard
kevin at sb.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
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 mailing list