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).
3) 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