| 1 | == Standards Position Discussion == |
| 2 | ''by Tess O'Connor (@hober), Apple'' [https://tess.oconnor.cx/2020/11/WebKit Slide Deck] |
| 3 | |
| 4 | 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. |
| 5 | |
| 6 | ''hober:'' Coming to consensus and communicating that consensus externally |
| 7 | |
| 8 | ''hober:'' Right now, folks ask the community for positions on webkit-dev because there is no other place to ask |
| 9 | |
| 10 | ''hober:'' We should publish our positions on webkit.org |
| 11 | |
| 12 | ''hober:'' jond has a prototype, similar to Mozilla's standard's positions |
| 13 | |
| 14 | ''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? |
| 15 | |
| 16 | ''hober:'' Let's keep the process as light-weight as possible |
| 17 | |
| 18 | ''hober:'' We should create a new GitHub repository under WebKit, folks can request a position by filing an issue |
| 19 | |
| 20 | ''hober:'' Community can come to a consensus and make comments on the issue |
| 21 | |
| 22 | == Questions & Comments == |
| 23 | |
| 24 | ''noam:'' Can we have this a year ago? |
| 25 | |
| 26 | ''sam:'' Paragraph lines in the json is a problem with Mozilla, would probably be a problem for us too |
| 27 | |
| 28 | ''hober:'' There is pressure to keep it short, maybe we should use a different backing store |
| 29 | |
| 30 | ''smfr:'' Maybe link back to the GitHub issue? |
| 31 | |
| 32 | ''Eric Carlson:'' You skipped over what happens if we can't come to a consensus |
| 33 | |
| 34 | ''hober:'' We want to introduce as little process, not trying to describe a solution to that beforehand. |
| 35 | |
| 36 | ''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? |
| 37 | |
| 38 | ''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 |
| 39 | |
| 40 | ''hober:'' These wouldn't be unchangeable positions, ones that are issued can be revised |
| 41 | |
| 42 | ''rniwa:'' Email to say "we have reached a consensus, please comment within the next 5 business days to object" |
| 43 | |
| 44 | ''hober:'' Would make a lot of sense to do something like that |
| 45 | |
| 46 | ''John Wilander:'' Differentiating between standard and doing something |
| 47 | |
| 48 | ''hober:'' Differentiating between published standards, things being worked on by one individual or one organization |
| 49 | |
| 50 | ''rniwa:'' How do we handle when a standard substantially changes and our position changes |
| 51 | |
| 52 | ''hober:'' Communicating is easy, noticing might be hard. Answering that question probably requires vigilance |
| 53 | |
| 54 | ''rniwa:'' Maybe specify a date when the review happened |
| 55 | |
| 56 | ''noam:'' Will this be connected to MDN/can I use? |
| 57 | |
| 58 | ''hober:'' Existing feature status page is a source of information, but I don't think it makes sense sense to link to MDN |
| 59 | |
| 60 | ''Jen Simmons:'' Seems like developers won't really use standards positions or find them relevant |
| 61 | |
| 62 | ''noam:'' it has "under consideration" which has link to somewhere where it is considered |
| 63 | |
| 64 | ''hober:'' We do have under consideration on our status page |
| 65 | |
| 66 | ''rniwa:'' Concerned about unhelpful noise from developers |
| 67 | |
| 68 | ''hober:'' Inclined not to worry about this at the beginning |
| 69 | |
| 70 | ''smfr:'' Is it a non-goal to prepare for the scenario where different ports have different opinions? |
| 71 | |
| 72 | ''hober:'' Let's worry about that when we get to it |
| 73 | |
| 74 | ''hober:'' Maybe should reflect a per-port stance on the feature page? |
| 75 | |
| 76 | ''Ross:'' I think we had a successful contributing with standards and trying to be as conformant as possible. |
| 77 | |
| 78 | ''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. |
| 79 | |
| 80 | ''Ross:'' The rest of the presentation is focused on standards-related work in the JSC team. |
| 81 | |
| 82 | ''Ross:'' But there are cases where we use our knowledge and work in JSC to help contribute to standards work. |
| 83 | |
| 84 | ''Alexey:'' Today we have an all time high on test262 (JS spec test suite) |
| 85 | |
| 86 | ''Alexey:'' Overall we have an 85% pass rate up from 80% in 2019 |
| 87 | |
| 88 | ''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 |
| 89 | |
| 90 | ''Alexey:'' ProxyObject has been improved such as trap failures, relection, in the prototype chain, etc. |
| 91 | |
| 92 | ''Alexey:'' Early errors for unicode RegExps |
| 93 | |
| 94 | ''Alexey:'' [[DefineOwnProperty]] no longer corrupts property name order (for-in) |
| 95 | |
| 96 | ''Alexey:'' Classes no longer rely on `_proto_ ops handle [[IsHTMLDDA]] correctly |
| 97 | |
| 98 | ''Alexey:'' Array.prototype.sort was aligned with the new tightened spec. |
| 99 | |
| 100 | ''Alexey:'' Ross aligned TypedArray internal and prototype methods with the spec (while at the same time fixing the spec) |
| 101 | |
| 102 | ''Caio:'' Public and private fields are currently a stage 3 proposal in TC-39 |
| 103 | |
| 104 | ''Caio:'' In the last year Safari shipped with public fields |
| 105 | |
| 106 | ''Caio:'' With fields the constructor of a class will install each of the fields in the class onto the object it creates |
| 107 | |
| 108 | ''Caio:'' Private fields are a bit different because the identifier is only accessible from inside the lexical scope of the class definition |
| 109 | |
| 110 | ''Caio:'' Igalia has been working on this and has also been working on other class features. |
| 111 | |
| 112 | ''Ross:'' Were you also gonig to tell us about BigInt? |
| 113 | |
| 114 | ''Caio:'' Robin and I have been working on BigInt over the last year |
| 115 | |
| 116 | ''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. |
| 117 | |
| 118 | ''Ross:'' New 262 features. |
| 119 | |
| 120 | ''Yusuke:'' WeakRef and FinalizationRegistry, implemented by Keith (me) |
| 121 | |
| 122 | ''Yususke:'' With WeakRef, it’s now possible to create a weak map where the values are held weakly |
| 123 | |
| 124 | ''Yusuke:'' In fact we are already using WeakRef in the WebInspector |
| 125 | |
| 126 | ''Ross:'' Short-circuiting assignment operators. |
| 127 | |
| 128 | ''Ross:'' This proposal was delayed until the nullish coalesing feature has been shipped. |
| 129 | |
| 130 | ''Ross:'' short ciruiting assignment was implemented by Devin |
| 131 | |
| 132 | ''Ross:'' String.prototype.replaceAll does what you would have expected replace all along. |
| 133 | |
| 134 | ''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 |
| 135 | |
| 136 | ''Ross:'' Array.prototype.at (originally, proposed as Array.prototype.item) |
| 137 | |
| 138 | ''Ross:'' has an advantage for access because it works with negative indicies |
| 139 | |
| 140 | ''Yusuke:'' Intl |
| 141 | |
| 142 | ''Yusuke:'' We went from 37% conformance to 98% conformance |
| 143 | |
| 144 | ''Yusuke:'' Ross and I worked closely on getting everything working |
| 145 | |
| 146 | Included work with ICU, perf, and new feature work. |
| 147 | |
| 148 | ''Yusuke:'' * describes all the new Intl features we have shipped * |
| 149 | |
| 150 | ''Yusuke:'' New Webassembly features this year are mutable Globals |
| 151 | |
| 152 | ''Ross:'' Looking ahead to 2021 we want to get to 90% pass rate on test262 |
| 153 | |
| 154 | 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 |
| 155 | |
| 156 | ''Caio:'' We also want to continue our class properties work to implement private methods |
| 157 | |
| 158 | ''Caio:'' Not limited to just functions but also can include private getters and setters |
| 159 | |
| 160 | ''Caio:'' Last but not least we also want to add static class fields and static private methods |
| 161 | |
| 162 | ''Yusuke:'' We have also re-enabled SharedArrayBuffer and Atomics in the build and in testers\ |
| 163 | |
| 164 | ''Yusuke:'' We also want to add Top-level await. This lets us put the await expression at the top level of module code. |
| 165 | |
| 166 | ''Yusuke:'' Another module feature we want is to have modules in workers |
| 167 | |
| 168 | ''Yusuke:'' And many more features all coming soon! |
| 169 | |
| 170 | ''Yusuke:'' We also hope to have more collaboration and build on the progress we have made this year |
| 171 | |
| 172 | ''Jen:'' Questions? |
| 173 | |
| 174 | ''Saam:'' Where are we at in test262 conformance again? |
| 175 | |
| 176 | ''Ross:'' Roughly we are at 85% |
| 177 | |
| 178 | ''Ryosuke:'' Is private class fields enabled in safari 14 |
| 179 | |
| 180 | ''Yusuke:'' Private fields just landed a few minutes ago so no |
| 181 | |
| 182 | ''Ryosuke:'' I’m excited for this feature so I hope we can get it done soon |
| 183 | |
| 184 | ''Caio:'' We still needed to add some JIT work for private fields and hopefully we can get that done soon |
| 185 | |
| 186 | ''Saam:'' We should just turn it on |
| 187 | |
| 188 | ''Yusuke:'' This is a good time to enable it because it gives us a chance to get feedback |
| 189 | |
| 190 | ''Caio:'' We need to do some work on field initialization but it shouldn’t block private fields because it didn’t block public fields |
| 191 | |
| 192 | ''Ryosuke:'' In order for the fuzzer to run with it we need to enable it somewhere e.g. WebKitTestRunner |
| 193 | |
| 194 | ''Yusuke:'' We need to add support private fields syntax in the fuzzer but shouldn’t be too hard |
| 195 | |
| 196 | ''Ryosuke:'' For each JSC feature we now want to have significant fuzzing for each new feature before shipping |
| 197 | |
| 198 | ''Yusuke:'' We can also enable the feature in our fuzzers without enabling by default |
| 199 | |
| 200 | ''Ryosuke:'' To clarify on what we want to fuzz we want to fuzz everything that could be used to exploit JSC |
| 201 | |
| 202 | ''Saam:'' Fortunately, for most features outside syntax, fuzzer will just test it |
| 203 | |
| 204 | ''Yusuke:'' Yeah, for things like changes to DFG the fuzzer will find it because it will build off all the JSC tests |