This project is archived and is in readonly mode.

#3970 ✓stale
Fjan

improve textarea helper to avoid newline quirk

Reported by Fjan | February 16th, 2010 @ 12:49 PM

There is a little known quirk in HTML that causes a textarea tag that starts with a newline to ignore the first newline:

textarea_tag(:test1,"Foobar")
textarea_tag(:test2,"\r\nFoobar") # will result in a textarea with content equal to :test1 !
textarea_tag(:test3,"\r\n\r\nFoobar") # will result in a text area that starts with 1 newline

This is very much an edge case, because it will only surface when editing an object that starts with a newline.
The solution would be to have the textarea helper simply insert an extra newline. (Alternative would be to detect a first newline and encode it as )

Comments and changes to this ticket

  • Michael MacDonald

    Michael MacDonald April 21st, 2010 @ 01:42 PM

    • Assigned user set to “Ryan Bigg”

    I was intrigued by this ticket and tested it out and yes, the behaviour described above does occur for textareas in HTML (not just in Rails). So why do browsers behave in this way? According to the HTML 4.01 specification (Appendix B.3.1):

    SGML specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception.

    So, this behaviour is the "correct" behaviour. If the text_area_tag helper were changed then it would be behaving differently to how a normal textarea tag behaves.

    Based on this, I would suggest this ticket be marked as invalid.

  • Fjan

    Fjan April 21st, 2010 @ 02:20 PM

    Your observation is correct, but I don't follow your conclusion. If the correct behaviour is to ignore starting line breaks then how would adding an (ignored) line break make it behave differently? It would behave exactly as normal (and I've tested it does so on all common browsers).

  • Michael MacDonald

    Michael MacDonald May 10th, 2010 @ 02:24 PM

    I took another look at this and I think I understand what you're trying to achieve (or more specifically, why you want this change). If the data you have is "/r/nFoobar", when that is presented in a textarea the newline is ignored and not displayed. But if you were to save the form (without altering the textarea) the newline gets stripped and now your field's data is simply "Foobar". Basically, if the user wishes to insert a newline at the start of a textarea, it gets stripped out.

    My argument is that, this behaviour is exactly the same for standard html textarea tags so the rails helper should mimic that behaviour exactly. If you were to replace the rails helper with a straight html textarea, your behaviour would be different. HTML textareas that begin with a newline get stripped.

    Having said all this, I don't see any negative ramification of inserting a newline at the start of a textarea's content as, like you said, it will simply get ignored and is the equivalent of placing the content on a newline in the source. Ultimately, it comes down to whether a rails helper should output the exact equivalent of an html tag or should it improve upon the html tag to overcome quirks such as this.

  • Fjan

    Fjan May 10th, 2010 @ 03:10 PM

    I guess the reason the SGML spec absorbs the first newline is so that handwritten markup can look prettier; a text area created by rails looks messy in the source code with the first line appearing right after the starting tag and the rest of the lines starting at the left hand column. Handwritten markup would have been the usual way to work when the spec was designed. So you could argue that by inserting the extra new line you are writing the HTML the way it was originally intended, and that the Rails way of outputting everything without new lines is what is causing the quirk.

    But that's just a glass is half full / half empty discussion. I simply have a need for my users to allow text areas to start with new lines and would like to avoid monkey patching the rails helpers :-)

  • Ryan Bigg

    Ryan Bigg May 14th, 2010 @ 12:49 AM

    • Tag set to bugmash
    • Assigned user cleared.
  • Ryan Bigg

    Ryan Bigg May 14th, 2010 @ 12:49 AM

    • State changed from “new” to “open”
  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:39 PM

    • Importance changed from “” to “Low”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:39 PM

    • State changed from “open” to “stale”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Tags

Pages