可以使用未知的HTML标签吗?

Ric*_*gan 37 html html5

如果我弄错了,请纠正我,但AFAIK,标记中未知的HTML标签(即HTML规范中未定义的标签,比如说<foobar>),最终将被视为<div>HTML 5浏览器环境中的常规标签.

我在想:这种做法有多可支持?我的意思是,如果我在标记中使用未知的HTML标记,我会发现什么陷阱?快速恐龙在接下来的几秒钟内扑向我吗?

我问的原因是,如果这些标签遵循<div>,我可能会以更加语义的方式使用这些标签,比如分配识别模块的类名.看看这篇文章,例如,一个.media.现在如果不是将CSS写入目标.media,而是将其作为目标<media>呢?在我看来,这使得标记更具可读性和可维护性,但我确实认为它不是"正确的"HTML.

编辑

为了保持透明,几年前确实发现了这个问题.它已被关闭作为偏离主题,但我觉得我在自己的措辞中有一个有效的观点.我承认,这是一个非常接近的重复,但它是在几年前,所以Web开发人员对该主题的一般环境观可能会发生变化.

iva*_*ese 76

user1309389有一个非常好的答案,我同意对规范的吸引力.但我不同意他们的结论,我认为他们错误地认为制造元素会导致"未定义的行为".我想提出另一种思考方式,根据规范和浏览器如何实际处理组成元素.

到2015年,我们正处于广泛采用的CustomElement规范的边缘,并且可以随时使用polyfill.现在是想要"编造自己的元素"的好时机.在不久的将来,您将能够以完全标准和受支持的方式创建具有您自己选择的标记和行为的新元素,每个人都可以喜欢.但是直到所有浏览器出现这种情况,直到大多数人使用支持的浏览器,你才能利用PolymerX-Tags的辛勤工作项目以近乎标准和大多数人支持的方式检查自定义元素的未来,这是很多人都喜欢的.这可能是"正确的事情".但它没有回答你的问题,坦率地说,我发现"只使用X"或"不做X"比"这里的规范如何涵盖这一点,以及浏览器的作用"更有帮助.所以,这就是我喜欢的.

反对大多数网络开发社区的衷心建议(有时尖叫),过去一年,我一直在使用"化妆"元素,在我的所有生产项目中,没有使用polyfill,我已经拥有没有无法解决的问题(还没有),也没有抱怨.怎么样?依赖于HTMLUnknownElement的标准行为,W3C规范的一部分涵盖了" 虚构 "元素的情况.如果浏览器遇到无法识别的HTML元素,则应该处理它的定义明确且明确的方式,HTMLUnknownElement定义该行为,并且您可以在此基础上构建.HTMLUnknownElement也必须足够强大和正确,以"不破坏网络"<blink>标签.不建议您使用HTMLUnknownElement,但在理论上和实践中,如果您知道自己在做什么,那么这样做绝对没有害处.

那么HTMLUnknownElement是如何工作的呢?它只是HTMLElement接口的扩展,它是所有HTML元素的标准接口.但是,与大多数其他元素不同,HTMLUnknownElement不会添加任何特殊行为 - 您将获得一个原始元素,无任何特殊行为,也不会限制使用规则.该HTMLDivElement接口的工作方式几乎完全一样的方式,扩展HTML元素和增加中几乎没有附加的行为.简而言之,构建自己的元素几乎与使用div或span相同.

我喜欢"化妆"元素是思维方式的转变.你应该根据几个因素使用或发明 HTML元素,从标记到阅读的清晰程度,到浏览器和屏幕阅读器和搜索引擎如何解析代码,到某些代码被某些人"正确"的可能性.客观衡量.我谨慎使用虚构的元素,但我完全按照理查德所描述的方式使用,以使HTML的作者更有意义,而不仅仅是对提取元数据的计算机服务有意义.当在团队中以一致的方式使用时,可以有很大的好处,因为制作元素可以简明扼要地表达它们的用途.

我特别喜欢使用组合元素来指示何时使用JS来定义元素的额外行为.例如,如果我有一个将由JS添加/删除子元素的元素,我将使用一个组合元素作为该元素受特殊行为约束的线索.出于同样的原因,当标准元素足够时,我不使用虚构的元素.你会在我的代码<dynamic-list>旁边看到幸福的生活<div>.

现在,关于那些讨厌的验证者.是的,使用虚构元素并不是"有效",因为它不会通过"验证器".但是现代HTML和JS开发的许多常用功能,模式和系统都失败了所有W3C验证器.验证者不是法律 - 规范是.法律没有约束力 - 所有浏览器中的实现都是.随着HTML的灵活性不断提高,以及浏览器与规范的关系发生了变化,验证器的实用性已经多年来一直在变暗.验证器非常适合那些不熟悉HTML并需要指导的人.但是如果你很乐意从规范和浏览器实现中获得指导,那么就没有理由担心被验证者推倒了.当然,如果您遵循Google,Apple,Microsoft等提供的许多指南来实现任何实验性功能,那么您将在验证者的范围之外工作.这绝对是一件好事,只要你故意这样做,而且你对你正在做的事情了解得足够多.

因此,如果你要构建自己的元素并依赖HTMLUnknownElement,那么不要只把它当作狂野的西部.您需要遵循一些简单的规则.

  1. 您必须在标记的名称中使用连字符.如果您这样做,您将保证永远不会与未来版本的HTML规范发生冲突.永远不要说<wrong>,永远都说<quite-right>.

  2. 制作元素不能自动关闭 - 你必须用一个结束标签关闭它们.你不能只说<wrong><still-wrong />,你必须说<totally-good></totally-good>.

  3. 您必须display在CSS中为元素定义属性,否则渲染行为是未定义的.

就是这样.如果你做这些事情,你应该善于在IE9及更高版本中使用虚构元素,依赖于HTMLUnknownElement的安全网.对我来说,好处远远超过成本,所以我一直在大量使用这种模式.我经营SaaS网站迎合主要的工业企业,到目前为止我没有遇到任何麻烦或抱怨.如果你必须支持IE的旧版本,那么远离任何"2015"技术或其原始近似值是明智的,并且安全地保持在规范中经过深思熟虑的部分.

因此,总而言之,您的问题的答案是"是的,如果您知道自己在做什么".

  • 这里是W3C HTML Checker(验证器)的维护者.我最近添加了对自定义元素的支持.它的要点是检查器不再报告元素名称的错误,例如在其中具有连字符的"完全正确".有关更多详细信息,请参阅http://stackoverflow.com/questions/28508533/w3c-validation-for-ui-select/28711028#28711028 (12认同)
  • 这里的最佳答案实际上回答了问题。 (2认同)

小智 14

您应始终接近HTML,因为它在各自的规范中定义."定义"新标签是一种极端的方法.它可能会通过浏览器检查,因为它实现了各种故障,但不能保证这一点.你充其量只是进入了未定义行为之地.更不用说你将失败验证测试,但你似乎意识到这一点.

如果您希望在标记中更具语义表达能力,可以使用HTML5定义相当多的描述性标记来描述页面结构,而不是div需要附加ids或classes 的泛型s .

最后,一个简短的回答:不,这是不好的做法,你不应该这样做,并且在你的开发中可能会出现无法预料的问题.

  • 后期开发中总会出现不可预见的问题。&lt;future&gt;未来本质上是未知的。&lt;/future&gt; (3认同)
  • Web组件呢? (2认同)

Jef*_*ins 9

不会.您将无法通过验证,您将通过浏览器获得随机问题,您将被所述恐龙吃掉.如果您希望页面的行为可预测,CSS就是答案.


aWe*_*per 8

是的,我们可以.

有一个关于自定义元素/标签的新规范 - http://w3c.github.io/webcomponents/spec/custom/.

唯一的问题是你必须使用js来注册你的新元素

你可以在这里阅读更多相关信息

https://developers.google.com/web/fundamentals/getting-started/primers/customelements