== Standards Position Discussion ==
''by Tess O'Connor (@hober), Apple'' [https://tess.oconnor.cx/2020/11/WebKit 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^32

''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