700字范文 > 收件箱和发件箱表设计_在收件箱中播放不错

收件箱和发件箱表设计_在收件箱中播放不错

时间：2021-09-18 16:56:02

收件箱和发件箱表设计

photo :Nieve44/Luz

照片：Nieve44 / Luz

Coding email can be a tricky business. Once you get the basic rules down, it’s smooth sailing — until you encounter some bugs.

编码电子邮件可能是一件棘手的事情。一旦掌握了基本规则，就可以顺利进行，直到遇到一些错误为止。

As we all know, bugs are par for the course in web development — but email introduces a few additional complexities.

众所周知，错误是Web开发课程中不可或缺的部分-但电子邮件会带来一些其他复杂性。

Not only will your recipients use different browsers, but you’ll also have to contend with a variety of email providers, devices and apps — and all of these will render your email code (which you’ve worked so hard to translate from design to inbox) in myriad ways.

收件人不仅会使用不同的浏览器，而且您还必须与各种电子邮件提供商，设备和应用程序抗衡-所有这些都会渲染您的电子邮件代码(您一直在努力将其从设计转换为收件箱)。

It’s best to become familiar with each and every one of the canvases (and their many quirks) your users will use to view your messages on, and play nice in the inbox. Below are a few of the most common bugs I have come across over the years, and solutions to fix them.

最好熟悉用户将用来查看您的消息并在收件箱中很好玩的每一个画布(以及它们的许多怪癖)。以下是我多年来遇到的一些最常见的错误，以及解决这些错误的解决方案。

Gmail，Yahoo和iOS陷入困境 (Gmail, Yahoo and iOS got the blues)

Remember when web pages consisted mostly of black text and white backgrounds, with the occasional word underlined in blue text? Readers caught on to the fact that blue signified “hyperlink,” and learned where to click.

还记得网页主要由黑色文字和白色背景组成，偶尔的单词在蓝色文字下划线的情况吗？读者了解到蓝色表示“超链接”这一事实，并了解了单击的位置。

Most web designers aren’t still partying like it’s 1999, and will override that default blue with a hex value that compliments their personal design and color palette.

大多数网页设计师并没有像1999年那样开派对，而是会使用十六进制值覆盖默认的蓝色，以补充其个人设计和调色板。

Unfortunately, emails viewed in Yahoo and Gmail are a little stubborn about letting go of that penchant for blue links. Simply defining a new hex value as a style within an<a>tag just won’t cut it on these platforms. The easiest solution is to add an additional<span>tag, nested inside the<a>tag, defining the hex value a second time.

不幸的是，在Yahoo和Gmail中查看的电子邮件对于放开这种偏爱的蓝色链接有些固执。只需在<a>标记内定义一个新的十六进制值作为样式，就不会在这些平台上使用它。最简单的解决方案是添加一个附加的<span>标记，该标记嵌套在<a>标记内，第二次定义十六进制值。

<a href="/" target="_blank" style="color:#c98702;"><span style="color:#c98702">Act Now</span></a>

Gmail doesn’t see the world in black and white.When using a hex value of #FFFFFF or #000000, or defining a link color as either “black” or “white,” Gmail will still default to blue for these values no matter how many ways you define them — in the<a>tag, in an additional<span>tag, etc.

Gmail看不到黑白的世界。当使用#FFFFFF或＃000000的十六进制值，或将链接颜色定义为“黑色”或“白色”时，无论您使用多种方式定义这些值，Gmail仍默认为蓝色(在<a>标签，其他<span>标签等。

To override blue links in pure black or white text, I replace the text color with a hex value one character off from the standard black and white — i.e. #FFFFF1 or #000001 — and define it in both the<a>tag and additional<span>tag. The difference is subtle enough to pass as black or white to the human eye, and Gmail will honor your color choices.

要覆盖纯黑色或白色文本中的蓝色链接，我将文本颜色替换为与标准黑白(即＃FFFFF1或＃000001)相隔一个字符的十六进制值，并在<a>标记和其他<span>标记。两者之间的差异非常细微，足以让人眼看到黑色或白色，而Gmail会尊重您的颜色选择。

In a similar vein, iOS automatically turns phone numbers, addresses and dates into blue hyperlinks even if you haven’t added an<a>tag.

同样，即使您没有添加<a>标签，iOS也会自动将电话号码，地址和日期转换为蓝色超链接。

Why does it do this?Possibly because it assumes that you’ll want to call, map or add these blocks of text to your calendar. To avoid unwanted/surprise links, again wrap any phone numbers, addresses and other “vulnerable” content with a<span>and manually style it to the color of your choice.

为什么这样做呢？可能是因为它假设您要调用，映射或将这些文本块添加到日历中。为避免不必要的/意外的链接，请再次使用<span>包装所有电话号码，地址和其他“易受攻击”的内容，然后将其手动设置为您选择的颜色。

iOS supports topline CSS and media queries, so if you have a lot of addresses, phone numbers or dates in your email, you can define the color once and add the class throughout your code.

iOS支持顶级CSS和媒体查询，因此，如果电子邮件中有很多地址，电话号码或日期，则可以定义一次颜色，然后在整个代码中添加类。

Outlook和Gmail❤空格 (Outlook and Gmail ❤ whitespace)

Image maps are not widely supported across email clients, so a best practice is to slice images. Note that Outlook and Gmail both add white space around images, which produce a gap-like effect that can cause some aggravation whenever images need to be tightly stacked or flushed.

图像映射在电子邮件客户端中不受广泛支持，因此最佳实践是对图像进行切片。请注意，Outlook和Gmail都在图像周围添加了空白，这会产生类似缝隙的效果，每当需要将图像紧密堆叠或冲洗时，都会造成一些恶化。

Thankfully, adding adisplay:blockstyle to each image will eliminate the extra white space.

值得庆幸的是，为每个图像添加display:block样式将消除多余的空白。

<img src="image.jpg" border="0" style="display:block">

Android上的Gmail应用程序可自行调整宽度 (Gmail App on Android brings its own width to the table)

From time to time, Android will set its own width for cells in a table when viewing the email on the Gmail app. I’ve noticed this in nested tables withtwo or more columns— one column gets all the love and the greater width, while the other is left in a skinny, narrow cell.

在Gmail应用程序上查看电子邮件时，Android会不时为表格中的单元格设置其自己的宽度。我已经在具有两列或更多列的嵌套表中注意到这一点-一列获得了所有的爱和更大的宽度，而另一列则留在了一个狭窄的狭窄单元格中。

Here’s a workaround:

解决方法：

If the cell contains an image of equal width, add a min-width value to the cell.如果单元格包含宽度相等的图像，则将最小宽度值添加到该单元格。 If the cell doesn’t contain elements that make up the fully intended width, add a transparent GIF as the first line of code in the cell, and set the width in the image tag to the desired cell width (yes, coding like it’s 1999). This, in addition to appending the min-width value to the cell, should force it to expand to contain the image and ensure your cells render at the correct width.如果该单元格不包含组成全部预期宽度的元素，请添加透明GIF作为该单元格中的第一行代码，然后将image标签中的宽度设置为所需的单元格宽度(是的，像1999年那样进行编码)。除了将最小宽度值附加到单元格之外，这还应强制其扩展以包含图像，并确保单元格以正确的宽度进行渲染。

<table width="650" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f7fcff"><tr> <td width="240" valign="top" style="background-color:#E4E3DD; min-width:240px;"><a href="/?%%=v(@tracking_parameters)=%%CRM20_M" target="_blank" alias="BODY - Main Image"><img src="/email/images/1073080926_CRM_DedicatedEmail_M_v3_summer2_1.jpg" width="240" alt="20% Off on " border="0" style="display:block;" /></a></td> <td width="410" valign="top" style="background-color:#f7fcff; min-width:410px;"><img src='spacer.gif' width='410' height='1' border='0'></td>...

iOS创建自己的边框 (iOS creates its own borders)

I’ve noticed that this bug occurs whenever a background color or image is applied to rows within a table. iOS inherits the background color, which shows up on the outside of the table as borders then disappears as you zoom in to view it at close range.

我注意到，每当将背景颜色或图像应用于表中的行时，就会发生此错误。 iOS继承了背景色，背景色以边框显示在表的外部，然后在放大以近距离查看时消失。

My workaround:Add an extra wrapping table with the parent background color defined and nest the table and the cells which contain the background color that formerly showed through inside of this, to ensure the entire table gets the intended color assigned to it.

我的解决方法：添加一个额外的包装表，并为其定义父背景色，并嵌套该表和包含以前通过其内部显示的背景色的单元格，以确保整个表都获得为其分配的预期颜色。

Hopefully these suggested bug fixes keep you from banging your head against the wall. Rest assured that more bugs will present themselves as email clients and apps continue to evolve.

希望这些建议的错误修复可以防止您将头撞到墙上。请放心，随着电子邮件客户端和应用程序的不断发展，将会出现更多错误。

Remember that it’s always important to test, test, test — on your favorite devices, in multiple email clients, and in rendering tools like ReturnPath and Litmus. Also remember that it doesn’t hurt to share your own solutions — your peers will thank you when it’s their turn to discover the latest bug.

请记住，在您喜欢的设备上，在多个电子邮件客户端中以及在诸如ReturnPath和Litmus之类的渲染工具中进行测试总是非常重要的。还请记住，共享您自己的解决方案并没有什么害处-当轮到他们发现最新的错误时，您的同行将感谢您。