您可以为电子邮件中的丰富HTML格式提供哪些指导,同时在许多客户端和基于Web的电子邮件界面中保持良好的视觉稳定性
关于Stack Overflow问题的一个不相关的答案表明:
http://www.campaignmonitor.com/blog/archives/2008/05/2008_email_design_guidelines.html
其中包含以下准则:
<body>而不是<head><head>或中<body>,还是使用该style=""属性分配的荣誉内联样式我也有一些"未经证实"的事实,我不记得我在哪里阅读它们.
我想从战壕中获得更多的指导和经验,充实这份清单.
你能提供进一步的建议吗？
更新:我特别要求HTML中的设计部分指南和一致性.有关避免垃圾邮件过滤器的一般准则以及常见礼节的问题已经在SO上.
我在Visual Studio 2008项目中有一堆Velocity模板文件,问题是尽管扩展名.vm不是.xml或类似,但Visual Studio认为它们包含的HTML必须符合XML命名标准并产生错误(不仅仅是每个编译都会发出警告.
如何告诉Visual Studio忽略这些"错误的"XML文件？我愿意转而对XML进行所有验证,但我也没有找到这样的选项.
更新,错误不会停止构建,他们只是淹没了大约20个验证错误背后的真正错误.我似乎记得在VS 2005中关闭验证的选项,但我在VS 2008中找不到任何此类选项.
我接受将##文件的开头添加为答案,即使它很难看,它也可以解决问题.谢谢你!
更新2我以为我在Marc之前尝试过你的答案,发现它没有被正确记住.但是现在我再次尝试它确实运行得很好,而且比为每个文件添加注释更清晰.重新奖励接受的答案.
我已经阅读了Google和SO提供的大部分文献(如果我错过了某些内容,请更正我).
我想要做的是使用资源本地化MVC站点,我想要强类型资源文件(ResX)的编译时安全性,但是ASP.NET 2.0资源提供者模型的灵活性,或类似的东西.我不介意做一些工作,但似乎我所研究的所有路径导致死路一条.
为了在视图中显示本地化文本,我可以一起帮助从HttpContext.Get(全局|本地)ResourceObject中提取资源,但是在模型验证和脚手架方面我无处可去,我想我可以继承属性并提供数据但是因为它意味着从HttpContext中提取东西,我怀疑在激活属性时它是可用的.
由于MVC中的方向本地化似乎是针对ResX文件而远离2.0资源提供者模型,因此我可以尝试将自己注入ResXFileCodeGenerator生成的类中,并使用自定义ResXFileCodeGenerator来提供我自己的ResourceProvider,但这非常属于hackish涉及自定义Visual Studio插件和代码生成.
所以我的问题基本上就是灵活的MVC本地化的故事是什么？
参考文献如下: