那么，如果自定义 HTML 属性不是有效的 XHTML 又会怎样呢？

小开

最佳答案

这样做的后果是，w3c 将在2年、5年、10年后出现，并创建一个同名的属性。现在你的页面坏了。

HTML5将为合法的自定义属性(比如 data-myattr = “ foo”)提供一个 data 属性类型，所以也许您现在就可以开始使用它，并且在未来的名称冲突中相当安全。

最后，您可能忽略了自定义逻辑是 class 属性背后的理性。虽然它通常被认为是一种样式属性，但实际上它是一种在元素上设置自定义元属性的合法方法。不幸的是，您基本上仅限于布尔属性，这就是 HTML5添加数据前缀的原因。

顺便说一句，我说的“基本布尔”是指原则上。实际上，没有什么可以阻止您在类名中使用分隔符来定义自定义值和属性。

class="document docId.56 permissions.RW"

小开

可以不使用自定义属性，而是使用 JSON 将 HTML 元素与属性关联起来:

var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };

至于后果，见斯普利夫的回答。

小开

这取决于你的客户/老板/等... 他们是否要求验证 XHTML？

有些人说有很多变通方法——根据场景的不同，它们可以很好地工作。这包括添加类，利用 rel属性，甚至还有人编写了自己的解析器来从 HTML 注释中提取 JSON。

HTML5提供了一种标准的方法来实现这一点，在您的自定义属性前面加上“ data-”。无论如何，我建议现在就这样做，因为您可能会使用标准 XHTML 中将要使用的属性。

小开

使用非标准的 HTML 可以使浏览器以“怪异模式”呈现页面，在这种情况下，页面的其他部分可能呈现不同，其他事情如定位可能略有不同。不过，使用自定义 DTD 可能会绕过这个问题。

小开

因为它们不是标准的，你不知道会发生什么，现在不知道，将来也不知道。正如其他人所说，W3C 可能在未来开始使用这些相同的名称。但更危险的是，你不知道“浏览器 xxx”的开发人员在遇到他们时做了什么。

也许这个页面是以怪异的模式呈现的，也许这个页面在某个晦涩的移动浏览器上没有以所有的速度呈现，也许浏览器会泄露内存，也许一个病毒杀手会在你的页面上窒息，等等，等等。

我知道虔诚地遵守标准可能看起来像是势利。然而，一旦你因为没有跟随他们而经历了问题，你就会倾向于停止这样的思考。然而，这样做大多为时已晚，您需要使用一个不同的框架从头开始您的应用程序..。

小开

我见过一些痴迷于验证的人，他们做的事情比使用一个简单的自定义属性要糟糕/怪异得多:

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

在我看来，自定义属性真的无关紧要。正如其他人所说，注意标准中未来添加的属性可能是有益的。但是现在我们在 HTML5中有了 data-* 属性，所以我们得到了保存。

真正重要的是您有正确嵌套的标记和正确引用的属性值。

我甚至使用自定义标记名称(那些由 HTML5引入的名称，比如 header、 footer 等) ，但这些名称在 IE 中存在问题。

顺便说一句，我经常发现具有讽刺意味的是，所有这些验证狂热者是如何在谷歌的巧妙技巧面前低头的，比如 iframe 上传。

小开

有效性的事情是今天可能不重要，但是你不知道明天是否会重要(根据墨菲定律，明天会重要)。

只是最好选择一个未来的替代品。如果它们不存在(他们在这个特殊的情况下) ，那么要做的就是发明一种未来证明的替代方案。

使用自定义属性可能是无害的，但是，为什么仅仅因为您认为(您永远不能确定)它不会造成损害而选择潜在的有害解决方案呢？.如果未来的证明方案过于昂贵或难以操作，可能值得进一步讨论，但情况肯定不是这样。

小开

我认为开发人员验证只是为了验证，但是有一些事情需要说明，它保持了标记的整洁。但是，因为每一个(夸张警告!) 浏览器显示的一切都不一样真的没有标准。我们努力遵循标准，因为它让我们觉得我们至少有一些方向。有些人认为，保持代码标准将防止未来出现问题和冲突。我的观点是: 如果今天没有人正确、完整地实现标准，那么不妨假设所有代码最终都会失败。如果它工作，使用它，除非它的混乱或你只是试图忽略标准，坚持它的 W3C 或东西。我认为重要的是要记住，标准的实施是非常缓慢的，网络在5年内已经发生了很大的变化。我相信任何人在需要解决潜在冲突时都会提前数年通知。当您甚至不能依赖当今的标准时，就没有理由计划未来标准的兼容性。

哦，我差点忘了，如果你的代码不验证10只小猫将死亡。你是一个小猫杀手吗？

小开

验证本身并不是目的，而是一个工具，用于帮助及早发现错误，减少在多种浏览器类型上使用网页时可能面临的神秘渲染和行为问题。

添加自定义属性现在不会影响这两个问题，将来也不太可能影响，但是因为它们不会验证，这意味着当你要评估页面验证的输出时，你需要仔细地在重要的验证问题和不重要的验证问题之间做出选择。每次更改页面并重新验证时，都必须重复此操作。如果您的页面完全验证，那么您将得到一个漂亮的绿色 PASS 消息，并且您可以进入下一个测试阶段，或者进入下一个需要进行的更改。

小开

如果加价无效，则 Jquery. html (标记)无法工作。

小开

在 class 属性中存储多个值不是正确的代码封装，只是一种复杂的处理方法。以使用 jquery 的自定义广告旋转器为例。这样做在页面上更干净

<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />

并让一些简单的 jquery 代码从这里开始工作。任何开发人员或网页设计师现在可以工作的广告旋转器和改变的价值，这时要求没有多少废话。

一年后回到项目中，或者进入一个新的项目，之前的开发人员分开去了太平洋上的某个岛屿，当代码以这种不明确的加密方式编写时，想要弄清楚他们的意图可能会非常困难:

<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes"  />

当我们使用 c # 和其他语言编写代码时，我们不会将所有自定义属性放在一个属性中作为一个空格分隔的字符串，并且最终在每次需要访问或写入该字符串时都必须解析该字符串。想想下一个将为您的代码工作的人。

小开

尽管有些陈旧的讨论，但是在我看来，由于 html 是一种标记语言，而不是一种编程语言，因此应该对标记“错误”进行宽容的解释。浏览器完全可以做到这一点。我不认为这会改变，也不应该改变。因此，唯一重要的实际标准是大多数浏览器能够正确显示 html，并且这种情况会持续几年。在那之后，您的 html 可能会被重新设计。

小开

确认

您不应该需要自定义属性来提供验证。更好的方法是根据字段实际任务添加验证。

通过使用类来赋予意义。我有一些类名，比如:

date(日期)
zip(邮政编码)
area(地区)
社会保险号码

示例标记:

<input class="date" name="date" value="2011-08-09" />

示例 javascript (使用 jQuery) :

$('.date').validate(); // use your custom function/framework etc here.

如果您需要针对某个特定或场景的特殊验证器，那么您只需为您的特殊情况:

检查两个密码是否匹配的示例:

<input id="password" />
<input id="password-confirm" />


if($('#password').val() != $('#password-confirm').val())
{
// do something if the passwords don't match
}

(这种方法可以与 jQuery 验证和 mvc.net 框架以及其他框架无缝连接)

额外的好处: 您可以分配多个用空格 class = “ ssn custom- one custom- two”分隔的类

向服务器发送信息

如果您需要传递数据回来，使用 <input type="hidden" />。

(确保不要传递任何带有隐藏输入的敏感数据，因为用户几乎不费吹灰之力就可以修改这些数据)

小开

是的，您可以通过使用“数据”合法地添加自定义属性。

例如:

<div id="testDiv" data-myData="just testing"></div>

之后，只需要使用最新版本的 jquery 来执行以下操作:

alert($('#testDiv').data('myData'))

或设置数据属性:

$('#testDiv').data('myData', 'new custom data')

而且因为 jQuery 几乎可以在所有浏览器中工作，所以应该不会有任何问题;)

更新

就 javascript 引擎而言，在某些浏览器中，data-myData 可以转换为 data-myData。最好一直小写。

小开

只是添加我的成分组合，验证也很重要，当您需要创建内容，可以/可以后处理使用自动化工具。如果您的内容是有效的，您可以更容易地将标记从一种格式转换为另一种格式。例如，使用特定的模式从有效的 XHTML 转换为 XML，在解析已知并可以验证的数据以遵循可预测的格式时要容易得多。

例如，我需要我的内容是有效的 XHTML，因为它经常被转换成各种作业的 XML，然后在没有数据丢失或意外呈现结果的情况下转换回来。