I am working on multiple emails for a client who is using Outlook 2010 version 14 for a PC in their office. No matter how the email is created the right side of the table is blown way out.
For example:
Email #1:
Email #2:
This is the code: view-source:http://fortworth.dmplocal.com/main/index.php?action=viewsenthtml&id=95&ids=e9499cb22fd2fbaee560c877a2716fa0aab6880d
I have done a lot of searching to try and figure out what I could do to fix this, below are some things:
Took all CSS inline
Made sure all cell padding, cell spacing, and borders were set to zero
Specified width for tables
Specified height and width for images
Made sure images were the height and width that is specified in the code
Made images jpg's versus png's
Removed all unnecessary white space
My table is not more than 23.7 inches in height
I have read a lot of forums and found that a lot of people have problems with Outlook as well, but I have not found one that has the big space to the right of the table thus pushing it out that mine has.
Any help would be greatly appreciated!
For HTML tables, specify the width and height using HTML attributes rather than CSS styles. Modern versions of Outlook ignore width and height styles.
As #MarcB mentioned, Outlook 2007/2010/2013 uses the rendering engine of Word to render emails. Previous versions of Outlook used the rendering engine of IE. This shift caused significant changes to the landscape of HTML emails.
Below is a partial list of features not supported by Outlook 2007 and up:
CSS styles
float
position
display
width
height
padding (doesn't work on div and p tags)
background-image (only works on the body tag)
list-style-image
HTML attributes
alt (img)
background (table, th, td)
colspan, rowspan (th, td) (there's conflicting info on this, but it does appear to be supported, as long as a value of 0 is not used; however, it's often recommended to nest tables instead of using colspan and rowspan)
Miscellaneous
Animated GIFs
HTML forms
Try placing /> to close the image tag. This alone worked for me. This is a problem wholly invented by MS. As if it wasn't bad enough before.
#MattCoughlin's answer is right insofar as Outlook code. However, I would also add that Outlook is really specific about column and row counts.
Therefore, check that the number of columns add up. Use empty cells and colspans where necessary.
I just did some edits to your code and put up a fiddle for you to test.
http://jsfiddle.net/YWnzc/135/
But I could't check what I have done in my outlook 2010, but I think there are a lot of limitations in outlook 2010
http://fixoutlook.org/
Let me know how it goes.
further I also see that you have tables nested in your code. I dont hink this is necessary. seeing your mailer design this should be a pretty similar and the pronlem you are reporting should not be there, if it was properly coded.
As for me outlook ignored width of div, so if you code it like:
<div style="width:500px">
<table width="100%">
...
</table>
</div>
the width of table would be expanded to 100%, so try nesting all of fixed width elements inside tables and set fixed with to these parent tables (note that table also needs style), like:
<table width="500px" style="width:500px">
<div style="width:500px">
...
</div>
</table>
this will give you the width needed
Related
I am using the polymer svg iconset and iron-icon element in my page. Lets say I have a large number if rows in a table and each row has a couple of icons in it (uses iron-icon). These icons are repeated in every row. When I inspect the DOM, I see that each iron-icon in each row has the same icon svg as part of the DOM (inside the shadow root of icon-icon).
Isn't this a huge performance bottleneck? IE11 is slow in parsing DOM and this can cause further slowness. Would a font base icon set be more optimized here? Is Polymer's approach to use a svg iconset wrong?
From my experience, the performance issue is not in the size of the DOM itself, but the JS API interaction with it. The way Polymer implements the icons, it acts as a polyfill for Web Components custom elements. What actually happens in older browsers that don't understand their declaration is that if you write
<iron-icon icon="search"></iron-icon>
a scripts cycling through the DOM replaces what are considered unknown elements with DOM elements the browser understands (You'd have to look in the DOM inspector to see what actually is used in a specific browser).
A more direct approach could be to use something that IE understands natively, for example the SVG sprite pattern. Include an invisible <svg> element that contains symbols
<svg display="none">
<symbol id="search" viewBox="..."><path d="..." /></symbol>
...
</svg>
and reference them
<svg class="icon"><use xlink:href="#search"/></svg>
If you can achieve that when compiling the page server-side, it avoids the use of scripting in the client and should give a nice performance boost.
Even if your table cells are constructed client-side, adding these elements to the DOM directly might still be faster than first adding somesthing that a script has to replace later in a second run. (But that is only my guess without experience to back it up.)
I am trying to set up a simple blog using Metalsmith and the fullPage.js library.
At the moment I have a problem where the height of the section divs upon intial loading are roughly 2 times the correct size.
Ie. when it initially loads the height in the console reads 1563px.
The odd thing is that once I resize my browser window in any way ie. make it larger or smaller, the div(class='section') height will then resize to its correct height in the console and in the browser, and everything is laid out correctly again (with regular sized divs as opposed to the super tall ones that were there previously.
This initial height inconsistency is causing many issues with alignment in my layout, such as the prev/next arrows as well as the div content.
here is a link to my public git repo for this project.
If you want to run this locally you can pull it down, run npm install, then run nf start. You will then be able to access it at localhost/3000.
If anyone has any suggestions that would be much appreciated.
Thanks.
It is not ideal to just public your source. A link reproducing the error would be much better.
In any case, I believe yours is a case of missing the compulsory DOCTYPE declaration at the very start of the page.
Take a look at any examples of fullpage.js. They all have it.
Add this in the first line of your resulting HTML files:
<!DOCTYPE html>
In my email I have a html table. Table width is set to 900px.
I need to support initial text format set by user (only line breaks). So after a lot of tests I found out that for Outlook 2007 the best solution was tag <Pre>. I wrap text with this tag. But the problem is that some lines are very long and don't have breaks. In this case all email clients automatically breaks lines so table width is not changed. But Outlook 2000-2003 displays this lines without wrapping them. So the table width is increasing.
How this can be fixed? If I remove <pre>
tag everything is ok, long lines are autowrapped, table width is 900px but in this case I loose user text format (line breaks set by user).
In my opinion, the width of your email should not be larger than 600px. I recommend looking into using a framework or boilerplate template. This will make your life a hell of a lot easier. I personally like Zurb's Ink framework, but certainly there are others out there that will work just as well.
Good luck.
I want to print an html table with inline style for particular cells. This is the image of the table.
but when I print this web page out. the colors for those cells disappear. This is the image of the print preview.
This is the code sample of the table:
I know that I can set media type to print for css classes to print those colors out. But there are hundreds of colors available and creating a class for each of them will be a nightmare.
U guys got any solution to print this table with colored cells out?
This was a while ago ... maybe this no longer an issue with today's browsers?
They will print background colors if asked to do so. At least it worked for me, and I have pretty much exactly the same situation (inline css generated individually for each cell by PHP).
See https://rewordify.com/BackgroundColors.htm
Hotmail appears to be the only client which produces an unwanted gap in-between two tables carrying images. They should be nested directly against each other. The 'display:block;' (within the img tag) is not the solution because I have multiple cells and images next to each other (in that header section with the logo).
The extra vertical space seems to appear in the tr, td, or table tags in the header section. In Hotmail it creates a 92px height, in everyother browser its 89px (same height as the images).
(I cant post images yet - not enough rep.)
The code via jsFiddle.
I've tried playing with line-height and margin. I can't seem to get any adjustments to respond in Hotmail. Any leads? (I've read all the other html email gap questions)
Try setting cellspacing and cellpadding to "0".
Since it's Hotmail you'll probably be able to troubleshoot the e-mail through your browser's code inspector (Chrome Inspector and/or Firebug). Try to find what elements are causing the gaps.
It's not such a good idea to use margin in an e-mail since this can cause a lot of compatibility issues. How is this e-mail behaving in Outlook 2007/2010/2013?