Why do contact forms fail to handle line breaks?

Question

It's been my experience over the past few years that the majority of contact forms on web pages of both large companies as well as governmental institutions fail to handle line breaks properly in one way or another.

Typically, such a contact form consists of several single-line text boxes for contact details of the inquirer and one multi-line text box intended for the actual message:

When using such a form, I give the message a classic business letter/e-mail look and feel. I include salutation, closing and multiple paragraphs separated by line breaks to make the message as easy to read as possible for the customer service person on the other end.

I find that line breaks in the actual message often get messed up:

• Many times I would receive a confirmation e-mail repeating all the data I've entered. Usually, there would be one field per line and the line containing the "your message" field would present the message entirely without line breaks, making it really hard to read for anyone.
• Even if I don't receive a confirmation e-mail (or the mail wouldn't include any information entered into the form) I often find out from the reply, that customer service received the message in a way described above, with all line breaks gone.

Name: John
E-mail: [email protected]
Message: Hello, my name is John and I would like to know more about UX. Please let me know if there is a way to achieve X using Y. Thanks in advance. Best wishes, John

Being involved in web development myself, I'm aware that handling line breaks can sometimes involve a little work in order to make them work correctly. On the other hand, failure to handle line breaks at all would seem like a beginner's mistake.

Thus my question(s): Why is removal of line breaks in contact form messages so common? Is there a specific reason from UX point of view to disregard line breaks in contact form fields?

Answer 1

I would guess that any of the following could be the cause:

• The Designer did not think of this
• The Product Owner or BSA did not specify it
• The Developer was too junior so didnt know how to do it
• The widget used did not alow it
• The tech stack they used prevented it
• The security policy vetoed it
• There wasn't enough time to do anything fancy (e.g, MVP)

The bottom line is if this was specified in the design and everyone in the team agreed to do it, then the developers would have found a way to meet the design without falling foul of the security policies, and the data entered by the user would be converted with line breaks.

Answer 2

In my experience, this all comes down to the developer of the contact form not replacing the line breaks with proper HTML equivalents in the email message (sent as HTML). Options to format this correctly are to wrap chunks of text with line breaks between them into paragraphs (p) or to simply insert break tags (br) wherever you see a line break.

If the email message were sent as plain text, things would mostly be OK. I say "mostly" because even then there are issues with what constitutes a line break. Is it a linefeed (LF, \n) only, a carriage return (CR, \r) only, or a combination of the 2 (CRLF, \r\n)?

What I do in my email message translations is stick to the RFC standard for plain text emails, which prefers CRLF. When sending HTML messages, I replace explicit CRLF pairs first with br tags, then look for CR and LF individually to also replace with br tags. That typically handles whatever combination is sent to the server on form submission.

It really makes sense to keep the line breaks when translating a message to an email. Likewise, some systems store the user's message and show it on a web page for later reference (history). The same thing typically happens on those pages when the line breaks are not properly transformed (if at all).

Answer 3

Having just configured a website with an F5 Web Application Firewall (WAF) it appears that carriage-return and line-feed characters are commonly blocked to frustrate SQL-injection and cross-site scripting attempts - hence why you see this in corporate websites a lot. I imagine that blocking the charazcters is less effort than encoding the text box or using some other technique to remove these characters but retain formatting.