WebAssembly
Track and update all the implemented features
After seeing https://labs.leaningtech.com/blog/branch-hinting yesterday, I was quite surprised to read that not only is this proposal done, but it's also implemented in all the browsers, and yet it's not even tracked in the features.json file.
So I took it upon myself to make sure that all features that are in at least phase 3 (implementation phase) are tracked and up to date. While doing this I however noticed that with the recent addition of "Custom Page Sizes", at least one phase 1 feature is also tracked now. So I exhaustively updated the features.json file to include all features that are implemented in at least one engine as well.
With there being a lot more proposals that are being tracked now, I thought it would also make sense to properly reflect the phases on the website, instead of splitting them into just two sections.
This is very nice. But I have to agree with @dschuff about early phases: there is basically no entry requirement to phase 1, and proposals at this stage generally are "just an idea", often with no worked out design that could even be implemented and no agreement yet that they should ever be included. Implementations at this stage are mostly experiments. So it may be misleading to show phase 1 in this table, and may set wrong expectations. In contrast, phase 2 at least requires a "complete overview document" and "reasonably high level of consensus".
I can remove the phase 1 proposals then, but what about the component model and custom page sizes (the latter already having been there from a recent PR)?
Custom page sizes is scheduled for a phase 2 vote next Tuesday, so we could just wait that out. The component model is rather special, since it is it's own separate layer and will not necessarily be implemented in engines.
That's a good point about the phase 2 requirements being a good proxy for the usefulness of trying out a feature. I think that makes sense as a "default" criterion for inclusion here. I'm fine leaving custom page sizes in for now though, even if we don't wait; if it doesn't make it to phase 2, we can figure out what to do. CM is more interesting. My intuition is that it's well-specified enough that it might be useful for users or tool-builders to try to use, but as @rossberg mentioned, the layering is complicated and the relevant implementations are mostly not in this table. I'd say it probably makes sense to leave it out of this table for this PR, but if there's interest in coming up with an analogous convenience for developers, we can certainly discuss that. /cc @lukewagner
I removed all the phase 1 proposals and preemptively moved Custom Page Sizes to phase 2.
I pushed one additional change marking GC as being enabled in Safari 18. While it is indeed now enabled by default in Webkit, I don't actually know whether that also means it will be in the final Safari 18 or they ship an earlier version of Webkit. We could wait for the next iOS 18 Beta and check, or I can just revert it.
I undid that change. It seems like they mostly just cherry pick changes during the beta period, so it might not make it until 18.1. I'll just do a follow up PR then.
I undid that change. It seems like they mostly just cherry pick changes during the beta period, so it might not make it until 18.1. I'll just do a follow up PR then.
I think this is the right thing to do. When a feature turns on by default in WebKit it usually means it will ship in Safari, but not always. And Apple is very opaque about their release process and will never say anything about what will release in the future. So in my experience it's just best to wait until the official beta releases come out.