There is a little talk right now in the fediverse about whether there is a chance for reforming the WHATWG. Two months ago someone has asked the Pale Moon fediverse account (which I control) whether there is a chance for us to join the WHATWG as an implementer, which I haven't answered yet mostly because I have always forgotten to get to it lol, but also because it does take time to dig through past forum threads here about the WHATWG and how the WHATWG works. So now I will try to answer here, motivated by the same person wondering out loud recently in their blog about our membership in the WHATWG (along with Servo).
Before we can even talk about what being in the WHATWG would be like and whether we can have an impact, we have to talk about whether we even have someone with the sufficient knowledge of Goanna's DOM, HTML, and CSS implementation, and who also has enough willpower to lobby for our viewpoints in WHATWG discussions. Lobbying is a full-time job, and I doubt that someone would want to do this for free, voluntarily taking away time from their other obligations and hobbies. That already disqualifies Moonchild, who has stated in 2023 that they don't have the time for this. So dedicated funding for a salary would have to exist. All current three implementers in the WHATWG can easily solve this as they are all corporations who can simply hire one of their engineers with the sufficient diplomatic skills and patience to sit (in a virtual sense) through many discussions. Pale Moon however is not developed by (or Moonchild Productions is not) a corporation. There may be funds for high-priority issues marked for bounty (which sadly is mostly ignored), and money for the certificates (code-signing and HTTPS), server maintenance (note that we also try to cover many online services of the browser previously done by Mozilla, like the update server, add-on blocklist, add-on hosting and updates, the sync service). But a lobbyist is going to stretch the budget. And as of 2023 in the same linked forum post by Moonchild there is indeed no budget possible for this.
But let's just ignore money for a moment. Is there someone else other than Moonchild who have the DOM+HTML+CSS knowledge who is currently in the development team? I think (i.e. immediately coming to my mind) there are two.
I can't consider myself one of them unfortunately (even if I'm not technically in hiatus from platform development right now), even though I have touched DOM in the past, and have extensively touched the JavaScript garbage collector (I still don't understand how that works lol), the build system (separating SpiderMonkey or mozjs into its own dll drove me insane), Intl code (upgrading the in-tree ICU was a pain), and even brought in JPEG-XL support (sadly I couldn't finish all of it but it does mostly work, just be prepared to be disappointed if you're using HDR).
Digressing (or subtle boasting, if you like to see it that way heh) aside, I think the two people are athenian200 and FranklinDM. They both worked on bringing in WebComponents support (with the latter providing the final pieces to the WC puzzle), which you may remember has caused a big headache for us both because websites depending on it just didn't work in Pale Moon before we finally completed our implementation of both Shadow DOM and Custom Elements. That feat definitely required being familiar with our own DOM, HTML, and CSS implementations, all of them inherited from a pretty old Mozilla platform that not even Mozilla themselves as a collective at the time fully understand (and they probably still don't fully understand their current codebase).
Unfortunately athenian seems pretty busy with their irl right now (according to the forum software they're last seen active here this September). As for Franklin I know he studied in the University of the Philippines, but I'm not sure if he's still studying there... So already we're running into an obstacle that isn't in WHATWG's territory yet.
Ok let's assume we've got that covered. Let's also ignore the fact that DOM and HTML (which WHATWG handles) are just two small pieces of the web browser puzzle (the real deal, I think is JavaScript, based on ECMAScript whose spec is developed by TC39 of Ecma International, and whose additional features every year can make websites that shortsightedly require them broken in Pale Moon). All three implementers have (begrudgingly) unanimously agreed to let us (and only us) in just to appease the open web crowd. Great! I still doubt about our chances of influencing anything though.
First problem to deal with is the minimum amount of implementer support...
For a target feature we want to stay in the spec we need a minimum of two implementers in order for it to be kept. Unfortunately us being a member still means we couldn't have prevented <style scoped>, AppCache (aka HTML5 cache manifest or HTML5 Application Cache), and now mentions of XSLT from being removed from the living HTML and DOM standards; our veto would've been overridden by the three whose engineers are more interested in making their own browser's development easier, which means removal of features they think in their ivory towers are "useless" or "insecure".
The spec doesn't just get removals, they also get added into and modified. IIRC they also require a minimum of 2 in order for such a proposal to pass. Again we cannot prevent the bloating of the web platform as a lone opposition; Shadow DOM and Custom Elements are examples of what we wouldn't want in the web platform (because they're already redundant to XSLT and scoped styles, they're needlessly complex and require JavaScript, and they're still not good replacements to scoped styling in HTML as well as frameworks anyway), if we were a member at the time they were being developed. We also can't prevent the spec from being modified to match Chrome's implementation instead of forcing Chrome to correct itself for the other implementers.
So that threshold will have to be changed. A unanimous decision to remove something from the web platform (only one implementer needs to continue intending to support the targeted feature for its removal to be thwarted), and a unanimous decision as well to add to and modify the web (if the 3 have intended to implement and ship it and we haven't, it's not a standard). True consensus, instead of votes.
If you're an executive for one of those three corporations, would you like it if such a small browser that doesn't even hit a percentage point in market share bossed your devs around instead of your managers? I would've hated that! I would've plotted immediately for kicking that Pale Moon out of our cartel; their intentions simply don't fit what we want the web to look like, and they cannot defend themselves from Apple, Mozilla and Google giving them the boot when the least PR-damaging time comes.
So we need friends too. Perhaps Ladybird, which is the "newestcomer" and doing pretty well catching up in DOM, HTML and CSS, last I checked. We could have Servo too, though I think they might be too aligned with Mozilla (it was their creation after all), and I feel they're not doing as much progress as Ladybird are in web compatibility. Maybe add Dillo and NetSurf for the hell of it. The same "prerequisite" questions will still apply to them though. Do they have the lobbyist? Ladybird and Servo could probably hire one. I have doubts about Dillo and NetSurf though, which would be a shame because they are the two I feel we would've been most friendly with in a reformed WHATWG. Those two after all would probably have a strong interest in keeping out anything new that involves or requires scripting.
These are my 200 billion centavos, and I would like to see yours (though just 2 cents would be fine
), especially those from the community core. 
