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, skins don't have well defined APIs. Currently, 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. Changing a skin can easily involve updating code in hundreds of locations - and there's no way to be sure which assumptions have been made - effectively discouraging iteration. 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, effectively discouraging creation. In the best case, features like mw.util.addPortletLink 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 too different and nothing works unless it is written specifically for it.

Solution
Skins can be made out of 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, which other software can rely on. 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