Changes between Initial Version and Version 1 of WebKitStandardsPositions

Timestamp:

Jan 5, 2021, 2:54:07 PM (5 years ago)

Author:

Jon Davis

Comment:

--

WebKitStandardsPositions

@@ +1 @@
+== 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