我知道这是一些人不赞成他们的原因,但这真的重要吗?我认为它们在与 JavaScript 交互以及从服务器存储和向服务器发送信息方面提供的功能超过了验证问题。我错过了什么吗?“无效”HTML 的后果是什么?而且自定义DTD不会解决它们吗?
15 回答
后果是 w3c 在 2、5、10 年后出现,并创建了一个具有相同名称的属性。现在你的页面坏了。
HTML5 将为合法的自定义属性(如 data-myattr="foo")提供数据属性类型,所以也许您现在可以开始使用它,并且在未来的名称冲突中相当安全。
最后,您可能会忽略自定义逻辑是类属性背后的理性。尽管它通常被认为是一种样式属性,但实际上它是在元素上设置自定义元属性的合法方式。不幸的是,您基本上仅限于布尔属性,这就是 HTML5 添加数据前缀的原因。
顺便说一句,“基本上是布尔值”我的意思是原则上。实际上,没有什么可以阻止您在类名中使用分隔符来定义自定义值和属性。
class="document docId.56 permissions.RW"
是的,您可以使用“数据”合法地添加自定义属性。
例如:
<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。最好一直保持小写。
验证本身并不是目的,而是一种用于帮助及早发现错误并减少您的网页在多种浏览器类型上使用时可能面临的神秘渲染和行为问题的工具。
添加自定义属性现在不会影响这些问题中的任何一个,并且将来也不太可能这样做,但是由于它们不验证,这意味着当您评估页面验证的输出时,您将需要仔细挑选重要的验证问题和不重要的验证问题。每次更改页面并重新验证时,都必须重复此操作。如果您的页面完全验证,那么您会收到一条漂亮的绿色 PASS 消息,您可以继续进行下一阶段的测试,或者进行下一个需要进行的更改。
我见过沉迷于验证的人做的事情比使用简单的自定义属性更糟糕/奇怪:
<base href="http://example.com/" /><!--[if IE]></base><![endif]-->
在我看来,自定义属性真的无关紧要。正如其他人所说,提防未来在标准中添加的属性可能会很好。但是现在我们在 HTML5 中有 data-* 属性,所以我们被保存了。
真正重要的是您拥有正确嵌套的标签和正确引用的属性值。
我什至使用自定义标签名称(HTML5 引入的标签名称,如页眉、页脚等),但这些名称在 IE 中存在问题。
顺便说一句,讽刺的是,我经常发现所有那些验证狂热者是如何在谷歌的聪明技巧面前低头的,比如 iframe 上传。
您可以使用 JSON 将 HTML 元素与属性关联,而不是使用自定义属性:
var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };
至于后果,请参阅SpliFF 的回答。
在类属性中存储多个值不是正确的代码封装,而只是一种复杂的 hack 做事方式。以使用 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 可能会被重新设计。
只是为了将我的成分添加到组合中,当您需要创建可以/可以使用自动化工具进行后处理的内容时,验证也很重要。如果您的内容有效,您可以更轻松地将标记从一种格式转换为另一种格式。例如,在解析您知道并且可以验证以遵循可预测格式的数据时,使用特定模式将有效的 XHTML 转换为 XML 会容易得多。
例如,我需要我的内容是有效的 XHTML,因为它经常被转换为 XML 用于各种工作,然后再转换回来而不会丢失数据或出现意外的呈现结果。
好吧,这取决于您的客户/老板/等.. 他们是否需要它来验证 XHTML?
有人说有很多变通方法 - 根据场景,它们可以很好地工作。这包括添加类、利用rel
属性,甚至有人编写了自己的解析器来从 HTML 注释中提取 JSON。
HTML5 提供了一种标准方式来执行此操作,在您的自定义属性前面加上“data-”。无论如何,我建议现在就这样做,因为您可能会使用将在标准 XHTML 中使用的属性。
使用非标准 HTML 可能会使浏览器以“怪癖模式”呈现页面,在这种情况下,页面的某些其他部分可能会呈现不同的呈现方式,并且定位等其他方面可能会略有不同。不过,使用自定义 DTD 可能会解决这个问题。
因为它们不是标准的,所以您不知道现在或将来会发生什么。正如其他人所说,W3C 将来可能会开始使用这些相同的名称。但更危险的是,你不知道“浏览器xxx”的开发者在遇到他们的时候做了什么。
也许页面是以怪异模式呈现的,也许页面在某些不起眼的移动浏览器上根本不呈现,也许浏览器会泄漏内存,也许病毒杀手会阻塞你的页面等等等等。
我知道虔诚地遵循标准可能看起来很势利。但是,一旦您因不遵循它们而遇到问题,您往往会停止那样思考。但是,现在为时已晚,您需要使用不同的框架从头开始您的应用程序......
我认为开发人员验证只是为了验证,但有一些话要说,因为它可以保持标记干净。然而,因为每个(夸张的警告!)浏览器显示的一切都不同,所以真的没有标准。我们试图遵循标准,因为它让我们觉得我们至少有一些方向。有些人认为,保持代码标准可以防止将来出现问题和冲突。我的观点:无论如何,今天没有人正确和完整地实现标准,还不如假设你的所有代码最终都会失败。如果它有效,那么就使用它,除非它很乱,或者你只是试图忽略标准以坚持 W3C 或其他东西。我认为重要的是要记住标准的实施非常缓慢,网络在 5 年内发生了如此大的变化。一世' 我敢肯定,当需要解决潜在冲突时,任何人都会提前数年得到通知。当您甚至不能依赖今天的标准时,没有理由计划未来的标准兼容性。
哦,我差点忘了,如果你的代码没有验证 10 只小猫会死。你是小猫杀手吗?
如果标记无效,则 Jquery .html(markup) 不起作用。
验证
您不需要自定义属性来提供验证。更好的方法是根据字段实际任务添加验证。
通过使用类来分配意义。我有这样的类名:
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" />
. 他们开箱即用。
(确保您不传递任何带有隐藏输入的敏感数据,因为用户几乎可以毫不费力地修改它们)