I’m currently putting together an eshot for one of our clients which includes individual self-sizing height divs for different products. The outer divs have 20px padding to create a uniform space around the products.
The problem is two of the divs that have a single full height graphic item within are appearing in browsers with an additional 30px of space at the bottom. It appears fine within FW so where is the additional 30px coming from?
The units in question are 2nd and 5th from the top.
I hate to break it to you, but you have constructed your page with HTML
Layering off, so Freeway Pro renders everything with table layouts… there
is no div.
The problem is two of the divs that have a single full height graphic
item within are appearing in browsers with an additional 30px of space at
the bottom. It appears fine within FW so where is the additional 30px
coming from?
The units in question are 2nd and 5th from the top.
It is still a DIV, but only “code” spoken which will mean the output. What Ernie wants to say is, that you placed HTML items on your canvas with CSS Button off. Another point could be, that you styled your HTML item via Inspector (border, rounded-border, box-shadow) which could cause sometimes, that Freeway breaks this down to a table (code spoken here as well).
It’s a matter of fact, that it’s hard to guess, how this “table is created or generated” and where there had been rows striped in (which could cause the more of space) - don’t forget: All we can see is the DOM-code or source code of your example and not the construction view.
It’s created using the default blank html email template in FW which, in turn, uses the create email action. It is created using CSS as the CSS button is turned on, but I assume it’s the action which converts the CSS into a table layout and the resulting code. That said, I can understand what you’re saying about not being able to identify the CSS that created the code.
It’s not that much of an issue, so I will soldier on and hope the client doesn’t question it!
Tables are infinitely preferable to CSS and DIVs in an e-mail. Remember, even in a Webmail system like Gmail, e-mail is NOT the Web. HTML e-mail is a contradiction in terms, point in fact. Outlook for Windows uses the Word 97 HTML rendering engine, for crying out loud, so you have to party like it’s 1995. (Tables, clear GIF spacers, all the hoary old badness of our collective youth.)
Walter
On Jan 7, 2014, at 9:44 AM, neil.west1 wrote:
Thanks Thomas
It’s created using the default blank html email template in FW which, in turn, uses the create email action. It is created using CSS as the CSS button is turned on, but I assume it’s the action which converts the CSS into a table layout and the resulting code. That said, I can understand what you’re saying about not being able to identify the CSS that created the code.
It’s not that much of an issue, so I will soldier on and hope the client doesn’t question it!
Yes - I saw this indeed too late that it is an email template - my mistake. All I wanted to say that it is (at least for me) way too hard to figure out which row is too much.
Sorry Walter, not sure if I’m getting the drift of your post. Are you saying that I shouldn’t be using FW’s own email templates or action and creating in CSS; and should instead be starting from scratch with a blank table-based layout?
I used to create them as tables before I tried FW’s version and decided that the FW method was so much easier and ‘appeared’ to work just as well.
Tables are infinitely preferable to CSS and DIVs in an e-mail.
I wouldn’t go as far as “infinitely”.
I’ve been making regular email announcement for two different clients and
found that my regular inline method works very well, provided all the
styling is straight-forward and completely inline, and images are
absolutely referenced. Works great in Gmail, Apple Mail, IOS Mail, etc.
Mail clients are behind browsers when it comes to consistency, but they are
not as primitive anymore.
Also, FWP may call them “html items” but they are definitely NOT divs. A
div is a single structure with dimension, padding, margin and border.
Tables are a half-dozen structures cobbled together by Freeway Pro’s
“logic” so finding a culprit will require some serious deconstruction on
the output side.
Neil, the best I can do for you is to suggest using your browser’s
developer tools to “see” how Freeway’s generated table structure is
working. For example, if you scroll to the “Spill Kit Station” and right or
control-click (in Safari) you’ll get a menu with Inspect Element as one of
the choices. That will open either a split window or small floating window
with a live code view. Hovering over those code structures will highlight
and reveal all the many structures FWP is using to create that bit of your
layout. Once you find the element holding the Spill Kit image, you see it’s
about 28px taller than the image. Why FWP decided to do this is beyond my
understanding, and any answer you would get would be only be a guess.
So what can you do? In the short term, I think nothing. Live with it. Over
the long term, you can look for ways to exert more control over how Freeway
generates your output code. If you stick with table layouts, then explore
ways to make Freeway simplify the output, not complicate it. That one
element is a simple paragraph with an embedded image - I would expect one
table row and two table cells, or one table cell with p text and an inline
img. Then testing to see how well email supports your solution.
Or you can try learning inline (box-model) design and using actual divs -
there are many articles on the net about using table-less html for email,
even responsive email.
Thanks Ernie, it was actually created as a box model with outer divs and ‘child’ html and graphic items within. As far as I’m aware, it is the ‘create email’ action that creates the code that makes it appear like a table.
Either way, my initial space problem has been superseded by a much more serious problem where Outlook 2010 appears to break the design by inserting a large horizontal space roughly half way down. I’ve spent several hours trying everything I can think of to locate the cause of the problem within FW and even rebuilt it as a table with exactly the same result. I’m now of the opinion that it is Outlook causing the problem, but I don’t know how to solve it. I’ve set up another thread on here if you’ve any ideas…
