I'm pretty clueless on this issue at the moment so any help even small hints that might lead to the solution are really appreciated!
I've got an HTML mail that basically is a two column layout and in some cases links get unresponsive (they are basically clickable but nothing will happen when clicked) within Outlook 2007.
I've produced an as clean as possible example for an Email that has got that issue.
You can find a download here: http://static.bardiir.net/bugged_message.zip
The zip file contains the following:
The bugged message as MHT, EML and HTML files
Images used in the HTML-Version
If you don't trust the zip you can also access the html-version here:
http://static.bardiir.net/bugged_message/html_version.html
When you send the message to an Outlook 2007 client the right hand column link
Stet clita kasd gubergen, no sea takimata sanctus est will not be clickable.
If you can't reproduce from these source files please don't hesitate to ask and i'll happily send you a message that contains the bug.
Thanks in advance for any help :)
Update:
The message is originally generated with PHP on a server, if that's of any interest.
And if you remove the header-image or somewhat any part of the mail that's currently in there the link gets clickable, so the whole thing in combination seems to cause the issue.
Update2:
It's probably exactly the same bug as this but there's no answer there:
https://stackoverflow.com/questions/7420195/links-in-right-column-of-table-do-not-work-in-outlook-2007
Update3:
I just found out that the right hand column seems to be completely inert to anything. You cant even select text there (Outlook 2007 will crash). But if you tab-select the link and then press enter it works perfectly.
Update4:
I've got the perfectly same template with a left-hand column too, so basically only the order of the td cells is changed. With that ordering it always works. The links in both the main content as well as the sidebar are working perfectly.
Update5:
Even removing text only, no HTML-Tags at all, not even linebreaks will eventually enable clicking on the link. So if you go ahead and shorten every sentence in the above linked mail so only a few words without touch anything except the text nodes it will work again.
Update6:
I've built a completely valid version of the bugged message too like suggested in the answers. You can find it here: http://static.bardiir.net/bugged_message/html_version2.html
It's showing the same issue still but now all problems in validity are removed too.
(Validity shouldn't be the issue after all as the left-side column layout shows the same validation issues and is working correctly. Most of the validation issues are in fact only apparent in this example and not in the fully-filled newsletter that shows the same symptoms.)
It's hard to tell what's wrong with Outlook (stupid Word rendering engine). You can try opening the source in Outlook and see how Outlook is reformatting your html code.
I recreated your email using simpler HTML here. Hopefully this will resolve your issues.
Some things to take note of:
A number of email clients reject CSS shorthand for the font property.
Instead of using font tags, try adding the font-family property as an inline style to your table class to set the font type. It's also better not to use font intervals as well, because they may vary between email clients. It's better to keep all your style inline ensuring certain clients won't overwrite your style sheet with their own default one.
E.g. <table style="font-family: Arial, Helvetica, san-serif">
You should also limit yourself to one or two fonts + 1 (one for your primary, another as back up, plus a default system font, such as "san-serif" or "serif"). Nesting tables beyond 3-4 levels is just asking for trouble.
I used span tags instead of b tags for bold weight to avoid potential conflicts. I didn't use margin-top or padding, because certain clients like Hotmail ignore it.
Recreate your email, without the tables. You can do a quick test my using table2css.
There are two things which i have seen i.e. you are using two body html tags it might create a problem and another You are using Tested Tables and its the bad thing in Emails, I had also tested the best nested tables in email is about 8 Nested tables and going beyond that can also cause problem and if you are using them. Kindly use the tbody html tag also which would help in rendering this correctly for emails.
Related
I have a site which uses the Bootstrap framework.
Unfortunately some of the classes of divs do not display in Chrome (only) & I can't figure out why.
Bootstrap sits on another PHP framework - I did not create this original code; but I can modify it easily enough.
The hidden divs are being rendered in the DOM (I can inspect them).
I've searched all references to the hidden div class (col-ad) & they all come up as nice & mundane CSS with no obvious things that could make the div hidden. No javascript references either.
If I rename the class (eg. Xcol-ad) in the DOM the div displays.
When I inspect the div I get the following:
Which is the only thing I can find which could be the culprit. Unfortunately I can't find a reference to this within any of my code.
Have tried modifying the DOM (display:block!important) without success.
When I click on the <style> tags it (I think) points to something called #shadow-root(open) at which point I'm lost. I've searched for info about this but haven't been successful (I'm not 100% sure this is even the problem) - have changed a setting within Chrome (Show user agent shadow DOM) without success.
It feels like my styling has been taken over somewhere & I don't know where.
EDIT: link to demo site where I got script - just tried looking at site with browsershots tool & ads appear even with Chrome, so may be my version(?)
That is clearly some kind of ad blocker extension, that inserts its own style rules to block/hide elements – look at the identifiers used in that selector, should be pretty obvious.
Edit: [further explanation, from comment]
The selector contains “ad” in all imaginable combinations, plus “advertisement”, “banner”, “sponsor” showing up as well. That is a typical kind of “kill ’em all (at least the most obvious ones)” attempt by an ad blocker – and that often leads to collateral damage.
You can also see .ads_320_100 there, which is targeting a specific, typical banner size; some blockers even remove all images that have that kind of “dimensions” specified in their name, for certain “ad-typical” image sizes. (Even though it makes server-side management of different image sizes easier, I’d recommend to stay away from such naming schemes – for this exact reason.)
Hello,
I have the website DaltonEmpire (http://daltonempire.nl, check out for yourself), and when I got home today, it showed error 500. I had made really tiny HTML changes at school via my new CodeAnywhere app, but this was not supposed to happen. After some cleaning up of my PHP, just removing whitespaces, the page loaded.
But now, the background is completely gone and there all all kinds of weird &nspb; tags between my HTML according to Chrome Developer Tools [1], which weren't there before. In my actual code, of course there's whitespace to order my HTML, but that's just spaces, no &nspb;'s, and that never happened before.
Also, the body background is not loaded [2], and the Developer Tools indicate that CSS responsible for the background is not included at all [3] (rather than overwritten or not loaded), even though it is clearly in a <style> block with the body selector [4]. Manually adding that [5][6] bit through the Developer Tools seem to fix this.
Has anyone any idea how this could happen/how this could be solved?
The strangest thing is, I did not change anything specific at all that I can recall. What has caused this?
I need my website to be fixed as fast as possible, as my visitors are students to get their educative documents and in two days is their test week.
Thanks in regard,
Isaiah van Hunen
Attachments:
Weird &nspb;'s
Background not loaded
Background CSS not included?
Background CSS is included
Adding manual Background CSS
Background loads
I can help with 1).
is a formatting entity:
it is the entity used to represent a non-breaking space. It is essentially a standard space, the primary difference being that a browser should not break
(or wrap) a line of text at the point that this occupies.
http://www.sightspecific.com/~mosh/www_faq/nbsp.html
Microsoft Word puts it into HTML files, and so do other WYSIWYG editors.
Unfortunately, CodeAnywhere seems to have the same issue.
Do you have an earlier version of the code that you can open in Notepad/Notepad++/Atom in order to add the whitespace manually there (with ` tags or the like)? That might help.
I'm the author of an email client and one of things I'm in the process of doing is adding support for HTML editing. The editor itself it build upon a HTML rendering control that I've written from scratch, however it supports most HTML and CSS fairly well. The issue I'm having is formatting the reply to HTML email with the user's reply template, which is also HTML (with a different style sheet). So cleanly merging two HTML documents with their own styles without either of them being messed up by the other document's styles.
When the user replies to a HTML email, I parse out the content of the tag and put it into a that forms part of the reply. That div's style shows a line down the left margin to inform the user that it's quoting the original email. Gmail does the same thing. Anyway the styles from the HTML block as saved separately and then insert into the head part of the new document.
What happens of course is that if the original email defined a style for say a link, that style affects all the links outside the original quoted area. So things like my signature at the bottom and the From/To header rendering that is part of the reply template all get that styling from the source HTML.
I'm wondering if there is an easy straight forward solution to containing all the original styles to just the quoted part of the document? Something like namespacing? Or limited scope styling?
The solution I've come to is to add all the incoming styles from the multiple documents to a global style sheet. Styles are matched by first checking the count of properties is the same, then enumerating each property and comparing it's value. This basically gives the software a minimum number of styles to correctly render the content. It could be really slow in a pathological case but so far it's working well in practice.
As an aside, recently I've noticed a lot of email clients striping all the style out of replies. Which to be honest seems like the cheap and nasty solution to the issue. Even if it does give a consistent look.
I have a HTML document with many tables which I want to be printed. The problem is that sometimes, the paper end is reached in the middle of a row, so half of it is printed in one page and the rest in the next page, even cutting a single line of text in two parts.
Is there any way to avoid this?
NOTE: I have already read this question, but I need a solution which not involves CSS, because is not working at the target computer, and I can't change that.
Even with CSS, the issue is difficult due to limited browser support to CSS pagination (as can be seen from the answers to the question you refer to).
Through years, this problem has existed, and I don't think anyone has souped up an HTML trick for the purpose. There have been some tricks for trying to prevent page breaks inside a paragraph or list by placing it in a one-cell table, but this has worked occasionally only, and besides, in your case you already have a table.
So I’m afraid there is no solution, apart from using elements that cause extra vertical spacing, like a pre element containing empty lines (to push the entire table to next page—this may of course make things much worse when the parameters of the situation, like page formatting and paper size, differ from your expectations) or splitting a table into two tables, possibly with extra space between them (even more problematic).
If the target computer doesn't support (enough of) CSS, then you can create a PDF document on the server. If you set the Content-Type correctly, the browser will download the document and start the PDF reader of the system.
If this isn't possible, then there is no solution.
I got some auto generated HMLT code working. Made sure it is correctly parsed by http://validator.w3.org/, and it is a working HTML4.01 Strict.
Now, when I embed this code in a email and send it to gmail, the result is quite adverse (messes up the formatting).
The code is quite long, and apparently only happens when it has such size. This tells me two things:
not worth putting a code snippet here
it is probably some conflicting tag, but still considered valid the parser
Would you guys know of any tool even more strict to validate my HTML? Maybe even something specific for gmail?
Or maybe, just some pro tip on what usually screws the code for gmail.
ps.: the code, although is long, is also quite simple, only a few tables and styles - I took some care in making sure used only "email friendly" tags and formats.
Did you say styles? Oh, boy! Email clients are all doing things differently and even if you get it working for GMail, it may not work for Yahoo.
You may want to look at something like Email CSS guide to start, but really you also want to use some of the Inbox Analysis services (e.g. Inbox Inspector from MailChimp) to get a better picture.
I haven't done this myself (yet), but I have seen mentioned over and over that this is one area you can lose your hair over.
You have to code like its 1999 and not worry about being so tied to conformity to HTML.
Unfortunately valid HTML just doesn't work for some (most) email clients. Even Gmail will strip or ignore things probably for security reasons. The best bet for an email is basically HTML 3. Some inline styles for fonts. I know that <p> tags break in Gmail, and in general colspan and rowspan won't work as intended and you have to use nested tables. Those are just a few things I can think of off the top of my head.
All the answers here helped, but the actual problem was elsewhere.
The problem was In the HTML as I thought, but not exactly in my HTML.
Turns out the the email client will wrap lines too big before handling it to render, regardless if it is HTML code or whatever, more exactly, breaking tags in the middle - that explain why it was happening only when the report reached a certain length.
What tipped me that was when I looked at the code generated by MailChimp (suggested by Alexandre Rafalovitch) and noticed it was formatted as quoted-printable, cropped at exactly 75chars for every line.
After that was easy enough to do the same in my own code generator. Well, actually, I didn't even format as quoted-printable, only made sure it would wrap too long lines by itself.
Apart from that, for all I can tell, a HTML 4.01 Strict code will work pretty much fine in a Gmail client.
Hope it helps post-1999 generations.
cheers.