Chakra. Interoperability means more than just standards.
How is the decision to implement a function that is not included in the specification of standards? Like all browser vendors, we often have to make this decision. This publication will provide a number of real-world JavaScript examples to illustrate some of the principles used to create a interoperable browser when standards standards are not enough.
Ideally, the specification of standards is self-sufficient. A JavaScript implementation would simply include everything specified in the ECMAScript specification , and nothing more. We believe that specifications published by standardization organizations such as Ecma International or W3C are essential to ensure browser interoperability. Such specifications inform the browser implementers about what functions they should implement, and website developers what functions they should use.
In the real world of the Internet, things are not so clearly defined. Specifications are rarely perfect, and sometimes they are intentionally left incomplete or ambiguous. Own experience as an editor of the specification of ES5 suggests that there are always problems that have not found a final solution. As a result, functions that are not defined in any specification of standards are widely implemented and applied. A developer trying to build a browser that would work on the existing Internet will have to implement many features not covered by the standards specification.
')
When creating Chakra , ECMAScript 5 (ES5) specification was carefully followed, including regular expressions grammar. But when testing started on real websites, pages began to come across that didn't work because of syntax errors in some regular expression literals. For example, a failure occurred on regular expressions containing the following right bracket:
The reason was that the ECMAScript standard regular expression grammar includes] the list of characters that cannot be directly used as a match character. The specification states that the
In practice, all browsers accept regular expressions such as
A consensus function is a term that we use to describe such functions that are not part of any standard, but are universally implemented in a way that enables interaction. In general, IE9 and any other JavaScript implementation should include such consensus functions in order to work with real web content. The real difficulty lies in their identification, since they are not included in the specifications of the standards.
We recognize the need to maintain consensus functions of this kind and will make efforts to ensure that they are included in future revisions of relevant standards for the Internet. However, not all JavaScript extensions are implemented everywhere or uniformly.
ES5 includes support for reading and setting values. Similar functions have been available in some web browsers for many years. During this period, browser developers experimented with various syntaxes and programmatic interfaces (APIs) to define such methods. Before the advent of ES5, the most widely implemented API used two methods called __ defineGetter__ and __ defineSetter__ to define the read / set methods. The use of underscores on either side of a method name is a convention used by some browser developers to mark methods that are experimental features or address the low-level unique features of a particular JavaScript implementation.
ECMA TC39 committee members agreed that methods for reading and setting values ​​should be included in the ES5 specification, since their benefits are obvious. At the same time, the TC39 committee decided to create a new API for their definition and refrain from standardizing interfaces __ defineXXX__.
Why did the TC39 do just that? Due to significant differences in the behavior of browsers that provided this API. Standardization based on common semantics for these methods will mean that some or possibly all existing implementations of browsers will have to be modified to bring them in line with the new semantics. And this will probably make non-functional some applications written to work with specific browsers.
Another reason is the desire to maintain the logical integrity of naming conventions. No other embedded name in ECMAScript begins with an underscore or ends with an underscore. The association of such names with experimental functions or the implementation of a specific function is widely known. Using this symbol for a standardized function will be misleading and reduce its usefulness for future experiments.
The TC39 committee developed a new API based on the
Browsers that already have the __defineXXX__ API implemented can continue to support it unchanged in order to ensure compatibility. However, in a new code written to ensure compatibility of browsers that support the ES5 standard, the Object.defineProperty method should be used to determine the properties of methods for reading and setting values.
The development team is still being asked to add the __defineXXX__ programming interfaces to IE9. It is clear why. Some developers already have code that uses these interfaces, and they would like this code to run in IE9. However, the developers of IE9 believe that supporting these interfaces will not be in the fundamental interest of ensuring interoperability on the Internet. TC39 has already reviewed this API and concluded that its standardization is undesirable. If support for __defineXXX__ interfaces were added in IE9, this API would be even closer to becoming a permanent consensus function on the Internet; this would essentially cancel decision TC39.
Unfortunately, in the short term, this creates a small amount of additional work for developers currently using this outdated API. However, creating a simple compatibility library for existing code that implements __defineXXX__ interfaces using the
In JavaScript code, you can set a link to a function, and you can also call it in code that precedes the function declaration as such. This is possible because JavaScript logically “lifts” all function declarations to the top of the enclosing code body. JavaScript also allows for the existence of multiple function declarations with the same name. Consider a simple testing function.
After the call, the function created a sequence of alerts: “second f1”, “second f1”, ”second f1”. The reason is that JavaScript actually handles this function as if it were written as follows:
ECMAScript specification has historically imposed only one restriction on the placement of a function declaration. The ECMAScript standard does not include the ability to place a function declaration inside the body of a control structure statement. An example code is shown below.
In the analysis, in accordance with the ECMAScript specification, the above code will cause a syntax error. However, if you run it in any browser, you will find that the error does not occur. Support for function declarations in any place where instruction is allowed is a consensus on the Internet. And if so, why is this not included in ES5? Section 12 of the ES5 specification actually says something about this.
NOTE. It is known that several widely used ECMAScript implementations support the use of function declaration as an instruction. However, between implementations there are significant and irreconcilable variations in the semantics applied to such function declarations. Due to these irreconcilable differences, the use of a function declaration as an instruction causes the code to not be reliably portable between implementations. It is recommended in ECMAScript implementations to prohibit such use of the function declaration or to accompany the declaration with a mandatory warning. In future editions of ECMAScript, alternative portable means may be defined for declaring functions in the context of an instruction.
What do these inconsistent wording mean? Simply put, the behavior of different browsers differed so much that the matching attempts were impractical.
What does IE9 do? Does IE9 prohibit such feature declarations at the instruction level as recommended in the ES5 specification? No, in IE9, similar ads are handled in exactly the same way as in previous versions of IE.
Why was this decision made? Because the previous experiments of browser developers have demonstrated that the rejection of such ads led to the inoperability of many existing web pages.
This may seem surprising. How can a web page depend on functions that behave differently in different browsers and, nevertheless, be compatible with different browsers? One possible answer: in fact, the code is not used. This may be a function that is never called, or the result of which is not important for the functioning of the page. On the other hand, if the JavaScript implementation would treat these functions as syntax errors, the entire script would be rejected, even if the function was never called.
The implementation of such a dangerous function for developers is undesirable. However, its existence on the Internet is fixed, so there is virtually no choice.
Sometimes the question is asked whether IE9 will support the declaration of
Several browsers support this feature, but there are significant differences in their handling of unusual situations and in what they define as errors. Here is an example showing some differences in the behavior of browsers that "support"
Depending on the browser, the code can do the following:
In essence, only very simple applications of
The actual implementation of JavaScript cannot support only a small number of trivial use cases. This implementation should also do something with untypical borderline cases and erroneous scenarios that exist on real web pages. It is likely that standardized specifications exist primarily for such situations. What to do with simple common use cases is usually obvious. This is for edge cases, a specification of standards is required to ensure the existence of compatible implementations.
TC39 seriously considered the inclusion of
So what does IE9 do with
The desire of many website developers to be able to use such an ad is understandable. However, I don’t want to create another situation, similar to the conditional function declaration, when the function should exist, but it would be better for website developers not to use it if they are concerned about browser compatibility. Ultimately, it appears that the best long-term solution for the Internet is to exclude it from use and wait until the standardization process takes its course.
These are just four specific JavaScript examples that demonstrate what kind of decisions you have to make during the creation of IE9. Many similar problems arise in connection with other standards and consensus functions on the Internet. In each case, a similar analysis is carried out. And what does the standard say? How many websites really need it? Is this a consensus function with common semantics? Are there several incompatible function options? Does the standards committee work on this issue? Are there any test suites ? Will adoption promote or hinder standardization processes? Ultimately, this is a matter of subjective judgment, and therefore it is important to make every effort to ensure a principled and consistent approach to decision-making.
PS Have you already rated Habr on HTML5 ?
Ideally, the specification of standards is self-sufficient. A JavaScript implementation would simply include everything specified in the ECMAScript specification , and nothing more. We believe that specifications published by standardization organizations such as Ecma International or W3C are essential to ensure browser interoperability. Such specifications inform the browser implementers about what functions they should implement, and website developers what functions they should use.
In the real world of the Internet, things are not so clearly defined. Specifications are rarely perfect, and sometimes they are intentionally left incomplete or ambiguous. Own experience as an editor of the specification of ES5 suggests that there are always problems that have not found a final solution. As a result, functions that are not defined in any specification of standards are widely implemented and applied. A developer trying to build a browser that would work on the existing Internet will have to implement many features not covered by the standards specification.
')
What is a real grammar regular expression?
When creating Chakra , ECMAScript 5 (ES5) specification was carefully followed, including regular expressions grammar. But when testing started on real websites, pages began to come across that didn't work because of syntax errors in some regular expression literals. For example, a failure occurred on regular expressions containing the following right bracket:
next = /]/.exec(buffer);The reason was that the ECMAScript standard regular expression grammar includes] the list of characters that cannot be directly used as a match character. The specification states that the
/]/ symbol is invalid, use /\]/ instead. It turns out that such a restriction of the symbol [is important, because otherwise it would be impossible to analyze literals such as /axyz[ad]qwer/ . However, the single bracket], which is not preceded by the symbol [, in fact does not represent an obstacle for analysis. However, the standard still claims that it is unacceptable.In practice, all browsers accept regular expressions such as
/]/ , and website developers write them.A consensus function is a term that we use to describe such functions that are not part of any standard, but are universally implemented in a way that enables interaction. In general, IE9 and any other JavaScript implementation should include such consensus functions in order to work with real web content. The real difficulty lies in their identification, since they are not included in the specifications of the standards.
We recognize the need to maintain consensus functions of this kind and will make efforts to ensure that they are included in future revisions of relevant standards for the Internet. However, not all JavaScript extensions are implemented everywhere or uniformly.
Why are there no methods in IE9 with _ _ in the names?
ES5 includes support for reading and setting values. Similar functions have been available in some web browsers for many years. During this period, browser developers experimented with various syntaxes and programmatic interfaces (APIs) to define such methods. Before the advent of ES5, the most widely implemented API used two methods called __ defineGetter__ and __ defineSetter__ to define the read / set methods. The use of underscores on either side of a method name is a convention used by some browser developers to mark methods that are experimental features or address the low-level unique features of a particular JavaScript implementation.
ECMA TC39 committee members agreed that methods for reading and setting values ​​should be included in the ES5 specification, since their benefits are obvious. At the same time, the TC39 committee decided to create a new API for their definition and refrain from standardizing interfaces __ defineXXX__.
Why did the TC39 do just that? Due to significant differences in the behavior of browsers that provided this API. Standardization based on common semantics for these methods will mean that some or possibly all existing implementations of browsers will have to be modified to bring them in line with the new semantics. And this will probably make non-functional some applications written to work with specific browsers.
Another reason is the desire to maintain the logical integrity of naming conventions. No other embedded name in ECMAScript begins with an underscore or ends with an underscore. The association of such names with experimental functions or the implementation of a specific function is widely known. Using this symbol for a standardized function will be misleading and reduce its usefulness for future experiments.
The TC39 committee developed a new API based on the
Object.defineProperty method. This interface not only supports the definition of the properties of the read and set methods, but also other new features of ES5. The __defineXXX__ methods were not included in the ES5 specification.Browsers that already have the __defineXXX__ API implemented can continue to support it unchanged in order to ensure compatibility. However, in a new code written to ensure compatibility of browsers that support the ES5 standard, the Object.defineProperty method should be used to determine the properties of methods for reading and setting values.
The development team is still being asked to add the __defineXXX__ programming interfaces to IE9. It is clear why. Some developers already have code that uses these interfaces, and they would like this code to run in IE9. However, the developers of IE9 believe that supporting these interfaces will not be in the fundamental interest of ensuring interoperability on the Internet. TC39 has already reviewed this API and concluded that its standardization is undesirable. If support for __defineXXX__ interfaces were added in IE9, this API would be even closer to becoming a permanent consensus function on the Internet; this would essentially cancel decision TC39.
Unfortunately, in the short term, this creates a small amount of additional work for developers currently using this outdated API. However, creating a simple compatibility library for existing code that implements __defineXXX__ interfaces using the
Object.defineProperty method Object.defineProperty to be nothing.Inoperable consensus function
In JavaScript code, you can set a link to a function, and you can also call it in code that precedes the function declaration as such. This is possible because JavaScript logically “lifts” all function declarations to the top of the enclosing code body. JavaScript also allows for the existence of multiple function declarations with the same name. Consider a simple testing function.
<code> function testFuncDeclarationOrder () {</ code> <code> f1 (); </ code>
<code> function f1 () {alert ("first f1")} </ code> <code> </ code> <code> f1 (); </ code>
<code> function f1 () {alert ("second f1")} </ code> <code> f1 (); </ code>
<code>} </ code>
After the call, the function created a sequence of alerts: “second f1”, “second f1”, ”second f1”. The reason is that JavaScript actually handles this function as if it were written as follows:
<code> function testFuncDeclarationOrder () {</ code> <code> function f1 () {alert ("first f1")} </ code> <code> function f1 () {alert ("second f1")} </ code> <code> f1 (); </ code>
<code> f1 (); </ code>
<code> f1 (); </ code>
<code>} </ code>
ECMAScript specification has historically imposed only one restriction on the placement of a function declaration. The ECMAScript standard does not include the ability to place a function declaration inside the body of a control structure statement. An example code is shown below.
<code> if (someCondition) {</ code> <code> function f1 () {alert ("f1")} </ code> <code>} </ code>
In the analysis, in accordance with the ECMAScript specification, the above code will cause a syntax error. However, if you run it in any browser, you will find that the error does not occur. Support for function declarations in any place where instruction is allowed is a consensus on the Internet. And if so, why is this not included in ES5? Section 12 of the ES5 specification actually says something about this.
NOTE. It is known that several widely used ECMAScript implementations support the use of function declaration as an instruction. However, between implementations there are significant and irreconcilable variations in the semantics applied to such function declarations. Due to these irreconcilable differences, the use of a function declaration as an instruction causes the code to not be reliably portable between implementations. It is recommended in ECMAScript implementations to prohibit such use of the function declaration or to accompany the declaration with a mandatory warning. In future editions of ECMAScript, alternative portable means may be defined for declaring functions in the context of an instruction.
What do these inconsistent wording mean? Simply put, the behavior of different browsers differed so much that the matching attempts were impractical.
What does IE9 do? Does IE9 prohibit such feature declarations at the instruction level as recommended in the ES5 specification? No, in IE9, similar ads are handled in exactly the same way as in previous versions of IE.
Why was this decision made? Because the previous experiments of browser developers have demonstrated that the rejection of such ads led to the inoperability of many existing web pages.
This may seem surprising. How can a web page depend on functions that behave differently in different browsers and, nevertheless, be compatible with different browsers? One possible answer: in fact, the code is not used. This may be a function that is never called, or the result of which is not important for the functioning of the page. On the other hand, if the JavaScript implementation would treat these functions as syntax errors, the entire script would be rejected, even if the function was never called.
The implementation of such a dangerous function for developers is undesirable. However, its existence on the Internet is fixed, so there is virtually no choice.
And what about const?
Sometimes the question is asked whether IE9 will support the declaration of
const . const is a non-standard JavaScript extension that provides a way to declare “named constant” values. A typical application might look something like this:const pi=3.14159;Several browsers support this feature, but there are significant differences in their handling of unusual situations and in what they define as errors. Here is an example showing some differences in the behavior of browsers that "support"
const :<code> // function with multiple const declarations for the same name </ code>
<code> function f () {</ code> <code> alert ('executing within f'); </ code> <code> const x = 1; // declare the constant x as 1 </ code>
<code> alert (x); </ code>
<code> const x = 2; // override the constant x as 2 </ code>
<code> alert (x); </ code>
<code> x = 3; // try to set 3 for x </ code>
<code> </ code> <code> alert (x); </ code>
<code>} </ code>
<code> alert ('about to call f'); f (); </ code> Depending on the browser, the code can do the following:
- report a syntax error and do not load the page;
- throw an exception when calling f;
- Alert: '1', '2', '2'. This means that conflicting
constdeclarations are resolved, but the assignment is ignored; - Alert '1', '2', '3'. This means that
constprocessed just like var.
In essence, only very simple applications of
const compatible with various browsers that support ad. Many more complex applications or scenarios that may lead to an error are incompatible between different browsers.The actual implementation of JavaScript cannot support only a small number of trivial use cases. This implementation should also do something with untypical borderline cases and erroneous scenarios that exist on real web pages. It is likely that standardized specifications exist primarily for such situations. What to do with simple common use cases is usually obvious. This is for edge cases, a specification of standards is required to ensure the existence of compatible implementations.
TC39 seriously considered the inclusion of
const in ES5, it is present in the early projects of ES5. However, many problems have emerged with its definition and interaction with other ads. Ultimately, it was agreed in TC39 that const standardization would wait for the “next” revision of the specification, in which some of these other problems might also be solved. In essence, the TC39 committee decided that standardization of a function with a flaw is undesirable. Instead, he decided to postpone any const standardization for the future, when a single improved design could be embedded in all browsers.So what does IE9 do with
const ? So far the group has adhered to the decision not to support him. This is not yet a consensus function, since it has never been available in all browsers. There is no standard specification, but there are significant semantic differences between all existing browser implementations. In addition to this, it is known that TC39 decided not to standardize any existing alternatives and intends to re-examine the issue in the following ECMAScript editions.The desire of many website developers to be able to use such an ad is understandable. However, I don’t want to create another situation, similar to the conditional function declaration, when the function should exist, but it would be better for website developers not to use it if they are concerned about browser compatibility. Ultimately, it appears that the best long-term solution for the Internet is to exclude it from use and wait until the standardization process takes its course.
A principled approach to decision making
These are just four specific JavaScript examples that demonstrate what kind of decisions you have to make during the creation of IE9. Many similar problems arise in connection with other standards and consensus functions on the Internet. In each case, a similar analysis is carried out. And what does the standard say? How many websites really need it? Is this a consensus function with common semantics? Are there several incompatible function options? Does the standards committee work on this issue? Are there any test suites ? Will adoption promote or hinder standardization processes? Ultimately, this is a matter of subjective judgment, and therefore it is important to make every effort to ensure a principled and consistent approach to decision-making.
PS Have you already rated Habr on HTML5 ?
Source: https://habr.com/ru/post/105644/
All Articles