whatwg / javascript Goto Github PK

I’ve been wanting to add notes to each section saying which browsers / ES engines support this feature (similar to how it’s done in the HTML spec.

Example screenshot, taken from http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html:

--> at the start of a line, optionally preceded by whitespace or single-line MultiLineComments, must be treated as a SingleLineComment — equivalent to //.

Remove "single-line". http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2366

See other repositories, such as Fetch or HTML, for an example.

See https://bugzilla.mozilla.org/show_bug.cgi?id=815013
and https://bugzilla.mozilla.org/show_bug.cgi?id=815014

http://wiki.ecmascript.org/doku.php?id=strawman:match_web_reality_spec

In TC39, we came to consensus on requiring Unicode 8.0.0 for ES2016, and it seemed to me like future ECMAScript versions would require the current Unicode version at the time. I don't think the JavaScript spec needs to require these additional things.

ES6 will probably spec it, though:
http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string
http://wiki.ecmascript.org/doku.php?id=strawman:function_to_string
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function.prototype.tostring

Hi,

could you please clarify what this is for and how it is related to the original specification? This should probably be done in repo’s description, README.

Thanks!
Anselm

The Comment syntax section would be clearer if it was specified in the same way as syntax is specified in ECMAScript proper.

You should probably include tests that cover multiple lines as well, as this forms a "start of line" situation and might be an easily overlooked case. Especially line-continuations.

/*
--> probably not a problem in this case though, cause, who cares
*/

var s = 'eh 
--> this is more important'
assert_eq(s, 'eh --> this is more important');

For reference, these are my complete cases (feel free to scrub/remove them from this ticket once processed :)

<script>
    var tests = 0;
    var failed = 0;
    var passed = 0;
    var str = '';
</script>

<!-- original use case for super old browsers -->
<script>++tests;</script>
<script><!--
    ++passed;
--></script>

<!-- original use case, comment after opening -->
<script>++tests;</script>
<script><!-- ++failed; str += 'A';
    ++passed;
--></script>

<!-- original use case, comment after closing -->
<script>++tests;</script>
<script><!--
    ++passed;
-->++failed; str += 'B';</script>

<!-- original use case, comment after opening and closing -->
<script>++tests;</script>
<script><!-- ++failed; str += 'C';
    ++passed;
--> ++failed; str += 'D';</script>

<!-- whitespace before opening -->
<script>++tests;</script>
<script>
<!-- ++failed; str += 'E';
    ++passed;
--> ++failed; str += 'F';</script>

<!-- whitespace before closing -->
<script>++tests;</script>
<script><!-- ++failed; str += 'G';
    ++passed;
    --> ++failed; str += 'H';</script>

<!-- code before opening -->
<script>tests += 2;</script>
<script>
    ++passed;
<!-- ++failed; str += 'I';
    ++passed;
    --> ++failed; str += 'J';
</script>

<!-- missing closing tag -->
<script>tests += 2;</script>
<script>
    ++passed;
    <!-- ++failed; str += 'K';
    ++passed;
</script>

<!-- missing opening tag -->
<script>tests += 2;</script>
<script>
    ++passed;
    --> ++failed; str += 'L';
    ++passed;
</script>

<!-- code before opening tag (same line) -->
<script>tests += 2;</script>
<script>
    ++passed; <!-- ++failed; str += 'M';
    ++passed;
</script>

<!-- open comment in a string -->
<script>tests += 3;</script>
<script>
    ++passed;
    var x = 'foo <!-- bar';
    ++passed;
    assert_eq(x, 'foo <!-- bar', 'comment should probably not be stripped from string?');
    ++passed;
</script>

<!-- open comment in a regex -->
<script>tests += 3;</script>
<script>
    ++passed;
    var x = /foo <!-- bar/;
    ++passed;
    assert_eq(x.toString(), '/foo <!-- bar/', 'regex should probably not be stripped from string?');
    ++passed;
</script>

<!-- open comment in a multiline string -->
<script>tests += 3;</script>
<script>
    ++passed;
    var x = 'foo \
<!-- bar';
    ++passed;
    assert_eq(x, 'foo <!-- bar', 'comment should probably not be stripped from string?');
    ++passed;
</script>

<!-- close comment in a multiline string (has be at start of line to be relevant) -->
<script>tests += 3;</script>
<script>
    ++passed;
    var x = 'foo \
--> bar';
    ++passed;
    assert_eq(x, 'foo --> bar', 'comment should probably not be stripped from string?');
    ++passed;
</script>

assert_eq(tests, passed, 'All passed parts should have been executed');
assert_eq(failed, 0, 'None of the failed parts should have been executed [' + str + ']');

As far as I can tell, 08 doesn’t parse per the ES spec, but it does parse in Chrome and Firefox (as a decimal literal).

So far I know of:

• https://github.com/sebmarkbage/ecmascript-string-left-right-trim
• https://github.com/tc39/Function-prototype-toString-revision
• https://github.com/claudepache/es-regexp-legacy-static-properties
• Some in-progress proposal from @erights and @ljharb on Error.prototype.stack; is that online somewhere?

There are also a number of important open bugs, which I've tagged as "web reality" on the TC39 repo.

In XML, browsers allow this:

<script>
<![CDATA[
    // code goes here
]]>
</script>

Worth looking into, in case JS engines allow it in other situations as well. Suggested by @qfox: https://twitter.com/kuvos/status/385685177164238848 & https://twitter.com/kuvos/status/385685397365198849

They’re about to be removed from test-262, so it would be a good idea to give them a new home: https://bugs.ecmascript.org/show_bug.cgi?id=1125

Update: Some more:

Removing tests that use functions listed in Annex B of the specification:
https://bugs.ecmascript.org/show_bug.cgi?id=1125
https://bugs.ecmascript.org/show_bug.cgi?id=1128
https://bugs.ecmascript.org/show_bug.cgi?id=1129
https://bugs.ecmascript.org/show_bug.cgi?id=1131

Currently, Chromium/Blink logs a warning to the console when it determines a promise rejection to be uncaught --- this is pretty friendly for developers (and it would be awesome if this was Annex B-ified or something) --- But it would also probably be nice to emit an "error" event so that window.onerror on the UI thread could handle this, and fit in better with the general "global" error handler.

I'm not sure if people have discussed this much or not, since Blink seems to be the only one doing this (logging) at the moment --- but it would be real nice if we could get implementations on the same page, and maybe do a bit more

(Will close #18 too)

12.1 Decimal escapes in character class ranges

Any DecimalEscapes in character class ranges must behave like \0 rather than throwing syntax errors.

For example, /[\1-Z]/ matches any character with a code point between U+0000 and U+005A.

Where has this behavior been observed? Tests in the Chrome 23 console conform to my expectations based on older tests in every major browser.

/[\1-Z]/.test(String.fromCharCode(0)); // false
/[\1-Z]/.test(String.fromCharCode(1)); // true

These are not decimal escapes at all. They are octal escapes. And I'm not aware of anything special about their handling when used in ranges. I believe browser handling is inconsistent for \8 and \9 within regexes, but that's a separate issue. The one special rule I can think of for handling of octal escapes within character classes is that they may only be up to three digits long, even if the leading digit is a zero. Outside of character classes, they may be up to four digits long if the leading digit is a zero. To see this difference visually, note the syntax highlighting here (RegexPal's syntax highlighting for octal escapes is specifically designed to follow web reality).

http://javascript.spec.whatwg.org/#regexp.lastmatch

It doesn't even have a TODO like the Function.prototype.toString() section does.

Since those moved into the ES spec the abstract operation definition here is not used anymore

Maybe I am wrong, but I tried to follow to spec along here. (https://tc39.github.io/ecma262/#sec-date.utc)

For zero arguments:
Date.UTC

1. y = ToNumber(year) => y = NaN
2. This step is somewhat confusing, but we should end up with yr = y = NaN
   MakeDay(yr, m, dt)
3. Return NaN, yr is not finite.
   MakeDate
4. Return NaN, day is not finite
   TimeClip
5. Return NaN, time is not finite

For one argument MakeDay should also return NaN, because month is not finite, so the rest follows.

3/4 browsers have agreement on what this should look like. It exists everywhere.

They contain the source string used for the last regular expression matching.

RegExp.input is a Microsoft extension, and it is just an alias for RegExp.$_. It is also supported in Chrome/Opera (V8) (I have not tried other browsers).

var str = "something";
str.match(/(eth)/);
RegExp.$_ // something
RegExp.input // something

See https://mail.mozilla.org/pipermail/es-discuss/2013-June/031149.html and https://bugs.ecmascript.org/show_bug.cgi?id=1553. /cc @Constellation

See tc39/ecma262#562

See
https://bugzilla.mozilla.org/show_bug.cgi?id=238945
https://code.google.com/p/v8/issues/detail?id=1127
https://bugs.ecmascript.org/show_bug.cgi?id=8

https://mail.mozilla.org/pipermail/es-discuss/2013-March/029403.html

'\8' == '8'; // true
'\9' == '9'; // true

The JavaScript WHATWG spec is pretty small and largely subsumed by TC39 work. There are just a few things left. Ideally, we would bring the remaining items into ECMAScript (e.g., library features like __defineSetter__ and RegExp legacy $1 properties) and just leave it to HTML/WebIDL to reference ECMAScript and require Annex B. Now that there's the stage process and ecmarkup, we could even have spec text which is at an earlier stage to describe certain features where consensus doesn't yet exist.

@annevk @domenic @mathiasbynens What do you think?

Items 14.1, 2, 3 & 4 should be removed.

14.1 Object.prototype.__defineGetter__(propertyName, function)
14.2 Object.prototype.__defineSetter__(propertyName, function)
14.3 Object.prototype.__lookupGetter__(propertyName)
14.4 Object.prototype.__lookupSetter__(propertyName)

These Object.prototype extensions have all been superseded with the standardization of: Object.defineProperty/defineProperties and Object.getOwnPropertyDescriptor in ES5. There is greater support for the standardized versions of these APIs then the deprecated extensions.

Inclusion of these items in a normative standard is irresponsible and future hostile.

https://bugzilla.mozilla.org/show_bug.cgi?id=647423
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/defineGetter

Consider the following:

var x = {};
Object.defineProperty(x, "foo", {get: function(){return 1}});
print(x.__lookupGetter__("foo"));

Per the current spec, this should print undefined. Per every implementation, this should print the get property of the foo property descriptor on x (i.e., the function).

As far as I can tell, __lookupGetter__ (with __lookupSetter__ being a very slight variation on this with .get replaced by .set) should be:

Object.prototype.__lookupGetter__ = function(propertyName) {
  var obj = this;
  do {
    var desc = Object.getOwnPropertyDescriptor(obj, propertyName);
    if (desc !== undefined)
      return desc.get;
  } while((obj = Object.getPrototypeOf(obj)) !== null);
}

…where all the built-ins have their initial values (i.e., Object.prototype, Object.getOwnPropertyDescriptor, Object.getPrototypeOf, and undefined).

Now, to look at the define variants:

Set the internal [[Enumerable]] property of obj’s prop property to true.

What if obj doesn't have a prop property? In a case like var x = {}; x.__defineGetter__("foo", function(){return 1}); there is no foo property on x, as where would it come from?

Whenever a property with the name of prop is accessed on the obj object, call function with the this binding set to obj, and return the result.

What does this even mean? What should the following do:

var x = {};
x.__defineGetter__("foo", function(){return 1});
print(Object.getOwnPropertyDescriptor("foo"));
print(Object.getOwnPropertyDescriptor("foo").get);

Is this accessing the property? What on earth should the object that Object.getOwnPropertyDescriptor look like? You've not created a property descriptor for foo, you've just magically defined its behaviour!

As far as I can tell, the actual behaviour is the following (again, assuming all built-ins have their initial value, and the setter variant just being the set property and not the get property):

Object.prototype.__defineGetter__ = function(propertyName, func) {
  if (typeof func !== "function")
    throw TypeError("not a function");
  Object.defineProperty(this, propertyName, {get: func, enumerable: true});
}

As it is now, it is pretty much totally undefined how these functions relate to the ES object model (just some handwaving about "whenever a property with name of prop is accessed on the obj object").

More info on RegExp#compile: http://msdn.microsoft.com/en-us/library/x9cswe0z(v=vs.84).aspx

They incorporated less than we thought, but I think they got comments. The errata is incorporated.

IMO having sections for IsCallable etc. is not that necessary. Just make them hyperlinks where they appear.

Probably should use http://www.ecma-international.org/ecma-262/6.0/

As reported by @SimonSapin: http://twitter.com/simonsapin/status/267346179103268865