De facto standard The world's incredible facts standard _ Basics

A few days ago, IEBlog mentioned that interoperability is not just about standards, but that there are some considerations of de facto standards-the so-called "de facto standard", which is not a standard, but that everyone follows the one thing it does.

These de facto standards (also written "De facto standard") tend to be formed when a certain thing has not yet been established by mutual compromise between the parties, interestingly, as a result of compromise, these "de facto standards" themselves tend to be uncoordinated with other things, and are really called " Standard "Things often happen after a lot of things have happened, so almost everywhere there is a" de facto standard "and" standard "some sense of incompatibility.

Say a long time nonsense, should say the topic:

In the post in the link at the beginning of this article, a syntax question about regular expressions is mentioned:

Like the "/]/" form, since "]" itself is part of the syntax for "matching any of these characters", the ECMAScript standard marks such a form as an "invalid expression"--but at the same time such usage is not easily ambiguous because it is simple to understand. So it's actually used in most browsers to be considered "effective."

When IE9 's development team started testing their new JavaScript engine "Chakra," they found that some of the JavaScript code that would have been running well could not be run in "Chakra," one of the reasons was the initial "Chakra" is implemented according to the ECMAScript Standard, and the old code contains many things that are not valid in the standard-to be compatible, and "interworking", "Chakra" need to do is not just consistent with the standard, but also to recognize such expressions.

This is a good example of "realizing interoperability is not just a standard."

In addition to this, some of the other factual criteria in JavaScript, for example:

In a string, if you enter a newline tag after the backslash "\", either [LF] (what the actual representative means), or [CR] (\ r) or [CR][LF] (\ r \ n actually represents), is completely ignored along with the backslash-say "ignore" is not accurate enough, perhaps it should be said that "this combination will be considered as a string in multiple lines of code" and so on.

If this is still difficult to understand (or even inexplicable), some code examples should be easier to understand.

For example, this code:

Copy Code code as follows:

var s = "This is an\
One line string. ";

is actually and

Copy Code code as follows:

var s = "This is a" +
"One line string.";

Equivalent.
And if you write

Copy Code code as follows:

var s = "This is an
One line string. "

A syntax error is generated because of the "unfinished string."

At first it was just a feature unique to the JScript engine used in IE, but it is now supported by several major browsers, as I have just mentioned, and it is one of the "de facto standards".

I'm interested in speaking more about the "de facto standard" thing, but this thing is too much, I only know a small part of it-and often not remember, so today I can only write here, if I think of something else may write another article New Boven bar