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/
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.
When visualised you see a lot of interesting things: 1) We have 6 ways of describing modal windows that take up the full screen (click 6 times on that demo to delete these 6 rules and see the stuff underneath) * .fullscreen * .modal_editor * #guider_overlay * .mw-fullscreen-overlay * .mwEmbedPlayer * .ui-widget-overlay' 2) We have 4 slightly different ways of describing a blue button * body .ui-button.ui-button-blue * .mw-ui-button.mw-ui-primary * .guider_button * button.button.blue 3) There are 13 different CSS rules for creating a pdf icon next to a link
I've also added mobile styles and styles introduced by visual editor and if you compare those to the desktop one you'll see we have even more inconsistencies.
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.
This script is still very much a proof of concept so if anyone is interested in improving the visualisation I'd encourage you to send me a pull request on github :)
Jon Robson wrote:
This script is still very much a proof of concept so if anyone is interested in improving the visualisation I'd encourage you to send me a pull request on github :)
https://github.com/jdlrobson/LivingStyleGuide
I tried this tool very quickly and it seemed to only generate a white screen. :-( My browser error console reports the following:
Uncaught InvalidCharacterError: The string contains invalid characters. Uncaught TypeError: Cannot call method 'init' of undefined Uncaught ReferenceError: lsg is not defined
MZMcBride
Yeh it's bizarre Ori had the same one. It's really strange as I have the exact same browser as Ori and can't reproduce it. I'm trying to work out what's going on and push a fix. The version on my website has a workaround around this issue in the meantime!
On Thu, Oct 24, 2013 at 4:08 PM, MZMcBride z@mzmcbride.com wrote:
Jon Robson wrote:
This script is still very much a proof of concept so if anyone is interested in improving the visualisation I'd encourage you to send me a pull request on github :)
https://github.com/jdlrobson/LivingStyleGuide
I tried this tool very quickly and it seemed to only generate a white screen. :-( My browser error console reports the following:
Uncaught InvalidCharacterError: The string contains invalid characters. Uncaught TypeError: Cannot call method 'init' of undefined Uncaught ReferenceError: lsg is not defined
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for doing this Jon.
When I used the Vector version, at first I got an all black screen, which made me think it was broken. I guess that was just a CSS rule to click and delete? :)
On Thu, Oct 24, 2013 at 2:43 PM, Jon Robson jdlrobson@gmail.com wrote:
- We have 6 ways of describing modal windows that take up the full
screen (click 6 times on that demo to delete these 6 rules and see the stuff underneath)
- .fullscreen
- .modal_editor
- #guider_overlay
- .mw-fullscreen-overlay
- .mwEmbedPlayer
- .ui-widget-overlay'
Yeah, if we don't have a bug about settling on one overlay style, we should. This is pretty bad. Maybe the work being done to split out ve.ui/oo.js/whatever we're calling it might help us settle on a standard?
- We have 4 slightly different ways of describing a blue button
- body .ui-button.ui-button-blue
jQuery.ui
- .mw-ui-button.mw-ui-primary
mediawiki.ui
- .guider_button
Extension:GuidedTour. Matt will explain more I'm sure.
- button.button.blue
This is ULS I believe? The relevant bug is https://bugzilla.wikimedia.org/show_bug.cgi?id=50599
On 10/24/2013 08:27 PM, Steven Walling wrote:
Thanks for doing this Jon.
When I used the Vector version, at first I got an all black screen, which made me think it was broken. I guess that was just a CSS rule to click and delete? :)
Yes.
Yeah, if we don't have a bug about settling on one overlay style, we should. This is pretty bad. Maybe the work being done to split out ve.ui/oo.js/whatever we're calling it might help us settle on a standard?
It's part of https://bugzilla.wikimedia.org/show_bug.cgi?id=55534
- .guider_button
Extension:GuidedTour. Matt will explain more I'm sure.
Right. As noted, it's not actually being used.
To complicate it further, I think the UX team actually now wants to go in a totally different direction with no blue buttons at all (https://www.mediawiki.org/wiki/File:WMF_DESIGN_Password_Reset.png).
So we should try to finalize that if possible. That might avoid people having to go back and change their HTML twice (once to use mw-ui, another to e.g. add another layer).
In some cases CSS can be changed alone, but sometimes they have to be changed in tandem, which is more code to touch.
CCing the design list.
Matt
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
On 24 October 2013 18:12, Matthew Flaschen mflaschen@wikimedia.org wrote:
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/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).
Yeah, we're very keen on our work being useful for other teams. An mw.ui layer on top of oojs-ui is very much an objective, and the ability to theme/skin/etc. that (so that Agora/whatever changes can be applied system-wide in one go). The commit above should get merged in the next day or so; the next step is to move it into MW core, as part of the Great VisualEditor Repo Split of 2013. :-)
This part is probably the most up in the air, and would be good to discuss at the architecture summit, among other places.
Well, hopefully we'll have made some actual implementation progress by January, but yes, very much a worthwhile thing to discuss there. I suppose we'll need to go away and write up an RfC, once we actually know what the proposal is having tried some things out in practice.
J.
It would be cool if we could have a jenkins tool or something keeping eye on the site and reporting about addition and removals of such 'similar' rules.
DJ
Le 28/10/13 11:02, Derk-Jan Hartman a écrit :
It would be cool if we could have a jenkins tool or something keeping eye on the site and reporting about addition and removals of such 'similar' rules.
In phantomjs examples directory, there is a bunch of scripts to do it, namely:
https://github.com/ariya/phantomjs/blob/master/examples/netlog.js https://github.com/ariya/phantomjs/blob/master/examples/netsniff.js
That would output some HAR which we might process somehow to generate a nice HTML report somewhere. Could even send the metrics to graphite and add that to https://gdash.wikimedia.org/
More details on phantomjs wiki:
https://github.com/ariya/phantomjs/wiki/Network-Monitoring
Le 24/10/13 23:43, Jon Robson a écrit :
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/
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.
<snip>
Is there any CSS linting utility to catch them ? If not, it would be nice to be able to run that kind of checks via Jenkins whenever someone send a patchset.
wikitech-l@lists.wikimedia.org