方式验证gmail的HTML代码？

Question

我得到了一些自动生成的HMLT代码。确保http://validator.w3.org/正确解析它，并且它是一个有效的HTML4.01 Strict。

现在，当我将此代码嵌入到电子邮件中并将其发送到gmail时，结果非常不利（弄乱了格式化）。

代码很长，显然只有在它有这么大的时候才会发生。这告诉我两件事：

• 不值得在此处输入代码段
• 它可能是一些冲突的标记，但仍被视为有效的解析器

您是否知道任何更严格的工具来验证我的HTML？甚至可能是gmail特有的东西？

或者，也许只是一些专业提示，通常会解决gmail的代码问题。

ps：代码虽然很长，但也很简单，只有几个表格和样式 - 我确保只使用“电子邮件友好”标签和格式。

Answer 1

你说过风格吗？好家伙！电子邮件客户端的工作方式各不相同，即使你让它为GMail工作，它也可能不适用于雅虎。

您可能希望查看Email CSS guide之类的内容，但实际上您还想使用某些收件箱分析服务（例如Inbox Inspector from MailChimp）来获得更好的图片。

我自己还没有这样做，但我已经看到一遍又一遍地提到这是一个你可能会失去头发的区域。

Answer 2

您必须像1999年一样编写代码，而不必担心与HTML的符合性如此紧密。

Answer 3

不幸的是，有效的HTML不适用于某些（大多数）电子邮件客户端。即使是Gmail也会出于安全原因剥离或忽略某些内容。电子邮件的最佳选择基本上是HTML 3.字体的一些内联样式。我知道<p>代码在Gmail中会中断，一般来说colspan和rowspan无法按预期工作，您必须使用嵌套表格。这些只是我能想到的一些事情。

Answer 4

这里的所有答案都有帮助，但实际问题出在其他地方。

问题出在我想的HTML中，但不完全在我的 HTML中。

事实证明，电子邮件客户端在处理渲染之前会将行包裹得太大，无论是HTML代码还是其他内容，更准确地说，在中间打破标记 - 这解释了为什么只有在报告到达时才发生这种情况一定的长度。

当我查看MailChimp生成的代码（由Alexandre Rafalovitch建议）并注意到它被格式化为quoted-printable时，让我感到惊讶的是，每行都裁剪为75个。

之后很容易在我自己的代码生成器中执行相同的操作。好吧，实际上，我甚至没有格式化为quoted-printable，只是确保它会自行包裹太长的行。

除此之外，我可以说，HTML 4.01严格代码在Gmail客户端中运行得非常好。

希望它有助于1999年后的几代人。

欢呼声。