De facto standard The incredible fact standard in the world_Basic knowledge

IEBlog mentioned a few days ago that achieving interoperability does not rely solely on standards, which cited some considerations about de facto standards - the so-called "de facto standards", that is, not Standard, but something that everyone follows to do things.

These de facto standards (also written as "De facto standards") are often formed by mutual compromise between the parties involved when there is no standard for a certain thing - interestingly, as a compromise As a result, these "de facto standards" themselves are often inconsistent with other things; and what is truly called a "standard" is often produced only after a lot of things have happened, so there are "de facto standards" almost everywhere. "standard" and "standard" feel a little out of place.

After talking nonsense for a long time, it’s time to get to the point:

In the blog post linked at the beginning of this article, a grammatical issue about regular expressions is mentioned:

Forms like "/]/", because "]" itself is part of the syntax of "match any of these characters", the ECMAScript standard marks such a form as an "invalid expression" ” - But at the same time, due to its simple composition, such usage is not easy to cause ambiguity in understanding, so in fact, it is considered “valid” in most browsers.

When the IE9 development team first started testing their new JavaScript engine "Chakra", they found that some JavaScript code that originally ran well could not run in "Chakra". One of the reasons was that the original "Chakra" It is implemented in accordance with the ECMAScript standard, and the old code contains many things like this that are invalid in the standard - to be compatible and "interoperable", "Chakra" needs to not only be consistent with the standard, but also can recognize such expressions.

This is a good example of "achieving interoperability requires more than standards alone".

In addition to this, there are some other de facto standards in JavaScript, such as:

In a string if a newline mark is entered after the backslash "", either [LF] ( actual meaning), or [CR] ( the actual meaning), or [CR][LF] ( n actually represents), will be completely ignored along with the backslash - saying "ignored" is not accurate enough, maybe it should be said "this combination will be considered as splitting a string across multiple lines of code" Something like that.

If you still find it hard to understand (or even inexplicable) after saying this, it should be easier to understand through some code examples.

For example, this code:

Copy the code The code is as follows:

var s = "This is an
one line string.";

is actually the same as

Copy code The code is as follows:

var s = "This is an"
" one line string.";

Equivalent.
And if written as

Copy code The code is as follows:

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

will generate a syntax error because of "unterminated string".

At the beginning, it was just a feature unique to the JScript engine used in IE, but now several major browsers support this writing method. As I just mentioned, it is also " One of the de facto standards.

I am very interested in talking more about "de facto standards", but unfortunately there are too many such things, and I only know a very small part of them - and I often can't remember them. , so I can only write here today. If I think of something again, I may write a new blog post