Issue with content generation in outlook email reply - html

I am facing an issue with email generated from our application.
In the received email, I do the following
Ctrl-R (reply)
Ctrl-A (select-all)
delete
And I expect to then see an empty outlook email with the correct To: and Subject: lines. The problem is that these actions now lead to an empty box in my email rather than an empty email.
When I debugged the issue, found out that this is because of the following
Border is given to a div which is hidden.
In reply mode, this div becomes visible.
When I do select all and then delete, the box (which is due to
border to div), doesn't go
Figured that when I change div to span, this problem won't occur. But it is leading to lot of other problems.
Can somebody suggest a solution here. Basically, what I want to achieve is:
Delete all the hidden elements that are not disappearing when I select all and delete

Not exactly sure what you are trying to achieve.
Do you want to delete all the hidden elements that are not disappearing when you select all and delete?
You could try clicking the "Format text" tab, then change from "As HTML" to "As Plain Text" before you choose "Select All".

The problem was caused by a div at the end. Fixed the issue by adding a line break after that div

Related

IE 8 Select box item text is being truncated

The text in select box elements are being truncated on inital load, until a user clicks on the select box it looks like this:
Once the user clicks, the text will expand to say "Female". This only happens in IE.
Also, it seems like if there is sufficient text in the select box, then thee truncations will not happen. I just noticed this behavior:
I assume there is no style hook for a select's text? Based on this info, I think that appending a bunch of white space to an option that's length is less than 6 chars (or somethign) would be an acceptable if not annoying solution.
Here is what the select looks like once it gets focus:
I tried every solution in this post:
Select dropdown with fixed width cutting off content in IE
Which seems to be to "go to" post for this issue. Neither JavaScript or css techniques seem to solve this bug.
It seems like this would be a common problem; can someone suggest a pure css fix that addresses this bug in IE that is not mentioned in the post above?
Thank you.

Collapsible table in HTML Email (Outlook 2007-2010)

I've sent various HTML emails in the past, and have seen the pretty large limitations associated with it. What I really need is the ability to have regions with a show/hide ability - click the plus sign or a header to toggle.
I'm figuring JS is out of the picture, CSS might be a possibility. I only need it to work in Outlook 2007-2010. Any suggestions?
Thanks!
You can do this in Outlook using anchor tags. The trick is to create 2 tables that are separated by a td cell with a large height specified so that you don't see the second table.
Both tables are exact duplicates except that table 1 has the show link, while table 2 has the content you want to show, and a hide link.
When you click the anchor tag, the email moves down to the position specified in your second table. As the content in both tables is the same except for the show/hide box visibility, you've created an illusion that the box is toggling.
If you have more than one show/hide box, you'll need to create more tables. The email will get really long, but the toggling effect still works in Outlook.
The anchor tags:
Click here to show content
<a name="section1"></a>
Here's a quick example: http://jsfiddle.net/mjcookson/nq3Re/
Update to comment: Also, your email might not fill the entire viewport, so a gap between tables is used to avoid seeing the second table immediately after the first table.
You can't do that in Outlook. Its HTML email rendering engine is pretty bad. I have seen it done for the mobile webkit and android browsers.
See this article: http://coding.smashingmagazine.com/2011/08/18/from-monitor-to-mobile-optimizing-email-newsletters-with-css/

Textbox cursor landing in the middle instead of beginning of line

I am making a page where I try to allow people to write about parks they know about. A problem I am having is that when a person tries to edit a park, the cursor in the text area ends up what seems to be 1 tab over from the beginning.
Here is an example:
http://www.comehike.com/outdoors/parks/park.php?park_id=447
On the left column, if click on "Write and share what you know about this topic" you will see that the cursor doesn't end up in the beginning of the text area.
Any idea why this is happening and how to fix it?
Thanks!!
get rid of the space between the textarea tags and that will solve that problem:
<textarea> </textarea>
<textarea></textarea>
There's obviously data (looks like 2 tabs) being output in the value of the textbox, or is stored in the database with the existing data.
Ah yes, it's between your textarea tags. Remove the tabs.

How to resolve issue where table column is too narrow?

I'm new on this particular project, and I've been tasked with resolving an issue that's appearing in IE8.
If you check http://funds.ft.com/ETFHomepage.aspx, There's a section called "News". In that section, there's a column called "Most Popular ETFs". This should be the same width as the "Recently Viewed ETFs" column.
For reference, this page is appearing correctly in Firefox. Can somebody please point out what I can do with CSS or (some other means)* to resolve this?
*I know the best way to resolve this issue is to scrap the terrible design and implement it correctly!! :-) -- we're actually doing that right now. It's a big job, so it's taking a long time. In the mean time however, we have to fix the bugs as they appear. Thanks
Update: just to note what I've said to Hristo, "I think the problem is with the table (rather, nested tables) on the left. The table in the center has its width defined by the image, and the table on the right doesn't have an image so it gets crushed"
Well the reason this is happening is because of the url you have under the "Alphaville: Overcoming the Volcker rule, with ETFs" header. Since the url has no whitespace in it, the table tries to give it space. So there are a couple of ways to fix this problem:
Plain text urls aren't very becoming on a webpage (especially when they're not in anchor tags so you can click on them.) Could you update the content so that you don't have a raw url in your content?
If you must be able to handle long lines of text with no whitespace then you need to figure out how to change the layout of the page so it forces the text to either wrap or clip to fit the container. Try playing around with putting "table-layout: fixed" on your tables to force the column widths to be sized based on the table's specifications only (instead of content). Firefox seems to be wrapping on dashes and slashes in the url whereas IE only wants to wrap on the dashes in the url.
I would say your layout is fine, and you just need to fix the content generation so it doesn't include any long plain text urls (option 1 above)
EDIT: If you do decide to go with option 2 above, then look into the css rule "word-break: break-all". It is IE only and it forces the text to break as soon as it reaches the end of the container. Not good for words, but it works for url's. So you couldn't apply this to the whole news table, but you could to just the cell that contains the url.

Google Chrome textareas wrapping and adding line breaks

I've got a problem with textarea's in Google Chrome. I'm using classic ASP, but this is unimportant as Chrome is actually posting the data incorrectly.
The problem is with a text area. As soon as a string of text is too long to fit one line of the text area, it wraps to the next line (as it should).
My problem is that when submitted, the form data contains a CarriageReturn & LineFeed at every spot where the text wrapped, as well as user generated enter/return events - I can't even tell the difference between the two.
Does anyone know how to fix this? Possibly an option in the text area or something? All other browsers only add CarriageReturns and LineFeeds where the end user has actually put them in.
This should only happen if you set the wrap="hard" attribute on the textarea.
Do you have wrap="hard" set on the textarea ? If so, remove it. If not, can you try setting wrap="soft" as attribute?