Wiktionary:Grease pit/User CSS vs. real MediaWiki preferences

One of the major hurdles facing our customization efforts is that most users want nothing to do with "monobook.css". We need a way to let users select CSS options through Special:Preferences. I think we need a developer liaison to help us with that task, right? Rod (A. Smith) 17:23, 29 May 2006 (UTC)

See User talk:Hippietrail#WT:CUSTOM. Had this page existed back then, I could have asked here :-). —Vildricianus 18:20, 29 May 2006 (UTC)

Thanks. My summary of that conversation follows. Please fix any mistakes in my paraphrasing:

—Vildricianus 21:01, 21 May 2006 (UTC)

Like, having separate skins?  :-) --Connel MacKenzie T C 21:16, 21 May 2006 (UTC)

• Without opening a gateway between the Wiktionary hackers and the actual MediaWiki hackers, there is no way for us to add features or customize besides Javascript, CSS, templates, and connecting via those to offline sites such as Connel's site where the random code is. It's true this is not user-friendly for non-hackers but there are several things we can do:
  1. We can use JS to add extra prefs pages which generate the code which can then be copied and pasted into the users's CSS and JS pages.
  2. We can coordinate a group of JS/CSS/Template hackers, possibly some of us can start hacking MediaWiki on our own machines or on a public site with CVS access for us, with another group of nonhacker Wiktionarians who can use and promote our changes to the MediaWiki devs etc, thereby opening a dialog so that when we have patches we want added to just en.wiktionary.org that we won't be ignored and won't be just 2 or 3 lonely voices
  3. There may be a lot more we can do with JS if the devs give us just the power to define a few cookies of our own - that would make possible adding JS/CSS customization directly from a new prefs page to the user's custom JS and CSS pages, among many other things.
• I think we need to continue with what we're doing, provide much more documentation and encouragement for non-hacker Wiktionarians to use our work, accept it, get used to communicating with us on improving it, help them to understand how we are held back by not having developer access to our own project, and getting such users to support our efforts on the way to either some of us becoming MediaWiki devs, or sustaining a reliable open chanel with the MediaWiki devs, or getting MediaWiki to split off to a certain degree en.wiktionary.org in some way that allows some of us to be devs just on it so that we can develop it into a dictionary-specific MediaWiki with our own extensions, etc.
• I think that's the short-term and long-term visions. — Hippietrail 00:14, 23 May 2006 (UTC)

Excellent. Now if "preload" could be allowed to work with existing pages, we could enable finely-detailed, easy configuration of Special:Mypage/monobook.css, e.g. by having JS in Special:Preferences expose something like http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?action=edit&preload=Template:custom-monobook-mentionBold-inflectionTable-serialcommaHidden&title=Special:Mypage/monobook.css , based on users selecting preference options. Rod (A. Smith) 20:04, 29 May 2006 (UTC)

Even nicer, would be to have the "Preferences tabs" (and content therein) modifyable in Special:SystemMessages. The dev's might think that is a bit heretical, as all preferences would need corresponding software/extensions. --Connel MacKenzie T C 20:26, 29 May 2006 (UTC)

This might not solve all the problems. It will give us the tabs but how will it let us invoke the actions that fiddling with the tabs should invoke? What might work is a feature request specifically for Preference tabs which manipulate only CSS - perhaps with a new CSS page that is not editable by hand - there are already several levels of CSS. I encourage you to talk to the devs on IRC which I cannot do, or file a feature request, and I will join in. — Hippietrail 21:25, 29 May 2006 (UTC)

• As a first step, I have posted Bug 6134, "The possibility of creating and manipulated cookies via JavaScript". — Hippietrail 22:38, 29 May 2006 (UTC)

  Sad to say, Brion has closed this one as invalid with only the comment "You might want to check a general JavaScript reference". I don't find that helpful at all. Is there anybody here who knows enough JavaScript to explain the problem? — Hippietrail 23:09, 29 May 2006 (UTC)

  Don't know Javascript but enough to know that you can add cookies via Javascript. That would require adding Javascript to a page, and the MediaWiki where it allows it I don't know well enough, but I suppose it must if e.g. TOC is collapsible. Davilla 16:04, 31 May 2006 (UTC)

  • I take that as encouragement that they are allowed (via Javascript.) I'll have to try soon. --Connel MacKenzie T C 23:58, 29 May 2006 (UTC)

• I'm on a roll so I also posted Bug 6135, "A way to manipulate CSS-based preferences via the GUI". Please participate in these bugs reports if you can. I fear a lone voice may well be ignored. — Hippietrail 23:03, 29 May 2006 (UTC)

  Shouldn't we ask if these things are already possible before writing them as requested features? Or maybe this is just my reaction to seeing these and requests from other folks labeled as "bugs". If it's odd to me, it's a form of dialogue anyways. Davilla 16:33, 31 May 2006 (UTC)

  I try to file a request before I'm pretty certain there's not a way to solve it already. If there is a way it's only a minor embarassment and the request will be closed. Bugzilla covers bugs and feature requests, each item is marked as one or the other but for Bugzilla purposes only, feature requests are a subtype of bug. Nothing to worry about, just jargon. — Hippietrail 17:19, 31 May 2006 (UTC)

I haven't followed all this, and I don't have my head fully wrapped around CSS and skins yet, so pardon me if I misstate, but let me see if I've got the basic picture.

1. We need a way to set our own (per-project) cookies, to affect behaviour in our per-project CSS. (I presume we're already in charge of our per-project CSS and that there's no other big problem there.)
2. The right way to get those cookies set would involve new questions and checkboxes on the Preferences page.
3. Therefore, what we need is a way to add per-project extensions or other customizations to the Preferences page.

I don't think it would be out of the question to devise a mechanism which would allow such extensions, and if implemented reasonably, I doubt the MediaWiki devs and WikiMedia admins would object.

If this is a reasonable track to go down, I'll look into the feasability of such an extension mechanism (I'm becoming somewhat familiar with the mediawiki software), and ask on the Wikitech mailing list whether they think this is a reasonable track to go down. –scs 21:34, 31 May 2006 (UTC)

Unless I've missed something, I don't think cookies have anything to do with the challenge. Instead, I think we need the ability for users to modify their Special:Mypage/monobook.css file through selections in Special:Preferences. Rod (A. Smith) 21:46, 31 May 2006 (UTC)

"Users to modify their monobook.css file"? What user monobook.css file? I don't have my own monobook.css file, do I?
(/me finally gets around to trying that special link)
Oh! Lookit that! I do potentially have my own monobook.css file, and pretty easy to get to, at that!

Anyway, all the talk about cookies (here in this subthread, that is) made me think someone was talking about having the site-wide CSS script adjust its own behavior, based on simple cookies, so that users wouldn't have to mess with per-user CSS at all (which, convenient though I now see the Special/Mypage link is, is still pretty far from what we'd want the average user to have to mess with). But come to think of it, there probably isn't a way to have CSS look at cookies. (Now where did I get the idea someone was saying there was?) –scs 22:56, 31 May 2006 (UTC)

I was wondering whether you are still considering devising a temporary solution via preload templates? —Vildricianus 22:00, 31 May 2006 (UTC)

The "preload" solution would probably be a single line of code for developers and flexible for us, so I hoped that would be easy for us to get. I don't know whether they will approve that request, though. Rod (A. Smith) 23:11, 31 May 2006 (UTC)

I don't get the "preload" business to solve this - can somebody explain it a little? — Hippietrail 02:11, 1 June 2006 (UTC)

My proposal is to use JS on Special:Preferences to create CSS and to preload it over Special:Mypage/monobook.css. The user would then preview and save the generated css. Each Special:Preference option would correspond to a display preference like "bolded mention" or "gender period visibility". Rod (A. Smith) 04:16, 1 June 2006 (UTC)

If you type in a non-existant term in the search box, and press , you are given a table of various "preload" templates that can be preloaded when you edit that entry. Once an entry exists, the preload capability no longer functions. So the "Buttons" concept is, IMHO, quite superior...see User:Vildricianus/monobook.js for examples. Using Javascript, we could be completely evil, and shrink the edit box size down to very small (or hide it entirely) when editing Monobook.js/monobook.css...and fill the screen with button options. That would be very evil though. And the Javascript would have to be pretty advanced, to be able to check and uncheck boxes. Additionally, since we can tack on goofy no-op parameters onto the URL, we could still enable raw editing under certain conditions. Of course, these ideas go far beyond "klugy" into the realm of "sinister" and I would not be comfortable doing such a hideous thing. Didn't I say something like that about the LC/UC redirects? --Connel MacKenzie T C 22:35, 1 June 2006 (UTC)