Standards Position Discussion

by Tess O'Connor (@hober), Apple ​Slide Deck

Let’s figure out how the WebKit community can come to consensus on web standards and communicate that consensus to the world & our colleagues from the other engines.

hober: Coming to consensus and communicating that consensus externally

hober: Right now, folks ask the community for positions on webkit-dev because there is no other place to ask

hober: We should publish our positions on webkit.org

hober: jond has a prototype, similar to Mozilla's standard's positions

hober: Difference is that Mozilla is a single organization, but WebKit is multiple organizations, how do we come to consensus, and what happens if we cannot come to consensus?

hober: Let's keep the process as light-weight as possible

hober: We should create a new GitHub repository under WebKit, folks can request a position by filing an issue

hober: Community can come to a consensus and make comments on the issue

Questions & Comments

noam: Can we have this a year ago?

sam: Paragraph lines in the json is a problem with Mozilla, would probably be a problem for us too

hober: There is pressure to keep it short, maybe we should use a different backing store

smfr: Maybe link back to the GitHub issue?

Eric Carlson: You skipped over what happens if we can't come to a consensus

hober: We want to introduce as little process, not trying to describe a solution to that beforehand.

rniwa: I think we've come to consensus about most of those requests, but how do we know that? How do we know enough time has passed for folks to comment?

hober: We need to wait long enough, can also re-open issues if they're closed pre-maturely. People need to show up to have a conversation, none of this is set in stone

hober: These wouldn't be unchangeable positions, ones that are issued can be revised

rniwa: Email to say "we have reached a consensus, please comment within the next 5 business days to object"

hober: Would make a lot of sense to do something like that

John Wilander: Differentiating between standard and doing something

hober: Differentiating between published standards, things being worked on by one individual or one organization

rniwa: How do we handle when a standard substantially changes and our position changes

hober: Communicating is easy, noticing might be hard. Answering that question probably requires vigilance

rniwa: Maybe specify a date when the review happened

noam: Will this be connected to MDN/can I use?

hober: Existing feature status page is a source of information, but I don't think it makes sense sense to link to MDN

Jen Simmons: Seems like developers won't really use standards positions or find them relevant

noam: it has "under consideration" which has link to somewhere where it is considered

hober: We do have under consideration on our status page

rniwa: Concerned about unhelpful noise from developers

hober: Inclined not to worry about this at the beginning

smfr: Is it a non-goal to prepare for the scenario where different ports have different opinions?

hober: Let's worry about that when we get to it

hober: Maybe should reflect a per-port stance on the feature page?

Ross: I think we had a successful contributing with standards and trying to be as conformant as possible.

Ross: We have had a more balanced participation in Source/JavaScriptCore in 2019-2020 in the last year. In the last year more contributions have been done by non-apple contributors. Slack has been great for our communication on the JSC part of the project. There’s also a biweekly OSS staff meeting.

Ross: The rest of the presentation is focused on standards-related work in the JSC team.

Ross: But there are cases where we use our knowledge and work in JSC to help contribute to standards work.

Alexey: Today we have an all time high on test262 (JS spec test suite)

Alexey: Overall we have an 85% pass rate up from 80% in 2019

Alexey: There have been a number of notable fixes in the last year. Keith (me) fixei unescaped astral literals in indentifiers. Saam fixed Array.prototype to work with indicies beyond 2³²

Alexey: ProxyObject has been improved such as trap failures, relection, in the prototype chain, etc.

Alexey: Early errors for unicode RegExps

Alexey: DefineOwnProperty no longer corrupts property name order (for-in)

Alexey: Classes no longer rely on `_proto_ ops handle IsHTMLDDA correctly

Alexey: Array.prototype.sort was aligned with the new tightened spec.

Alexey: Ross aligned TypedArray internal and prototype methods with the spec (while at the same time fixing the spec)

Caio: Public and private fields are currently a stage 3 proposal in TC-39

Caio: In the last year Safari shipped with public fields

Caio: With fields the constructor of a class will install each of the fields in the class onto the object it creates

Caio: Private fields are a bit different because the identifier is only accessible from inside the lexical scope of the class definition

Caio: Igalia has been working on this and has also been working on other class features.

Ross: Were you also gonig to tell us about BigInt?

Caio: Robin and I have been working on BigInt over the last year

Caio: BigInts are similar to numbers in JS but they have infinite precision. i.e. when you go over 2^{53 with BigInt you will not lose precision.}

Ross: New 262 features.

Yusuke: WeakRef and FinalizationRegistry, implemented by Keith (me)

Yususke: With WeakRef, it’s now possible to create a weak map where the values are held weakly

Yusuke: In fact we are already using WeakRef in the WebInspector

Ross: Short-circuiting assignment operators.

Ross: This proposal was delayed until the nullish coalesing feature has been shipped.

Ross: short ciruiting assignment was implemented by Devin

Ross: String.prototype.replaceAll does what you would have expected replace all along.

Ross: Previously if you didn’t use the global flag on a regexp or used a string regexp replace would only replace the first occurrance

Ross: Array.prototype.at (originally, proposed as Array.prototype.item)

Ross: has an advantage for access because it works with negative indicies

Yusuke: Intl

Yusuke: We went from 37% conformance to 98% conformance

Yusuke: Ross and I worked closely on getting everything working

Included work with ICU, perf, and new feature work.

Yusuke: * describes all the new Intl features we have shipped *

Yusuke: New Webassembly features this year are mutable Globals

Ross: Looking ahead to 2021 we want to get to 90% pass rate on test262

The important part here isn’t just to get 90% but rather that we want to establish 90% as our new baseline and continually improve on that

Caio: We also want to continue our class properties work to implement private methods

Caio: Not limited to just functions but also can include private getters and setters

Caio: Last but not least we also want to add static class fields and static private methods

Yusuke: We have also re-enabled SharedArrayBuffer and Atomics in the build and in testers\

Yusuke: We also want to add Top-level await. This lets us put the await expression at the top level of module code.

Yusuke: Another module feature we want is to have modules in workers

Yusuke: And many more features all coming soon!

Yusuke: We also hope to have more collaboration and build on the progress we have made this year

Jen: Questions?

Saam: Where are we at in test262 conformance again?

Ross: Roughly we are at 85%

Ryosuke: Is private class fields enabled in safari 14

Yusuke: Private fields just landed a few minutes ago so no

Ryosuke: I’m excited for this feature so I hope we can get it done soon

Caio: We still needed to add some JIT work for private fields and hopefully we can get that done soon

Saam: We should just turn it on

Yusuke: This is a good time to enable it because it gives us a chance to get feedback

Caio: We need to do some work on field initialization but it shouldn’t block private fields because it didn’t block public fields

Ryosuke: In order for the fuzzer to run with it we need to enable it somewhere e.g. WebKitTestRunner

Yusuke: We need to add support private fields syntax in the fuzzer but shouldn’t be too hard

Ryosuke: For each JSC feature we now want to have significant fuzzing for each new feature before shipping

Yusuke: We can also enable the feature in our fuzzers without enabling by default

Ryosuke: To clarify on what we want to fuzz we want to fuzz everything that could be used to exploit JSC

Saam: Fortunately, for most features outside syntax, fuzzer will just test it

Yusuke: Yeah, for things like changes to DFG the fuzzer will find it because it will build off all the JSC tests