I am supposed to send out the newsletter for a local club. Formatting in HTML appears fine, but if user views the email in a web based client (e.g. yahoo, gmail, etc.), the image also appear separately as an attachment; even though I am using a URL to reference the image. How can I avoid having the image appear as an attachment? Thanks!
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Club News</title>
</head>
<body leftmargin="0" marginwidth="0" topmargin="0" marginheight="0" offset="0" style="-webkit-text-size-adjust: none;margin: 0;padding: 0;background-color: #FAFAFA;width: 100%;">
<center>
<table id="table1" style="background-color: #ffffff; border-bottom: 0px none; width: 600px;" border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td>
<img style="position: relative; right: 0; bottom: 0;border: 0px none; line-height: 100%; outline: none; text-decoration: none; display: block; float: left;" title="Club1" src="http://www.clubswebsite.com/assets/img/clublogo.png" alt="logo" align="center"/>
</td>
</tr>
</tbody>
</table>
</tr>
</tbody>
</table>
One solution you can use, if your image is relatively simple (such as clip-art or logo), is to convert the image to pure HTML. You can find tools that convert the bitmap to an HTML table, coloring the cells in the pixel's color. Some convertors (here's one that I wrote - source code here) apply RLE compression to make sure that HTML isn't too large.
Note, that even with RLE this greatly increases the image size (e.g., a 5kb PNG might grow to be 80kb HTML) but AFAIK, as long as you keep the e-mail size under ~120kb it displays well on all e-mail clients.
Related
I have an animated .gif that is 1200px wide in total, but I'd like to scale it down to 600px wide for a clearer image in 120dpi. Below is the code that's in the message; it's displaying in the right width but the wrong height (as you can see there's no height defined, and it's not auto-scaling the way I'd like it to).
Outlook 2019 is the only email client in which it's displaying wrong. It looks fine in all other email clients. Also, the other images (.jpgs) in my message are displaying exactly the way I want them to, and they contain the same inline CSS.
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td style="padding: 0; text-align: center"><a href="https://www.lookoptic.com/collections/screen-products" target="_blank"> <img alt="FRAMES FOR THE FAMILY | Make protecting your eyes from harmful blue light a family choice. With matching frames for adults and kids, we keep it easy for the whole family to keep their eyes healthy even while spending more time in front of screens than ever." border="0" src="https://d3k81ch9hvuctc.cloudfront.net/company/HQd5zH/images/57fbdbba-e232-441f-abc2-098444d1525f.gif" width="600" style="display: block; border: 0px; outline: none;
width: 100%; height: auto; max-width: 600px;background: #fff; font-family: sans-serif; font-size: 15px; line-height: 15px; color: #555555;" /></a> </td>
</tr>
</tbody>
</table>
Any ideas? Thanks in advance.
Outlook will ignore the style sheet for your image. So you can use the height and width tags to direct the behavior of Outlook and allow modern email clients to operate the way they need.
If your animated image on Outlook is supposed to be 600px x 600px, do this:
<img src="#" width="600" height="600">
Then for the other clients, add in an inline style sheet (like you did in your example.
<img src="#" style="width: 100%; height: auto; max-width: 600px;" width="600" height="600">
This will work for any image format supported in Outlook.
Good luck.
The root problem is to display nice button compatible with MSO. As I used VML its working perfectly one pc, and not working an another. The point is environment of both PC is same
Win 10 - Microsoft Outlook ( 16005.13110.41006.0 )
The button source code is
<!--[if mso]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" href="http://google.com" style="line-height:28px; height:28px;width:135px; display: inline-block;" stroked="False" fillcolor="#468fb0">
<center style="color: #ffffff; font-size: 11px;">
CENTER
</center>
</v:rect>
<![endif]-->
At mine it looks nice
In other PC
So
Sizes are less in both dimensions
No text inside
Button is clickable
I tried different combination of VML/HTML tags, but it always the same - width&height ignored, and inner text is missing at all
If save emails as EML file and compare - its the same
Any suggestions what can be trigger this styling?
Other links and styles working properly btw.
Thanks
I noticed Campaign Monitor's 'bullet proof button' has this <w:anchorlock/> before the <center> which appears to function as an internal mechanism to stop anchors (links) from being modified. Maybe that's it?
I.e.
<!--[if mso]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" href="http://google.com" style="line-height:28px; height:28px;width:135px; display: inline-block;" stroked="False" fillcolor="#468fb0">
<w:anchorlock/>
<center style="color: #ffffff; font-size: 11px;">
CENTER
</center>
</v:rect>
<![endif]-->
Ok, it was a weird but
The problem was in pixels ( maybe screen resolution related? )
Every size with px was less. Solved with replace sizes to pt
I have a GWT app with one main panel showing a table of PostgreSQL instances. I want the app to show other kinds of instances, e.g. Redis instances. So I'm initially wrapping the main panel in a DeckLayoutPanel to swap out the PostgreSQL panel with a Redis panel. There will a vertical menu on the left side that the user will use to select the type of instance to show.
Adding DeckLayoutPanel to the UI XML causes the main panel to not display, although I do see the content in a DOM inspector.
Here's the original, working UI, without g:DeckLayoutPanel:
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder
xmlns:ui="urn:ui:com.google.gwt.uibinder"
xmlns:g="urn:import:com.google.gwt.user.client.ui">
<g:HTMLPanel>
<table width="100%" border="1">
<tr>
<td colspan="2" align="left">
Logo
</td>
<td colspan="2" align="right">
Hello John
</td>
</tr>
<tr>
<td colspan="4">
<g:VerticalPanel ui:field="instancesPanel">
<g:Label ui:field="mainErrorLabel" />
<g:FlexTable ui:field="flexTable" />
<g:HorizontalPanel>
<g:TextBox ui:field="createInstanceTextBox" />
<g:ListBox ui:field="createInstanceVersionsListBox" />
<g:Button ui:field="createInstanceButton">Create</g:Button>
<g:Label ui:field="createInstanceErrorLabel" />
</g:HorizontalPanel>
</g:VerticalPanel>
</td>
</tr>
<tr>
<td>Help</td>
<td>About</td>
<td>Contact</td>
</tr>
</table>
</g:HTMLPanel>
</ui:UiBinder>
If I remove the g:HTMLPanel and also the HTML table, trimming it to, this works:
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder
xmlns:ui="urn:ui:com.google.gwt.uibinder"
xmlns:g="urn:import:com.google.gwt.user.client.ui">
<g:DeckLayoutPanel ui:field="deckLayoutPanel">
<g:VerticalPanel ui:field="instancesPanel">
<g:Label ui:field="mainErrorLabel" />
<g:FlexTable ui:field="flexTable" />
<g:HorizontalPanel>
<g:TextBox ui:field="createInstanceTextBox" />
<g:ListBox ui:field="createInstanceVersionsListBox" />
<g:Button ui:field="createInstanceButton">Create</g:Button>
<g:Label ui:field="createInstanceErrorLabel" />
</g:HorizontalPanel>
</g:VerticalPanel>
</g:DeckLayoutPanel>
</ui:UiBinder>
I'm using an HTML table here since I'm not a front-end designer and I have similar HTML for the non-GWT JSP pages (using a JSTL tag) so want to make sure the GWT and non-GWT pages render the same.
Should I be using something else than a table? Should I switch to divs for placement instead? Is using a g:DeckLayoutPanel in an HTML table not supported? How is one supposed to get identical HTML pages for GWT and non-GWT pages if one needs to use only GWT layout widgets?
BTW, I tried using RootPanel and that didn't work either with the HTML page.
I'm binding to it using:
interface Binder extends UiBinder<HTMLPanel, MyWebApp> { }
private static final Binder binder = GWT.create(Binder.class);
#UiField
DeckLayoutPanel deckLayoutPanel;
#UiField
VerticalPanel instancesPanel;
#Override
public void onModuleLoad() {
HTMLPanel outer = binder.createAndBindUi(this);
// Tweak a bunch of settings on the UI elements.
...
RootLayoutPanel.get().add(outer);
deckLayoutPanel.showWidget(instancesPanel);
}
The HTML hosting the page is this:
<!doctype html>
<%# page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<html>
<head>
<link type="text/css" rel="stylesheet" href="MyWebApp.css">
<title>MyWebApp</title>
<script type="text/javascript" language="javascript" src="MyWebApp/MyWebApp.nocache.js"></script>
</head>
<body>
<iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1' style="position:absolute;width:0;height:0;border:0"></iframe>
<noscript>
<div style="width: 22em; position: absolute; left: 50%; margin-left: -11em; color: red; background-color: white; border: 1px solid red; padding: 4px; font-family: sans-serif">
Your web browser must have JavaScript enabled
in order for this application to display correctly.
</div>
</noscript>
</body>
</html>
DeckLayoutPanel in a HTMLPanel
The problem is part of the title...
The short answer is: Do not nest **LayoutPanels in anything other than a **LayoutPanel unless you set a fixed size for it.
**LayoutPanels are meant for applications that that have a static layout that is defined from the outer to the inner. If you only user **LayoutPanels for the outer layout, it works. In your second code example you noticed exactly this behavior.
A html table works different, it needs it's content to define a size and grow with it. As **LayoutPanels do not grow with their contents, they have a size of 0x0px.
I answered a similar question lately (link). Possibly it answers different aspects of this problem.
I was aware of multiple scrolling libraries (TouchScroll, iScroll) for the iPhone/iOS due to its inability (???) to support overflow:scroll . However, I was not aware (and I am looking for confirmation) that IFRAMEs don't really work either. It appears that the iframe doesn't respect any attempt to give it a fixed size and always just resizes itself to its content. Am I correct on this? Is the only way to scroll an IFRAME to place it inside a block element with the overflow CSS property set and then to use a lib like the aforementioned?
simply adding...
overflow-y:auto;
-webkit-overflow-scrolling:touch;
to a div around my iframe worked for me
You can scroll any content which is set to overflow:auto by touching with two fingers and dragging. Don't put iFrame inside a div with overflow:auto, and instead set the iframe to overflow:auto itself. Unfortunately, iframe scrolling is very choppy, regardless of content or device, so the best solution is to find a way to make your content fit into one long page, with "top" & "bottom" view divs set to follow the viewport (if this is the effect you're going for.)
Have you given Joe Hewitt's Scrollability library a go?
You can read more about it here:
Scrollability, New iOS Physics Project from Facebook for iPhone Creator, Joe Hewitt
Hope this helps.
The code below works for me (thanks to Christopher Zimmermann for his blog post http://dev.magnolia-cms.com/blog/2012/05/strategies-for-the-iframe-on-the-ipad-problem/). The problems are:
1. There are no scroll bars to let the user know that they can scroll
2. Users have to use two-finger scrolling
3. The PDF files are not centered (still working on it)
<!DOCTYPE HTML>
<html>
<head>
<title>Testing iFrames on iPad</title>
<style>
div {
border: solid 1px green;
height:100px;
}
.scroller{
border:solid 1px #66AA66;
height: 400px;
width: 400px;
overflow: auto;
text-align:center;
}
</style>
</head>
<body>
<table>
<tr>
<td><div class="scroller">
<iframe width="400" height="400" src="http://www.supremecourt.gov/opinions/11pdf/11-393c3a2.pdf" ></iframe>
</div>
</td>
<td><div class="scroller">
<iframe width="400" height="400" src="http://www.supremecourt.gov/opinions/11pdf/11-393c3a2.pdf" ></iframe>
</div>
</td>
</tr>
<tr>
<td><div class="scroller">
<iframe width="400" height="400" src="http://www.supremecourt.gov/opinions/11pdf/11-393c3a2.pdf" ></iframe>
</div>
</td>
<td><div class="scroller">
<iframe width="400" height="400" src="http://www.supremecourt.gov/opinions/11pdf/11-393c3a2.pdf" ></iframe>
</div>
</td>
</tr>
</table>
<div> Here are some additional contents.</div>
</body>
</html>
Flippant answer: don't use IFRAMES anymore.
The following markup when viewed in Safari on Iphone and Ipad displays the body background color for 1 pixel between the two tables. What is this and how do I stop it?
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Title</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style type="text/css">
body{
background:#000;
}
table{
background:#ffffff;
width:50px;
border:0;
margin:0;
padding:0;
}
</style>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td>a</td>
</tr>
</table>
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td>b</td>
</tr>
</table>
</body>
</html>
I've taken the liberty of dumping your markup to a file on my server:
Original markup
Alternative markup
There is no actual gap on my iPhone, but... the resizing algorithm does leave some space between the tables from time to time while zooming in/out.
This almost certainly has to do with some math not perfectly aligning to the pixel and getting rounded to match the nearest horizontal line. There is not much you can realy do about this, unless you resort to surrounding the tables with an inline-block that has the same background-color set like in the alternate file linked above.
On my iPhone the alternate version never displays any black lines between the tables. Be aware though that now the next element will be next to the inline-blocked div instead of underneath the tables. I'll leave solving that upto the reader. hint: css clear attribute.
Humm.. Have you updated Safari?
On Safari 5 I have no issue with this html...