What are some frequently misused HTML, JavaScript, and CSS elements, methods, and attributes?

What are the elements, methods and methods of HTML, Javascript and CSS that are often misused? Attributes?

In the past, when I wanted to make an element (such as input) read-only, I used disabled, but later I found that this was wrong. Because in HTML, if an element is set to disabled, its value will not be sent to the server. The correct approach should be to use readonly.

So besides disabled, what other things are often misused in web development?

Reply content:

Let’s just talk about CSS.

Float:left/right or position: absolute is followed by display:block, which is superfluous (relationship between the three: Visual formatting model)

5. Do not use the lang attribute or lang Attributes are written as zh-CN and other obsolete usages

No one talks about JS? Well, I heard another strange statement today, so I decided to write a few sentences. It can be said that the following points are all taken for granted because they were taken for granted but were not verified. The wrong way of writing has been spread like this.

There is no semantic difference between if(value) and if (!!value).  I object to the way if (!!value) is written.
 The same boring way of writing is: if ((var1 == var2) == true).
 if accepts "A condition expression that evaluates to true or false" and does not have to be of type PrimitiveBool.
 In "ECMAScript Spec", the semantics of if (value) is equivalent to: IF (ToBoolean(value)).
 The semantics of Logical Not are equivalent to: not ToBoolean(value).
 That is, !!val is equivalent to ToBoolean(value).
 In other words: the semantics of if (!!value) is equivalent to IF (ToBoolean(ToBoolean(value))).
 If you think this way of writing is reasonable, then why don't you continue to write:
 if (!!(!!value)),
 if (!!(!!(!!value)))
 ...?  

When do you need to use Logical Not “!” conversion type? This is generally necessary when functions pass parameters or return values. If the function documentation says that it returns a value of type Bool, then the function author is responsible for ensuring that the return value is of type (Primitive) Bool. Because users of functions may write code that depends on the return value type:

/**@returns Bool*/function has(str,substr) {
   return !!~str.indexOf(substr);
   //return ~str.indexOf(substr); // wrong!!!}//Function user code: JSON.stringify({
   //The value type of this option was originally agreed to be Enum(0|1)
   xxxOptionOnOff:+has(s,"xxx") //Users rely on the conversion of Bool to Number});

Same as passing parameters to functions, you also need to pay attention to the type:

/**@param {Bool} flag*/function toggle(flag) {
   //Expect to set className to toggle-on-true or toggle-on-false
   //Although this kind of code that relies too much on the Bool parameter type is not recommended, since the document declares the Bool type
   //It is necessary for the parameter passer to ensure that the parameter type is correct, even in a weakly typed language like JS
   ele.className= "toggle-on-"+flag;}toggle(!!btn.checked);//toggle(btn.checked);
 //wrong! btn.checked may return String "checked"

Second, thankless human GC:
Some people like to human GC when encountering closures:

function foo() {
   var obj={/*May be a big object*/};
   return function () {
     //The variable obj is not actually used in the return closure
     //The unused variable interpreter could have been optimized and not captured.
     //But some people are worried that obj cannot be GCed, so they forcefully...
     obj=null; // So the interpreter will capture obj instead, laugh~
     return;
   };}//Some people think it’s good to write like this: function bar() {
   var obj={/*May be a big object*/};
   //...lots of code
   obj=null;//Then do you think it will be GC *immediately*?  No, it’s just superfluous.
   // However, it is not ruled out that some browsers do not implement this optimization.
   return function () {/*Obj is not used in closures anyway*/};}

The third, efficiency series, now there should be very few people making these mistakes:

I think && and || are more efficient than if.

I think while (i) is more efficient than while (i>0).

Think eval is always very inefficient.
This has been discussed in this article: Is the code generated by eval really inefficient?

The efficiency difference between the prefixed and postfixed ++ and — series has been thoroughly criticized in the C language.

I think array[i] is always faster than object[p], so I mistakenly use Sparse Array.
…remembering what really ruined all Array type derivation: Array.prototype[9]=”KAKA”;

I thought… Anyway, it was all about what I thought.

The fourth one, `n|0`, `n^0` is not always OK to round. Bitwise Operators first performs ToInt32 on Operand. Number in JS is a double-precision 64-bit floating point number. Not just Int32. Math.pow(2,32)|0 gets 0.

Think about the common errors in JS that are really hard to find. You need to fix them every day.There are too many bugs. The Errors I can remember must be because they are uncommon. If HTML and CSS are written incorrectly, the browser will sometimes be silent. If JS is written incorrectly, it is simply written incorrectly. If the error is left there, it will end up in the coffin sooner or later.

The fifth one is related to jQuery. Bug prone code like element.unbind('event') should generally not appear in your code. This call is to unblock all listening functions for the event, but if you think about it carefully, unless the element is ready to be destroyed, this kind of code should generally not appear. If all the listening functions of the event are bound by themselves, then you should know which listeners should be unbind in the current Scene. It is difficult to imagine that there will be so many bound listeners that it exceeds the management capacity and you are too lazy to list them when unbinding; if the element is For public elements, other code will be bound to listen for functions. Writing this way will cause or hide errors. And importantly, it is usually a Bad Design signal, especially when bind and unbind occur at the same time. If the element/scene is not ready for destruction, this usually means I also repeat the bind listener function. For example:

editor.on("show",function () {
   submitButton.bind("click",function () {
     alert("Submit!"); //Then if the editor is hidden and shown again, the alert will be executed twice.
   });});editor.trigger("show");//When the show event is triggered once, the code will be bound again
 //In order to fix the above problem, so...editor.on("show",function () {
   submitButton.unbind("click").bind("click",function () {
     alert("Submit!");
   });});

Yes, the bug is fixed, but is there a better design? One principle is to bind events as early as possible. Give examples based on different situations. Extra unbinds are likely to be a signal of wrong design:

//The lowest level error is that in fact the behavior of submitButton will not be affected by the editor status.
 They have nothing to do with each other submitButton.bind("click",submitAction);
 //There is no need to wait until show before binding editor.on("show",showAction);
 //Another situation is, submitButton enable when editor show, d when hide
 isablefunction submitAction() {/*……*/}function enableSubmit() {
 submitButton.bind("click",submitAction);}
 function disableSubmit() {submitButton.unbind("click",submitAction);}
 editor.on("show",enableSubmit);editor.on("hide",disableSubmit);
 //Then you must have forgotten that it should be unbind in the hide state

Because bind and unbind should appear in two Actions in opposite states, such as show and hide, enable and disable, on and off ; If not, it usually means that the bind event has nothing to do with the two states. Since it has nothing to do with these states, why wait for the state to trigger before binding? If you find that it will bind twice, it means that the state will enter twice. Since it will enter twice, it means that the state will exit. Since it is related to the state, it should be bound in one “entering” state and in another. The “exit” state is released. Bind and unbind should always maintain this symmetrical relationship to facilitate the maintenance of listeners and avoid bugs. And when you separate bind from unbind, you will find that you will no longer write sloppy code like element.unbind('event').

Sixth, +new Date and 0 + new Date are different. Of course, I think this kind of pitfalls are errors in JS design. It’s just that the addition does not comply with the commutative law. The Date type needs to be treated specially.

Seventh, put a NonPrimtive value (Object) on the Prototype as the Instance attribute:

Editor.prototype={
   width:300, //default width 300 px
   toolbarItems:["File","Edit","Help"], //default toolbar items
   //…
   addToolbarItem:function (item) {
     this.toolbarItems.push(item); //Bug!
   }};

It seems that what I am talking about is syntax, not attribute methods or the like. Anyway, I’ll write this much now, and I’ll add more when I think of it later.

The above are the elements, methods and attributes of HTML, Javascript and CSS that are often misused? For more related content, please pay attention to the PHP Chinese website (www.php1.cn)!