create new tag
, view all tags

Bug: all(?) browsers lose initial \n in textarea

Refactored from InconsistentTreatmentOfTextEncoding

If a topic on disc has a leading blank line, it is lost when the topic is edited in Mozilla, Firefox, Opera, IE(v6) and Konqueror browsers.

The problem would appear to be with the <textarea> element.

The text area in patternskin is defined as


Look at this table. If the png and rendered rows differ on your browser, please inform us here!

  no newline 1 newline 2 newlines
text in topic "fred©" "\nfred©" "\n\nfred©"
text in html document

png fred0.png fred0.png fred0.png

passed as "fred©" "fred©" "\nfred©"
total loss none first leading \n first leading \n

with browser/version confirmed/not confirmed notes
Firefox 0.9.1, 1.0.1 confirmed  
Mozilla 1.7.1, 1.7.5 confirmed  
Konqueror 3.1.4 confirmed  
Internet Explorer 6.0.2800 confirmed  
Opera 7.54u2 confirmed  
Safari confirmed  
Amaya 8.5-1 not confirmed poor rendering
Opera 8.0 (linux) confirmed  
Dillo 0.8.3 confirmed edit disabled
Encompass 0.4.5 confirmed poor rendering
Galeon 1.3.19 confirmed based on mozilla

From http://www.w3.org/TR/REC-html40/interact/forms.html:

In general, a control's "initial value" may be specified with the control element's value attribute. However, the initial value of a TEXTAREA element is given by its contents,

17.7 the TEXTAREA element

<!ELEMENT TEXTAREA - - (#PCDATA)       -- multi-line text field -->

None of the wiki engines reviewed solves the problem of the single leading \n lost each time you put text in a textarea element (with all tested browsers).


prepend the string %TEXT% in the template with a newline. that is:


implemented by CrawfordCurrie in r3827.

-- ThomasWeigert, MarioFrasca, CrawfordCurrie


So, as I understand it, the fix to this is as simple as putting a newline into the template before %TEXT%. Yes?
-- CrawfordCurrie - 18 Mar 2005
Well, it works for me (Firefox and Konqueror). Let's hope that's correct, because I just checked it in. r3827 Can someone please test on IE?
-- CrawfordCurrie - 18 Mar 2005

Now, AFAICT from that spec above, all the browsers (including IE) are wrong. As I read it PCDATA should preserve the first newline, but by my testing, none of them respect it. I can live with that as long as it's consistent across all the browsers, and indeed I believe my checked in hack is correct for all the browsers.

The general problem of encoding data fields so they are content preserving is the domain of InconsistentTreatmentOfTextEncoding.

-- CrawfordCurrie - 20 Mar 2005

I refactored further, replaced the test to TestingTextareaAndHiddenInput... removed a few comments which were no more relevant.

-- MarioFrasca - 20 Mar 2005

tested with IE and Opera. behaviour confirmed. removed outdated discussion. hope it is all right with you.

-- MarioFrasca - 22 Mar 2005

Fix record

This is now cured, thanks to the extra newline at the start of the textarea. Note that this newline is in serted in code, not in the template.

-- CrawfordCurrie - 26 Mar 2005

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2005-08-04 - ThomasWeigert
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.