Ryan said:
Thank you for your informative reply.
1. It's not my code - I am just amending code that was provided to
our
company.
2. Here is an excerpt from the code:
body += ' <td width="135"><b>Approval Id:</b></td>\n';
body += ' <td>' + approvalLine.ApprovalId + '</td>\n';
body += ' </tr>\n';
body += ' <tr>\n';
body += ' <td width="135"><b>Created:</b></td>\n';
From my understanding of the the "\n" creates a new line.
So while I fully get where you are coming from as far as I can tell
the
lines are being broken up.
Wrong. I'm talking about the length of lines in the e-mail message.
The newline character ("\n") could be anywhere in the line. That
doesn't change the length of the line in the e-mail message. It marks
the end of the line in the *rendered* display of the HTML. What you see
rendered is NOT what is physcially coded. For all we know (I can't by
your examples if the lines that you show are anchored to the left edge
or somewhere off at the end of the line), the \n *character* in the HTML
code could be off over in position 23,368 in the physical line.
I wasn't talking about how the HTML renders. I was talking about the
physical line length (in an e-mail) for the *coding* of the HTML
content.
Both the code that creates the html and the html itself are both
readable by
humans already.
What do you think?
Super long lines (of code) are hard for humans to read not just due to
having to scroll around but because parameters can become disconnected
(the user won't remember what were the other parameters within a tag)
and you usually end up with multiple tags per physical line so it is
easy to miss some when reading through the HTML code. I said to make
the *code* easily readable by humans (which would probably end up
shortening the lines so they can more easily be deciphered), not to make
the rendered version readable.
HTML code is nothing but plain text. All e-mails get sent a plain text.
Whether RTF-, HTML-, or plain-text format, they are always in plain
text. HTML is plain-text with tags. MIME sections are plain-text
encodings of attached files. So disregarding that anything is HTML at
all in your e-mails, make sure the physical lines of the text contained
within your mails remains under the recommended 998 character length
(and probably a bit shorter than that, too).
I'm suggesting you keep the *text* within your *e-mail* message to
shorter line lengths. I didn't not mention what to do for HTML coding
regarding the line lengths in the rendered version of the text used to
code the display of the rendered version. You said that Outlook was
adding a linebreak at every 967th character. Well, is that in the
rendered version of your e-mail or is that in the raw text of your
e-mail message? If the problem is in the rendered version, it isn't an
Outlook problem. It is an Internet Explorer problem since Outlook
doesn't actually do the rendering. Outlook uses libraries from IE to
render HTML-formatted e-mails. What do those e-mails, after their
receipt, look like when you view them directly in IE rather than Outlook
call IE to render them?
