I've seen this discussion back and forth, and I know traditionally background image is NOT supported in outlook 2010. But I have also seen it done. Some designs require live text.
What is the ultimate synopsis, just don't use -- or try to hack? If a hack, what is the best one? (most supported)
As long as the design is not reliant on absolutes, I say go for it. Support is as large as it has ever been on background image usage and with some tweaks and 'hacks' you can get your emails looking great (even on Outlook!).
Best place to go is bulletproof backgrounds they will give you the code (HTML/CSS and VML for outlook) for both a bg image for a TD and a bg image for whole email. This is a great leaping off point and helps do most of the leg work for you right off the bat.
When positioning your children over the image in parent container, I would make sure to reference CSS compatability across each email client and do acid test after acid test to make sure it is displaying as you wanted.
It may take a bit of extra work, but the results can be more than worth it.
Related
I'm coding a transactional email template and it's intended to have a header with a bottom-border with an inverted border radius (see attached image).
Originally I've attempted this with a background image which works fine as long as: (1) The user allows for images to be downloaded, of course, and (2) Most importantly, the email is viewed in desktop because when fiddling with responsiveness (bellow 600px width) things get really messy.
With using an image I was trying to avoid using complex CSS code given the varied levels of support in email clients. However, I'm thinking that it may be a better option to avoid the issue with responsiveness.
I've seen different methods to achieve this curve. For example, over-imposing an absolute element at the bottom of the div with the overflow hidden and adjusting the border radius values there. Not sure, however, if it would worth the effort.
Could you help me find the best way to approach this problem having in mind the limitation of emails.
PS. I'd be OK with a non-curved bottom-border as a fall-back in cases where the client can't render border-radius appropriately.
Is there a reliable way to overlay an image over another image in a table-based HTML email? Keep in mind that, in order to render correctly, styles need to be inline.
Apparently the only way to have a bg image that works in all email readers is by specifying one for both the HTML background attribute of the body tag (for Outlook 2007, 2010) and the HTML background attribute of an HTML table that occupies the entire page (for all other email readers). It doesn't appear to be possible to have a bg image anywhere else that will display in all email readers.
Generally speaking the answer is "no". You can't overlay foreground content on top of other foreground content, and the options for adding a bg image are almost non-existent. But if you can manage with a single large bg image for the body tag (and table wrapper), combined with one or more foreground images, then "yes".
See: http://blog.mailermailer.com/2011/04/background-images-in-html-email-the-naked-truth/
Edit:
After running some exhaustive tests in Litmus, the answer is a resounding "no". Outlook 2007 and later only supports 2 ways to display a bg image: using the HTML background attribute on the body tag, and using the inline background-image style on the body tag. But in both cases, Outlook scales the image differently than other email readers, and there's no way to prevent the bg image from tiling.
For all practical purposes, in cases where it's important to support a wide variety of email readers:
There's no way to overlay images (or any other type of content).
Bg images are not supported.
From what I can gather backround images are not supported through all browsers. However, you may find this page from Campaign Monitor useful. At least it is quick to test the code to see if it suits your readers needs - check your email stats against which clients work before implementing if I were you.
I believe the above advice regarding "the only way to have a bg image that works in all email readers is by specifying one for both the HTML background attribute of the body tag" is also correct although Campaign Monitor seems to indicate otherwise. I would be careful to work out which browsers/email clients use the fallback and as to whether that would negatively effect your design.
As Z Index is supported except in Gmail (so perhaps not all that well), you could try to use that to create a design. Given that Gmail doesn't support it and the fallback is likely to be ugly as sin, you probably don't want to try this.
The designer I'm working with has given me a monster of an implementation issue...
Page background is grey, and atop of it is a crumpled paper texture (non-repeating with painted design elements) for the first 600 pixels (by 1400 pixels across; currently centered as a non-repeating background). At the bottom is another div with more text on it -- with a dropshadow, complex line pattern for the background and ripped edges, hovered slightly above the top div.
Saving the top part as a JPG and the bottom part as a transparent PNG leads to filesizes of +1mb.
Saving the top part as a JPG and the bottom part as a JPG doesn't work very well due to the drop shadow. It would technically work to save the bottom part as a slice with elements of the top part underneath the dropshadow, but it would have to line up pixel-perfect always or else look crappy. And at that point, I might as well save the whole site as one big image...
If the bottom part had a solid colour for the background, I could set each edge to have a different transparent PNG. However, the line pattern on the bottom part means that this wouldn't work.
My question is ultimately:
How the heck do people do ripped edges these days without making their site one big image?
Thanks!
Screengrab:
CSS3 does provide a border-image property, which should be able to help you with the ripped border effect (although even then, it would help if it was a repeating image).
See here for the W3 specification.
However it may not be much use to you, because browser support for this feature isn't great -- IE doesn't support it at all (not even IE9), and while most other browsers do support it, they all currently have gaps in their support and require a vendor prefix in the CSS property.
See CanIUse.com for a full browser support table for it.
To be honest, I think you should just go back to your designer and ask him to make it easier to work with -- he's probably just created something he thinks looks good, but is unaware of the limitations of the design he's put together; if you explain the issue to him, he may well be able to produce something a bit more usable for you.
There's really not a whole lot you can do here.
Page edges are ideally seamlessly repeated via repeat-y, and in your case it looks like the texture is one big image. You're either going to have to settle for sub-par performance or present the designer with your issues.
Check the archive of this blog for a good example.
You either have to fix the background images and use the entire image (or the top image AND the bottom image) and make the background non-scrolling. OR you have to get him to design a pattern that can repeat and then use a smaller PNG.
Clearly, your designer has a print background....
Ok, there's ways that will most likely theoretically work. But theoretical isn't always practical. I suspect your desire is to have cross-browser capability, as all of us should. So, start by throwing most new CSS3 tricks out, thanks to legacy IE. Forget box-shadow, forget crazy png tranparencies without hacks, etc.
What you're left with is doing a gigantic .jpg background. That will load....eventually.....
In this case, you can see the storm on the horizon, so run for cover. Go back to the designer, explain why this is about as smart an idea as texture layered over gradients, and help them understand why our buddies at Microsoft have made this virtually impossible. Just like a fully-flashed out site, it can be done somehow....but it's probably not the best use of time and resources. The web isn't print, it's dynamic...and when you put something "on a page" it's not going to stay put as it would in Illustrator, nor can you guarantee that your user is going it experience it in 100# glossy with a metallic overlay. Yes, I was a designer before I was a developer.....
Sound like a cop-out? Maybe it is. But I've been in your shoes, building sites for credit cards. My team was forced to waste thousands of dollars of the bank's money trying to make sites work with designs that probably shouldn't have been done on the web, thanks to print designers doing double-duty, getting designs approved prior to talking to the tech team....after, of course, we presented management with the options. Ultimately, it got the boss fired for going over budget.
although this is untypical, I would recommend cutting a big square shaped hole in the center of the image so that you're only left with the edges themselves and a transparent center and saving to PNG. Then saving the center part itself as a jpeg and putting the jpeg directly on top of the PNG in the correct position.
This way, the majority of the very large PNG will contain very little data and be a very small file size. The rest of the data would then, obviously, be jpeg and therefore smaller.
I ask because my buddy posted a question earlier on How to resolve issue with image path when testing HtmlHelper? and a few of us in the office got talking about how to resolve this.
One of the guys suggested that he wouldn't have this issue (Test crashing because it has a dependency on functionality in IIS) if he was referencing the image from CSS.
His point made perfect sense, but it kind of threw us back because we'd always been referencing images with <img/>. Were we doing it wrong all along? None of us are experts in this area so I thought it was worth putting to the community. What's the best way to reference images?
There are a variety of benefits to using CSS background-image and inline <img /> tags. CSS background images are great for decorative elements (content borders, background patterns, etc.) as they can be repeated with background-repeat. They make a poor choice for content-centric images, though, like product photographs, bio avatars, etc. Here, inline images work best because you can use an ALT attribute, and images are displayed regardless of browser (some older mobile browsers don't support backgrounds in CSS).
The tag is the best way.
It's standards compliant, accessible, and SEO friendly.
Indiscriminately putting all images into CSS background-image properties is a terrible idea in my opinion. Just a few things you deprive yourself of:
You can't stretch and resize images (may sometimes be necessary)
You can't use the ALT attribute (as David already says)
Background images usually won't get printed
they won't get indexed by search engines
they are difficult for the user to store
missing images won't show up with the "broken image" icon in IE
bad browser layout engines may have problems zooming, because the surrounding container could get zoomed apart from the image content (Shouldn't be a problem in FF though)
you always need an additional container to put the background-image in so you can't e.g. do DOM operations with image elements
the <img> tag exists for a reason, and should absolutely be used where appropriate (i.e. where the image is part of the content rather than decoration or background). For the "sort icon" thing I second what David says, it's fine both ways, but if it's a clickable element it should be an img.
When designing my homepage, I feel like the common knowledge is that it is bad to just have one big picture in the center that gives all of the content. The "right" way to do it would be to chop up the large layed out image into several small backgrounds and make the text use standard html with css background images for layout.
Is the only reason one big image is bad SEO reasons?
A search engine can't make sense of it.
A blind or otherwise visually-impaired person can't make sense of it.
Someone blocking images because he's on a mobile phone with expensive internet can't make sense of it.
There are a few reasons :-)
Also important:
Changes are not easily made to whole, pre-composited images, unless you still have access to the original layered variants. And hopefully they contain text as well, not just pixel data. (Mentioned by others before already. Credits go to pierre and Kendrick)
If you're using background images don't forget to set a text and background color too. Otherwise people not seeing any images might have a hard time deciphering your text (black on black isn't nice to read :-))
You can still use one large image as background. How the text is layed out above that is another matter entirely. In fact, chopping up the image and piecing the pieces together is painful using CSS too. In my experience it's best and easiest to leave background images unchopped and instead composite the rest of the layout above them, using other images or backgrounds if needed. This gives you a little more flexibility when changing a layout again, too.
SEO is one. Handicapped accessibility is another big one -- a screen reader can't read text within an image, typically. Page load time is another one; a user with a slow connection won't see anything useful while the image loads. Lastly, many browsers will use multiple connections to request resources such as images, so they can be loaded simultaneously. If there's just one image, only one connection can be used.
Updating will be tedious; you can also no longer rely on many benefits of CSS.
It's also bad for accessibility (screen readers, text-resizing, different monitor sizes)
It also removes your ability to easily edit text content.
I certainly wouldn't do it if you're looking for a web-developer job, but if you really don't care about the above, you won't be the first person to do it...
I see no reason at all in using imagea to represent something what can easily be achieved with HTML and CSS.
You're putting up a web site to enable communication between you and your visitors. Images and Flash prevent that.
Generally, you design a site with HTML/CSS and text. Only when you wish to add some design that cannot be expressed with standard means, then you use images. But have your site degrade gracefully for those who cannot or does not wish to see images. Let images be an addition, like an advanced version, in no case a replacement for text.