Should there be something here about using OOUI when possible to create interface elements, instead of using the Html class or (*gasp*) hardcoded HTML?
By the way, the document does seem to say that the Html class should be used instead of hardcoded HTML, but maybe that part could be clearer.
Given that OOUI is now deprecated, I think we should avoid giving that guidance right now. But sadly the alternative (Codex) isn't ready and a server-side-rendering system certainly isn't. Ah well.
I didn't know OOUI was actually deprecated. Not to get into in a side issue, but is it really officially deprecated, or is it just sort of implicit that, given that a competing library is being developed, OOUI is not going to get much attention any more?
In any case, this doesn't seem like a satisfactory answer. If an extension's interface is going to adhere to the Wikimedia Design Style Guide (which is also not mentioned in this document, by the way), OOUI is still the easiest way to achieve that, as far as I know. Let me ask this: if a new extension were created today for use on Wikipedia or other Wikimedia sites, and it contained form elements, how would its UI be coded so that it matched the style guide? Or would it simply have the default HTML gray buttons? (Doubtful.)
Re: OOUI's deprecation, see this wikitech-l thread.
My understanding is that practically a new MediaWiki extension would most likely use OOUI because it has the most comprehensive widget library and is well integrated into everything...Codex isn't there yet AIUI. I think leaving that as a TODO or even a note on the page saying it's in flux would be okay.
Codex is currently technically vapourware (there's not even an alpha release), but I have faith that it'll be usable for JS-only interfaces in the next few months (disclaimer: my team are one of those trialling it).
Codex-with-SSR (which could be used for non-JS users and to avoid FOUC) is ultra-vapourware with no plan let alone code written. It'll be a while.
