"If people want to style a UI they should be exploring new skins rather than adding global rules"
WTF. You realise that users can't just add new skins right? And it's especially pointless when they just want to add a couple of new rules.
Wikis being able to be different from each other is a good thing.
See my responses to threads above. Adding global rules leads to dead css code and a css mess and is a habit we should move away from. We should provide better ways to allow customisation.
How is this better in that way? Users and site administrators rarely have direct access to skins, extensions, and the site configuration itself. Unmaintained css, wherever it is, will 'die'. Changing the functionality of existing features will simply break stuff, as what is proposed cannot be backwards compatible. As people have pointed out already, being able to customise the overall appearance of an existing skin is expected and well-used functionality. There is no good reason to remove this.
Adding a separate content-scoped css interface message that would be called after common.css and skin.css might not be a bad idea, however, since that way users could put all the content-specific things there. Be a little neater away from the wider-scope stuff, and since it's all content anyway, definitions could be a bit shorter since the #content bit would be added automatically...
Hmm, perhaps we could deprecate 'common.css' in favor of 'content.css', and have people do skin specific hacks in Vector.css and Monobook.css? That'll mean people who just want content custom styling could get them easily (hence fixing problems for mobile), without taking away any customizability. content.css can be 'scoped', leaving the rest of them as is.
There would still be plenty of valid uses for the common.css, even with a content.css added. It would be neater to have more of the stuff in the content.css, but the content is simply not the only thing all skins tend to share in common (or, in some cases, that groups of skins share in common).
