On 10/24/2013 05:43 PM, Jon Robson wrote:
I think we are all in agreement that the CSS in MediaWiki is a mess but it's not clear how to solve the mess.
I think I've created a useful bit of JS to visualise this mess and make a path to solving it clearer.
If you visit: http://jonrobson.me.uk/lsg/
This is an interesting tool. I think mostly we have a pretty good understanding what the issues are, but it's still a lot of work. My understanding (correct me if I'm wrong):
1. The design and UX team generally want to transition from jquery.ui to a mediawiki.ui library. 2. VE has special issues since they want it to be usable as a stand-alone editor, but they are making progress in factoring out oojs-ui (a new UI library) from ve.ui (https://gerrit.wikimedia.org/r/#/c/88896/). I think they are interesting in making mediawiki.ui a custom layer on top of the more general oojs-ui library (kind of like you can have jquery ui themes. but probably with significant differences in the details). This part is probably the most up in the air, and would be good to discuss at the architecture summit, among other places.
You will see in the dropdown mediawiki vector styles. This is a CSS file I created by manually concatenating all CSS files loaded by default on desktop.
Can you explain how you did this? I don't see GuidedTour being loaded by default on desktop (and it certainly should not be). See e.g. http://httparchive.org/viewsite.php?pageid=11675485#waterfall
- .guider_button
Good catch. This is not actually used anymore. It was originally from a third-party library (GuidersJS), which we have now forked/merged into GuidedTour. I have been planning to make the UI in GuidedTour sit on top of of mediawiki.ui for a while (including things where mediawiki.ui doesn't have an implementation yet). However, in the meantime, you're right we should remove the no longer needed CSS (https://bugzilla.wikimedia.org/show_bug.cgi?id=56142).
- There are 13 different CSS rules for creating a pdf icon next to a link
It's helpful to link to existing bugs (https://bugzilla.wikimedia.org/show_bug.cgi?id=54604)
Changing the parser would probably make the CSS simpler, like you said. Of course, that requires a more testing than a simple CSS change.
The reason for searching for pdf# and pdf?, rather than just PDF is probably to avoid false positives.
Some of those are actually in English Wikipedia's https://en.wikipedia.org/wiki/MediaWiki:Common.css, not core.
They chose to override the PDF icon. If it's libre, and there's consensus to use it in core, we could do that.
They also added selectors for mw_content, which seems to only be used in Modern and thus should be moved to https://en.wikipedia.org/wiki/MediaWiki:Modern.css (at least until it can use the same content ID as everyone else).
I encourage you to dig into these styles and notice similarities and help us fix this mess! I'd suggest we start moving the common styles into a common library in MediaWiki core and change all our extensions to make use of the same class names. It's a big job but I think we can get this.
Yes, the way I see it, for simple things like PDF styling, it should continue using the common/skin framework. For "features", like buttons and dialog, we seem to be heading towards mediawiki.ui.
Matt Flaschen