New Line Quirk with HTML TextArea

Nov 18, 2008 aspnetmvc suggest edit

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

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

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

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

Foo</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
areas

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 mistake in the post? suggest edit

Comments

23 responses

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...
mike kidder • November 18th, 2008
Phil,
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.
haacked • November 18th, 2008
@Mike
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>
Graeme Christie • November 18th, 2008
@Mike
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.
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)
.....Replace("XXXEDITXXX","[span]Edit[/span]")
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
string.Format(Html.ActionLink("{0},"Index","Home"),"[span]Home[/span]")
Search stackoverflow website for a string.Format shortcut and make your own string extension to make it shorter:
(Html.ActionLink("{0},"Index","Home")).F("[span]Home[/span]")
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.
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 .
cowgaR • November 18th, 2008
a ...
//Yuri died in an excitement...
(probably meant a paragraph though;)
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...
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>
and
<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.
فناوران اطلاعات • November 19th, 2008
great!sometimes there are some point that we haven't noticed them during years of programming
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!
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.
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.
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.
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?
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.
<textarea>
Foo</textarea>
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  . 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.
Michael Knopf • December 17th, 2008
Phil
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.
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:
@"\r\nFoo"
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:
<textarea>Value</textarea>
instead of
<textarea>
Value
</textarea>
by default? After all, textarea is not an inline element.
Richard • January 12th, 2009
Unfortunately, the WebForms HtmlTextArea and TextBox controls don't handle this issue at all:
connect.microsoft.com/.../ViewFeedback.aspx
jm • July 12th, 2010
This behaviour is defined by the w3c html standard, following sgml standards: www.w3.org/.../notes.html#notes-line-breaks
"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."
sattiahdf • August 11th, 2010
This thread is useful.
as