那么，如果自定义 HTML 属性不是有效的 XHTML，该怎么办？

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

HTML5 将为合法的自定义属性（如 data-myattr=“foo”）提供数据属性类型，因此也许您现在可以开始使用它，并且可以合理地避免将来的名称冲突。

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

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

class="document docId.56 permissions.RW"

您可以使用 JSON 将 HTML 元素与属性相关联，而不是使用自定义属性：

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

至于后果，请参阅SpliFF的回答。

好吧，这取决于您的客户/老板/等。他们是否要求它验证 XHTML？

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

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

使用非标准 HTML 可能会使浏览器以“怪癖模式”呈现页面，在这种情况下，页面的其他部分可能会呈现不同，而其他内容（如定位）可能会略有不同。不过，使用自定义 DTD 可能会解决此问题。

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

也许页面以怪癖模式呈现，也许页面在一些不起眼的移动浏览器上根本没有呈现，也许浏览器会泄漏内存，也许病毒杀手会窒息你的页面，等等，等等。

我知道虔诚地遵循标准可能看起来很势利。然而，一旦你因为不遵循它们而遇到问题，你往往会停止这样想。但是，这为时已晚，您需要使用不同的框架从头开始应用程序......

我见过痴迷于验证的人做比使用简单的自定义属性更糟糕/奇怪的事情：

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

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

真正重要的是，你有正确的嵌套标签，以及正确引用的属性值。

我什至使用自定义标签名称（HTML5 引入的那些，如页眉、页脚等），但这些在 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（区域）
• ssn（社会安全号码）

标记示例：

<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。最好一直保持小写。

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

例如，我需要我的内容是有效的 XHTML，因为很多时候它被转换为各种作业的 XML，然后转换回来，而不会丢失数据或意外的渲染结果。