New Line Quirk with HTML TextArea mvc 0 comments suggest edit

Pop quiz. What would you expect these three bits of HTML to render?

<!-- no new lines after textarea -->

<!-- one new line after textarea -->

<!-- two new lines after textarea -->


The fact that I’m even writing about this might make you suspicious of your initial gut answer. Mine would have been that the first would render a text area with “Foo” on the first line, the second with it on the second line, and the third with it on the third line.

In fact, here’s what it renders using Firefox 3.0.3. I confirmed the same behavior with IE 8 beta 2 and Google Chrome.

three text

Notice that the first two text areas are identical. Why is this important?

Suppose you’re building an ASP.NET MVC website and you call the following bit of code:

<%= Html.TextArea("name", "\r\nFoo") %>

You probably would expect to see the third text area in the screenshot above in which “Foo” is rendered on the second line, not the first.

However, suppose our TextArea helper didn’t factor in the actual behavior that browsers exhibit. You would in this case get the behavior of the second text area in which “Foo” is still on the first line.

Fortunately, our TextArea helper does factor this in and renders the supplied value on the next line after the textarea tag. In my mind, this is very much an edge case, but it was reported as a bug by someone external a while back. Isn’t HTML fun?! ;)

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



23 responses

  1. Avatar for Steve C
    Steve C November 18th, 2008

    Ya, about as fun as a donkey with VD urinating in my eyes.
    I hope no kids are tuning in...

  2. Avatar for mike kidder
    mike kidder November 18th, 2008

    Question on the subject of helpers and markup. I just noticed yesterday that in passing a string like "Home" into html.actionLink it gets encoded.
    Any alternatives other than using straight html. A CSS template I am trying to use need "li,a,span" (not sure if angle brackets work in your comments) in that order.

  3. Avatar for haacked
    haacked November 18th, 2008

    You could use the Url.Action method instead of the Url.ActionLink. That method only generates the URL. In that case, you could use it within a normal anchor tag like so:
    <a href="<%= Url.Action(...) %>">Home</a>

  4. Avatar for Graeme Christie
    Graeme Christie November 18th, 2008

    Yeah the automatic Encoding can be incredibly annoying (Who decided you shouldn't have html in your html !). Phil's solution is fine in the case of Html.ActionLink, where it is trivial to implement the helpers functionality inline using Url... In the case of Helpers like Ajax.ActionLink, which render excessively complex html, implementing it by hand is not an option.
    Currently I work around the problem using a dirty hack, I insert a token as the Actionlink argument and then use Replace("Token", "real html"
    e.g. Ajax.ActionLink("XXXEDITXXX", "Edit", <blah blah="">).Replace("XXXEDITXXX","Edit");
    Works well enough. However it would be nice if MS could allow us to not encode Every Action Link. This looks hell ugly spattered around your code, and it is hardly obvious what you are doing unless you are aware of the limitation.

  5. Avatar for Graeme Christie
    Graeme Christie November 18th, 2008

    Argh ! There's never an Encode() around when you need one.
    My example above should read (I've used square brackets instead of angle brackets, I have no idea how you escape characters in this blog)

  6. Avatar for mike kidder
    mike kidder November 18th, 2008

    @Phil - sorry can't figure how to use the allowed tags in SubText comments... thanks for the info on Url.Action
    @Graeme - @Phil - thanks, I thought there was another option besides actionLink extension. [] == angle brackets
    Search stackoverflow website for a string.Format shortcut and make your own string extension to make it shorter:

  7. Avatar for haacked
    haacked November 18th, 2008

    @Graeme I think it's time I implement a better commenting system for Subtext. Or bring back my live preview feature.

  8. Avatar for Yuri Khan
    Yuri Khan November 18th, 2008

    By HTML 4.0 appendix B chapter 3.1, “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.” This is what you are observing.
    As far as I understand, the correct standard-compliant way to render a leading/trailing newline in a textarea (or any other element where white space is significant) is to enclose them (or the whole content, as may be practical) in a .

  9. Avatar for cowgaR
    cowgaR November 18th, 2008

    a ...
    //Yuri died in an excitement...
    (probably meant a paragraph though;)

  10. Avatar for Gabriel Bogea
    Gabriel Bogea November 18th, 2008

    This is the kind of thing that drives developers crazy. I'm glad someone found out about it before I had to go crazy trying to understand what was going on...

  11. Avatar for Jeff
    Jeff November 19th, 2008

    Actually, what you see in the browser is exactly what I would expect you to see. Simply put When you have <textarea>Foo</textarea>
    In this case Foo is always on the first line. In the first example the fact that youput Foo online witht he opening tag more or less told the browser to render this on line 1, then in the second example you had Foo hardcoded on line 1 of the textarea.
    So the behavior isn't that surprising at all really.

  12. Avatar for فناوران اطلاعات
    فناوران اطلاعات November 19th, 2008

    great!sometimes there are some point that we haven't noticed them during years of programming

  13. Avatar for jessicah
    jessicah November 20th, 2008

    The behaviour seems very normal. I've always written text-areas with the tags on separate lines; same as I do for code blocks, etc.
    But yes, whitespace is always a tricky issue in HTML/XML. Another interesting behaviour is that comments on their own line have the ability to affect layout!

  14. Avatar for Filini
    Filini November 20th, 2008

    Another thing that I've always found funny in HTML is the behavior of breaking-rows inside table cells.
    The new line after the BR is not rendered unless some content is written after the BR.
    BTW: how do I post some HTML markup in the comments here? My samples (even with encoded tags) are always rejected by the blog.

  15. Avatar for Michael Knopf
    Michael Knopf December 5th, 2008

    I agree with Jeff, when i read the opening paragraph I knew exactly how it would render as this is to be expected and is in fact the standard as noted in the comment made by Yuri Khan. In general I would say that modifying the output is mute really as most (if not all) developers are used to these whitespace issues.

  16. Avatar for developingchris
    developingchris December 17th, 2008

    +1 @knopf
    Thanks for giving me a second reason not to use this helper.
    Since its helping to muck with what I gave it, in a non standard compliant way, rendering useless the reason why I'm in mvc in the first place.

  17. Avatar for haacked
    haacked December 17th, 2008

    @knopf and @developingchris I don't understand your antagonism here. What would you expect
    <%= Html.TextArea("name", "\r\nFoo") %>
    to render as opposed to what we actually render?

  18. Avatar for developingchris
    developingchris December 17th, 2008

    I would expect it to render as if I had written a string output from a c# method in web forms.
    The antogonism is, although win forms people may think this is awkward, web people should and do know about this. Are you going to also turn every space in helpers into &nbsp;. Thats what this feels like to me. If that is the functionality you are aiming for, then as I said, its just the next reason why these helpers are going to be unused in my code. Not because I can't deal with this quirk, but because it shows that helpers are going to be quirky, and I'm not going to have control over my markup through them.

  19. Avatar for Michael Knopf
    Michael Knopf December 17th, 2008

    I'm not trying to be harsh or anything, @developingchris is a little rougher on people when it comes to these things as he hates to muddy the waters when it comes to separations of concern (separating the HTML from the logic), but I do follow what your emphasizing here and it's good to know that we can modify the output to behave in a manner that meets our expectations, however I don't think the default outcome is really a quirk as this is what is to be expected when dealing with HTML.
    I do agree with @developingchris that the expected output should be identical to what would render if in fact we had output the text via server-side code in a ASP.NET Web Forms project.

  20. Avatar for haacked
    haacked December 18th, 2008

    @developing chris. Ok, let's do a thought experiment using your recommendation.
    We have a page with <%= Html.TextArea("foo") %>. The user enters the following in the browser text box.

    | |
    |Foo |

    That will get submitted to the server as the following string:
    Now let's assign that to the variable submittedValue and re-render the form by calling:
    <Html.TextArea("foo", submittedValue) %>
    in order to render *exactly* what the user submitted. According to the markup you suggested we render, the user would see:

    |Foo |
    | |

    Does that seem like the correct behavior to you? If so, then we'll have to agree to disagree. I'd expect that the user would get exactly what the user typed in, which is:

    | |
    |Foo |

    Another way to look at it, is if we're doing XHTML, why should we render:
    instead of
    by default? After all, textarea is not an inline element.

  21. Avatar for Richard
    Richard January 12th, 2009

    Unfortunately, the WebForms HtmlTextArea and TextBox controls don't handle this issue at all:

  22. Avatar for jm
    jm July 12th, 2010

    This behaviour is defined by the w3c html standard, following sgml standards:
    "SGML (see [ISO8879], section 7.6.1) 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."

  23. Avatar for sattiahdf
    sattiahdf August 11th, 2010

    This thread is useful.