很久以前,当我发现W3C Validator时,我确保我制作的每个 HTML 文档都是有效的 HTML。
但是,我认为有时没有必要浪费时间使其有效。当然,对于实际的 Internet 页面可能很重要,但是当 HTML 页面在最常用的浏览器中正确呈现时(不一定包括 IE 6 和7)。
我想我主要是在谈论对代码的一些改进,例如将页面的每个显示元素包装在<p>
或<div>
标签上。
很久以前,当我发现W3C Validator时,我确保我制作的每个 HTML 文档都是有效的 HTML。
但是,我认为有时没有必要浪费时间使其有效。当然,对于实际的 Internet 页面可能很重要,但是当 HTML 页面在最常用的浏览器中正确呈现时(不一定包括 IE 6 和7)。
我想我主要是在谈论对代码的一些改进,例如将页面的每个显示元素包装在<p>
或<div>
标签上。
让页面本身验证并不是真正的商业主张。最终用户(使用他们古怪的浏览器)会发生什么才是真正的考验。
也就是说,定期验证将帮助您进行调试。它将捕获更显着的错误,例如未关闭的标签。反过来,这确实会影响最终用户。因此,将验证视为编译器警告 - 有利于纪律。
这是最佳实践,但实际上归结为组织要求/愿望。标准为您的组织增加价值是否足够重要?或者它是否足以正确显示?通常使用 Intranet 是后者。
如果您打算对未来友好,那么让 HTML 页面“有效”是值得的。也就是说,当浏览器开始去除不推荐使用的或供应商特定的标签时,您会发现您的页面显示不正确。
Web 标准的存在是有原因的——确保 Web 浏览器和解释器之间的显示/输出一致。选择使用不兼容的 HTML 编写页面是您的决定。用一句老话来说,这也是你的“葬礼”。
当 Intranet 选择的浏览器发生变化时会发生什么?确实没有办法保证您拥有的代码将在每个浏览器中正确呈现。但在很多情况下,浏览器会相当接近标准。我认为这还取决于页面的复杂程度,因为随着 CSS 和标签深度的复杂性增加,它在不同浏览器中呈现不同的可能性也会增加。最好的方法是编写有效的跨浏览器代码并针对目标浏览器进行测试。认为所有浏览器都可以一次写入并在任何地方渲染相同的想法是愚蠢的。但遵守标准是您接近的最佳方式。