我知道这就是某些人不同意的原因,但这真的重要吗?我认为,他们在与JavaScript交互以及从服务器存储信息以及向服务器发送信息时所提供的功能胜过了验证方面的考虑。我想念什么吗?“无效” HTML的后果是什么?而且自定义DTD是否也无法解决它们?
我知道这就是某些人不同意的原因,但这真的重要吗?我认为,他们在与JavaScript交互以及从服务器存储信息以及向服务器发送信息时所提供的功能胜过了验证方面的考虑。我想念什么吗?“无效” HTML的后果是什么?而且自定义DTD是否也无法解决它们?
Answers:
后果是w3c出现于2、5、10年,并创建了一个具有相同名称的属性。现在,您的页面已损坏。
HTML5将为合法的自定义属性提供数据属性类型(例如data-myattr =“ foo”),因此也许您现在就可以开始使用它,并且在将来不会出现名称冲突的情况下也相当安全。
最后,您可能忽略了自定义逻辑是class属性背后的合理性。尽管通常将其视为样式属性,但实际上这是在元素上设置自定义元属性的合法方法。不幸的是,您基本上只限于布尔属性,这就是HTML5添加数据前缀的原因。
顺便说一句,“基本布尔”是我原则上的意思。实际上,没有什么可以阻止您在类名称中使用分隔符来定义自定义值和属性的。
class="document docId.56 permissions.RW"
class="thingType.image"
->考虑定位.thingType.image{}
或$('.thingType.image')
。
是的,您可以使用“数据”合法添加自定义属性。
例如:
<div id="testDiv" data-myData="just testing"></div>
之后,只需使用最新版本的jquery即可执行以下操作:
alert($('#testDiv').data('myData'))
或设置数据属性:
$('#testDiv').data('myData', 'new custom data')
而且由于jQuery几乎可以在所有浏览器中使用,所以您应该不会有任何问题;)
更新
我已经看到人们迷恋于验证,而不是使用简单的自定义属性来做更糟糕/奇怪的事情:
<base href="http://example.com/" /><!--[if IE]></base><![endif]-->
我认为,自定义属性确实无关紧要。就像其他人所说的那样,当心将来在标准中添加属性可能会很好。但是现在我们在HTML5中具有data- *属性,因此已保存。
真正重要的是,您具有正确嵌套的标记和正确引用的属性值。
我什至使用自定义标签名称(由HTML5引入的自定义标签名称,例如页眉,页脚等),但这些名称在IE中存在问题。
顺便说一句,我经常具有讽刺意味的是,所有这些验证狂热分子如何在Google巧妙的技巧(例如iframe上传)面前屈服
除了使用自定义属性,您还可以使用JSON将HTML元素与属性相关联:
var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };
至于分支,请参阅SpliFF的答案。
在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#和其他语言编写代码时,我们不会编写将所有自定义属性放在一个属性中作为空格分隔的字符串的代码,而最终每次需要访问或写入它时,都必须解析该字符串。考虑下一个可以处理您的代码的人。
进行验证的事情是,今天可能不重要,但是您不知道明天是否会重要(并且根据墨菲定律,明天就很重要)。
最好选择一个面向未来的替代方案。如果它们不存在(在这种情况下确实存在),那么要走的路是发明一个可以证明未来的方法。
使用自定义属性可能是无害的,但是,为什么仍然仅仅因为您认为(永远无法确定)它不会造成任何危害而选择一种可能有害的解决方案?如果将来的证明替代方案太昂贵或太笨拙,则可能值得进一步讨论,但是事实并非如此。
只是为了添加我的成分,当您需要创建可以/可以使用自动化工具进行后处理的内容时,验证也很重要。如果您的内容有效,则可以更轻松地将标记从一种格式转换为另一种格式。例如,在解析您知道并且可以验证遵循可预测格式的数据时,使用特定架构对XML执行有效的XHTML变得容易得多。
例如,我需要我的内容是有效的XHTML,因为通常它会针对各种作业转换为XML,然后再转换回而不会丢失数据或出现意外的渲染结果。
使用非标准HTML可能会使浏览器以“怪癖模式”呈现页面,在这种情况下,页面的其他某些部分可能呈现不同的外观,而其他诸如定位的内容可能会略有不同。但是,使用自定义DTD可能会解决此问题。
因为它们不是标准的,所以您不知道现在或将来会发生什么。正如其他人所说,W3C将来可能会开始使用这些相同的名称。但是,更危险的是,您不知道“浏览器xxx”的开发人员在遇到他们时会做些什么。
也许页面怪癖模式呈现,也许页面没有在渲染都在一些不起眼的手机浏览器,可以是浏览器将导致内存泄漏,可能是病毒杀手会呛你的网页,等,等,等上
我知道,虔诚地遵守这些标准似乎很势利。但是,一旦由于不关注而遇到问题,您往往会停止这样的思考。但是,这几乎为时已晚,您需要使用其他框架从头开始应用程序...
我认为开发人员只是为了验证而进行验证,但是对于它可以保持标记清晰的事实,有话要说。但是,由于每个(夸大警告!)浏览器都以不同的方式显示所有内容,因此实际上没有标准。我们尝试遵循标准,因为它使我们感到至少有一些方向。有人认为保持代码标准将防止将来出现问题和冲突。我的意见:不管怎么说,今天没人正确正确地全面实施标准,不妨假设所有代码最终都会失败。如果它可行,请使用它,除非它凌乱不堪,或者您只是想忽略标准以使其坚持W3C之类。我认为重要的是要记住,标准的实施非常缓慢,网络在5年内发生了很大变化。一世' 确保任何人在需要解决潜在冲突时都会有多年的通知。当您甚至不能依靠当今的标准时,就没有理由计划将来的标准兼容性。
哦,我差点忘了,如果您的代码不验证10只小猫会死。你是小猫杀手吗?
您不需要自定义属性即可提供验证。更好的方法是根据字段实际任务添加验证。
使用类分配含义。我有这样的类名:
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" />
。他们开箱即用。
(确保您不会通过隐藏的输入传递任何敏感数据,因为用户几乎可以毫不费力地修改它们)