Requests for comment/Redo skin framework

We would like to create a skin framework to:


 * Make modification, extension and creation of skins quicker and less prone to error
 * Achieve compatibility between skins through an object-based API on the server and client
 * Liberate developers from having to maintain HTML output compatibility between skins

Problem
Currently, most MediaWiki UI elements don't have APIs, or have poor ones, and instead the HTML output by the skins for these elements is treated as the API. The HTML output of skins is kept as similar as possible between each skin as to support the many assumptions that are made by core, extension and gadget software that modify them on the client. On the server side, the few features we do have are centered around this approach of nearly identical HTML output being treated as the API.

This dependency is extremely fragile and resistant to change. Changing a skin or even just adjusting a style can easily involve updating code in hundreds of locations – and there's no way to be sure which assumptions have been made – discouraging iteration and innovation. New skins that do not have a nearly identical HTML structure will fail to work with many features and take a very long time to come to maturity, discouraging creation. In the best case, features like  try to work around minor differences, but still make lots of assumptions about the HTML. In the worst case, a skin's HTML output is so different that nothing works unless it is written specifically for it.

Solution
Pages' UI elements can be made out of skinned widgets – server- and client-side objects which render/manage discrete elements on the page. A skin can then have a standard API on the server and client, on which other software can rely. The structure of widget objects on the server can be rendered only in the final stage, allowing them to be interacted with by extensions before responding to the client. Once on the client, a structure of widget objects can be built, bound to the skin, and be used to interact with the skin programmatically at and after startup. Both the server and client code can be extended, reducing duplication while supporting the development of new features.

Proposal

 * Skin class for defining which widgets to use
 * Standard widgets which can be styled and extended
 * Client-side API for defining dynamic rendering and behavior of widgets
 * Server-side API for defining static rendering and behavior of widgets
 * Convert existing skins to use the new system
 * Document the server and client APIs
 * Introduce a radically different skin (doesn't need to be the "next" skin) as a test to prove flexibility