The previous day, IEBlog mentioned that implementing intercommunication is not just about standards. It cited some considerations about the de facto standards-the so-called "de facto standards", that is, they are not standards, but everyone follows it to do things. The previous day, IEBlog mentioned that implementing intercommunication is not just about standards. It cited some considerations about the de facto standards-the so-called "de facto standards", that is, they are not standards, but everyone follows it to do things.
These De facto standards are often formed by mutual compromise between the parties when there is no standard for a thing. Interestingly, as a result of compromise, these "de facto standards" are often not in coordination with other things; what is actually called "standard" is often generated after many things happen, so there is a feeling that "de facto standards" and "standards" are out of place almost everywhere.
After talking nonsense for a long time, I should be right:
In the blog post at the beginning of this article, I mentioned a syntax problem about regular expressions:
Such as "/]/". Because "]" is a part of the syntax that matches any of these characters, therefore, the ECMAScript standard marks this form as an "invalid expression"-but at the same time, this method is not easy to understand due to its simple structure, therefore, in most browsers, such use is considered "valid.
When the development team of IE9 started testing their new JavaScript Engine "Chakra", they found that some JavaScript code that was originally running well could not run in "Chakra, one of the reasons is that the initial "Chakra" was implemented according to the ECMAScript standard, and the old code contains a lot of things that are ineffective in the standard-to be compatible, in addition, what "Connect" and "Chakra" need to do is not only be consistent with the standard, but also be able to recognize such expressions.
This is a good example of "Implementing interoperability is not just about standards.
In addition to this, some other fact standards in JavaScript, such:
In a string, if a line feed mark is entered after the Backslash "", whether it is [LF] (actually meaning) or [CR] (actually meaning ), or [CR] [LF] (\ n actually represents the meaning), will be completely ignored together with the backslash-"ignored" is not accurate enough, it may be said that "this combination will be considered to be a string split into multiple lines of code.
If this is still difficult to understand (or even inexplicable), some code examples should be easier to understand.
For example, the following code:
The Code is as follows:
Var s = "This is \
One line string .";
Actually it is
The Code is as follows:
Var s = "This is an" +
"One line string .";
Equivalent.
If you write
The Code is as follows:
Var s = "This is
One line string ."
A syntax error occurs because the "unended string" is returned ".
At the beginning, it was only a unique feature of the JScript engine used in IE, but now several mainstream browsers support this method, as I mentioned earlier, it is also one of the "de facto standards.
I am very interested in talking about some things about "de facto standards", but there are too many things. I only know a small part of them-and I often cannot remember them, so I can only write it here today. If I remember something, I may write another blog post.