对于基于 CMS 的网站（客户端将来会更新网站），我是否应该使用过渡性文档类型而不是严格的文档类型？
在任何基于 CMS 的网站中，在我在未来的客户或任何客户的员工（非技术）工作之后，将通过所见即所得编辑器更新网站，并且他们肯定有可能使用已弃用的标签或任何非语义和未经验证的代码。那么在这种情况下，对于基于 CMS 的网站来说，使用过渡性文档类型会比使用严格的文档类型更好吗？
In any CMS based site after my work in future client or any client's staff (non-technical) will update website through WYSIWYG editor and it's surely possible they could use deprecated tag or any non-semantic and non validated code. so in this condition would it be better to use transtional doctype over strict for CMS based site?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据 CMS 中使用的文本编辑器引擎，它可能会生成无效的过渡标记和有效的严格标记。例如，如果您使用 TinyMCE 进行文本编辑，它会生成非常好的 HTML。如果您使用启用了设计模式的普通 iframe，它会在 Internet Explorer 中生成真正的 HTML 混乱。所以我想说，所见即所得控件并不是决定是否使用过渡标记或严格标记的良好标准。
Depending on the text editor engine used in your CMS, it may generate both invalid transitional markup as valid strict markup. For instance, if you use TinyMCE for text editing, it generates quite good HTML. If you use plain iframe with designMode enabled, it generates a real HTML mess out of it in Internet Explorer. So I'd say, WYSIWIG controls is not a good criteria for deciding if to use transitional or strict markup.
我们的 Sitecore 6 网站使用严格的文档类型。默认情况下，Sitecore 不会发布包含无效 html（富文本）字段的项目，并且您可以限制 WYSIWYG 模式下可用的按钮/选项。
We use a strict doctype for our Sitecore 6 site. By default, Sitecore won't publish items that contain invalid html (rich text) fields, and you can limit the buttons/options available in the WYSIWYG mode.
使用 HTML5 文档类型。只是
所见即所得编辑器不能犯错误，但 HTML5 会正常执行并在 XHTML Strict 失败时进行验证。
Use HTML5 doctype. Just
WYSIWYG editors must not make errors, but HTML5 will perform normally and validate when XHTML Strict will fail.
我确信他们会找到一种方法来破坏任何文档类型的验证。所以你不应该关心这个。 这里是一个很好的解释：
如果您想要“安全”标记。丰富您的后端表单。不要只给他们一个纯文本区域。提供图片上传功能。标题、副标题、日期等的不同输入字段。甚至可能切换到 markdown （如果用户无论如何都不知道 html）？与选择最宽容的文档类型相比，这将大大降低标记损坏的风险。
I'm sure the will find a way to break the validation of any doctype. so you shouldn't care about this. Here is a good explanation:
If you want a "safe" markup. enrich your backend form. dont just give them a plain textarea. provide image upload functionality. distinct input fields for heading, subheading, dates ect. Maybe even do a switch to markdown (if the user dont know html anyway)? that will lower the risk of a broken markup much more rather then choosing the most forbearing doctype.