有哪些经常被误用的 html、javascript、css 的元素、方法和属性？
以前想要把一个元素（input 之类的）设成只读的时候都是用 disabled，后来发现这是不对的。 因为在 html 里面，如果一个元素被设置成 disabled， 那么它的值就不会被发送到 server 端。 正确的做法应该是使用 readonly。
那么除了这个 disabled，在 web 开发中还有哪些东西是经常被误用的？
回复内容：
仅说一下 css 方面的吧。
float:left/right 或者 position: absolute 后还写上 display:block，画蛇添足（三者关系：visual formatting model）
不分场景的使用 overflow:hidden 来闭合浮动（详见：那些年我们一起清除过的浮动）
为了让 chrome 这个脑残支持小于12px 的文字，在 html 设置 -webkit-text-size-adjust:none; (最新的桌面版该属性已经被删除了，变更集：changeset 145168)
认为 px 是一个绝对单位（px 是相对单位），整个页面都是 px，line-height 也用 px，全家都是 px
习惯性不分场景的去除 a 标签 focus 时候的焦点
认为布局就是 float，所有的地方都是 float，全家都是 float！（试试 inline-block inline-block 前世今生 吧，试试 flexbox 吧）
满页面都是用 .clearfix 来闭合浮动，如果已经有了bfc为嘛还要在闭合浮动呢？毒害不浅，某浪微博为例，102个 .clearfix
好吧我还是说点其他的吧：
搞不拎清 png 的分类，认为 png24 支持透明，不知道 png8 也支持 α 透明（可以看看：png的秘密）
我又要吐槽 label 不加 for ，或者 for 属性加的不对的问题（请看：雅安地震，前端开发者可以做什么？）
看到@贺师俊老湿说道 ul，ol 滥用的问题，我举一个本来应该用 ol 却写成 ul 的例子：
首页 | 微吧 一起扎堆吧！找反面教材，都去渣浪吧，渣浪你承认不？
查看源码，满屏都是 div 的就不多说了吧……
好吧，我已经原谅你们了，或许你遇到了学习瓶颈：
【update】
写了 xhtml 的 doctype，但是文档连 well-formed 都没做到。比如渣浪微博。腾讯原来也是，不过最近似乎改好了。
【/update】
几乎每个 html 标签都可能被用错，table布局这种我就不说了，下面挑在各互联网大站屡见不鲜的说：
元素方面
1. 滥用 ul、dl
2. 该用 ol 的用 ul
3. 段落不会用 p 只会用 br 和 div
4. 不会用 h1 / h2 / h3 ... 只会用 strong 甚至 div
5. 不会用 label、fieldset、legend
6. 乱用 abbr、cite、q 之类比较少见的标签
7. 不会用或乱用 b / i / s / u 之类在 html5 中重新定义过的标签
属性方面
1. 多 class 症（病入膏肓的表现就是几乎每个元素上都有不止一个 class）
2. img 的 alt 属性没有意义（比如和title属性一样）
3. 混淆 input 的 disabled 属性和 readonly 属性
4. label 元素的 for 属性
5. 不会使用 lang 属性或 lang 属性写成 zh-cn 等已经废弃的用法
没人谈谈js？呃，我今天又听到一种奇怪的说法，所以打算写几句。下面谈到的几点，可以说都是因太过「想当然」，想当然以为如此，却并没有去验证，错误的写法就这样一直流传着。
if(value) 与 if (!!value) 语义上没有任何区别。我反对if (!!value)的写法。 同样无聊的写法还有：if ((var1 == var2) == true)。 if 接受“a condition expression that evaluates to true or false”，并非必须primitivebool类型。 在《ecmascript spec》中，if (value)的语义相当于：if (toboolean(value))。 而logical not的语义相当于：not toboolean(value)。 即 !!val 相当于 toboolean(value)。 也就是说：if (!!value)的语义相当于 if (toboolean(toboolean(value)))。 如果你认为这种写法是合理的，那你为什么不继续写道： if (!!(!!value))、 if (!!(!!(!!value))) ……？
什么时候需要使用logical not “!” 转换类型呢？一般函数传参或返回值有这个必要。如果函数文档中说它返回一个bool类型的值，那么函数作者就有责任保证其返回值的类型为（primitive）bool。因为函数的使用者可能会写出依赖返回值类型的代码：
/**@returns bool*/function has(str,substr) { return !!~str.indexof(substr); //return ~str.indexof(substr); // wrong!!!}//函数使用者的代码：json.stringify({ //此选项值类型早约定为enum(0|1) xxxoptiononoff:+has(s,"xxx") //使用者依赖于bool to number的转换});
同作向函数传参也需要注意类型：
/**@param {bool} flag*/function toggle(flag) { //期望设置classname为 toggle-on-true 或toggle-on-false //尽管不推荐这种过于依赖bool参数类型的代码，但既然文档声明是bool类型 //传参者就有必要保证参数类型正确，即使是js这种弱类型语言 ele.classname= "toggle-on-"+flag;}toggle(!!btn.checked);//toggle(btn.checked); //wrong! btn.checked可能返回string "checked"
第二个，吃力不讨好的人肉gc：
有人喜欢在遇到闭包时人肉gc：
function foo() { var obj={/*may be a big object*/}; return function () { //返回闭包中实际上没用到obj这个变量 //没有用到的变量解释器本可作优化、不去捕获 //但有人担心obj无法被gc，于是硬生生地... obj=null; // 于是解释器反而要将obj捕获了，笑～ return; };}//还有人以为这样写就蛮好：function bar() { var obj={/*may be a big object*/}; //...lots of code obj=null;//那你以为它就*立即*被gc了吗？没有，同样画蛇添足。 // 不过不排除有浏览器没有实现这种优化 return function () {/*闭包中反正用不到obj*/};}
第三个，效率系列，现在应该很少有人犯这些错误了：
以为 && 、 || 比 if 效率高。
以为 while (i) 比 while(i>0) 效率高。
以为 eval 永远效率非常低。
这点已经有这篇文章讨论过：由eval生成的代码效率真的很差吗？
前置、后置的++、--系列的效率差别早在c语言中就被批的体无完肤了。
以为array[i]总比object[p]快，以致错误地使用了sparse array。
...想起了真正毁掉一切array类型推导的：array.prototype[9]="kaka";
以为 …… 反正全都是以为怎么样怎么样。
第四个， `n|0`、`n^0`来取整不是始终ok的，bitwise operators先对operand进行toint32，js中的number是双精度64位浮点数、不止int32。math.pow(2,32)|0 得 0。
想想js的常见错误确实不好找啊，每天修的bug太多了，我能记得的error肯定都是因为它不常见才记得它的啊。html、css写错了浏览器有时一声不吭，js写错了就是写错了啊，错误留在那里迟早要见棺材的。
第五个，和jquery有关的，你的代码中一般不应该出现element.unbind('event')这种bug prone代码。这个调用是解除该事件所有监听函数，但仔细想一想，除非这个元素准备destroy掉了，这种代码一般是不应该出现的。如果该event所有监听函数都是自己绑定的，那你就应该知道当前scene该unbind哪些listeners，很难想象绑定上去的listeners会多到超出管理能力unbind时懒得列举的情形；如果该元素是公共元素，其上会有其它代码bind上去监听函数，那这样写会导致或隐藏错误。而且重要的是，它通常是一个bad design信号，尤其当bind与unbind同时出现时。如果该元素/该场景没有准备destroy，这通常意味着我还会重复bind监听函数。如：
editor.on("show",function () { submitbutton.bind("click",function () { alert("submit!"); //然后发现editor隐藏再show一次，就会alert执行两次 });});editor.trigger("show");//触发一次show事件就会重复绑定一次代码 //为了fix上面的问题，于是……editor.on("show",function () { submitbutton.unbind("click").bind("click",function () { alert("submit!"); });});
没错，是fix了bug，但是，有没有更好的设计方式呢？有个原则是，绑定事件要趁早，根据不同的情况试举例说明，多出的unbind很可能是错误设计的信号：
//最低级的错误是，其实submitbutton的行为不会受到editor状态的影响， 它俩压根没关系submitbutton.bind("click",submitaction); //根本不需要等到show时再绑定editor.on("show",showaction); //另一种情况是，editor show时submitbutton enable，hide时d isablefunction submitaction() {/*……*/}function enablesubmit() { submitbutton.bind("click",submitaction);} function disablesubmit() {submitbutton.unbind("click",submitaction);} editor.on("show",enablesubmit);editor.on("hide",disablesubmit); //那你一定忘记其实应在hide状态将其unbind
因为，bind与unbind本应在相反状态的两个action中出现，如show与hide、enable与disable、on与off；如果不是，通常意味着bind事件与两个状态无关，既然与这些状态无关，为什么还要等状态触发再绑定呢？ 若你发现会bind两次就意味着该状态会进入两次，既然会进入两次，就意味着该状态会退出，既然与状态有关，则应在一「进入」状态绑定，在另一「退出」状态解除，bind与unbind应始终保持这种对称关系，才有利于listeners的维护，避免bug。而当你将bind与unbind分开时，你就会发现自己不会再写出 element.unbind('event') 这样草率的代码。
第六个， +new date 和 0 + new date 是不一样的，当然我觉得这类坑都是js设计上的错误，加法不符合交换律也就罢了，还非要将 date类型特殊处理。
第七个，在prototype上放一个nonprimtive值（object）作为instance属性：
editor.prototype={ width:300, //default width 300 px toolbaritems:["file","edit","help"], //default toolbar items //…… addtoolbaritem:function (item) { this.toolbaritems.push(item); //bug! }};
好像我说的都是语法，都不是属性方法之类的啊。反正先写这么多，以后想起来再补充。
以上就是有哪些经常被误用的html、javascript、css 的元素、方法和属性？的内容。