Last modified: 2008-10-06 08:25:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6135 - A way to manipulate CSS-based preferences via the GUI
A way to manipulate CSS-based preferences via the GUI
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: css
  Show dependency treegraph
Reported: 2006-05-29 23:00 UTC by Andrew Dunbar
Modified: 2008-10-06 08:25 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Andrew Dunbar 2006-05-29 23:00:58 UTC
On the English Wiktionary we are currently devising a 
bunch of ways for users to customize what they see in 
various ways. These are implemented using templates which 
contain CSS to hide unwanted variants and show only the 
preferred variant.

The problem is that the vast majority of users don't know 
about and don't want to know about editing the custom CSS 

If we had a preferences page that resulted in a CSS page 
somewhere this would completely solve the problem. The 
page or pages would need to be customizable via MediaWiki: 
messages much like the navigation bar and 
internationalized strings are currently implemented.

The resulting CSS might be a whole other internal CSS page 
like wikibits which is not editable by the user, of it 
could simply be served as part of the current custom CSS 
page but not presented to UserName:Fred/monobook.css etc
Comment 1 Rod A. Smith 2006-05-30 00:14:59 UTC
It's not generation of CSS that we need, since we can 
already generate CSS with templates. Specifically, we 
ned two things:
# Enable us to add options to a (new?) tab on 
# Expose a way to save the output of a template 
programatically. E.g. if a query string could use 
the "preload" option to overlay whatever already exists 
at [[Special:Mypage/monobook.css]], the user could then 
see the generated CSS and commit that CSS over their 
existing monobook.css.
Comment 2 Rob Church 2006-05-30 00:55:01 UTC
Please provide an example of something which couldn't be added as a user
preference (even via an extension), but which could be added in some other form.

Something about the request doesn't add up to me. A lot of dynamic programming
of core functions through wiki markup et al. makes me very nervous.
Comment 3 Rod A. Smith 2006-05-30 02:10:58 UTC
There is no specific request to avoid adding user 
preferences or extensions.

Existing ParserFunctions are able to producing content 
for .css files, but if you would prefer to generate .css 
file content using a server extension, that would be 
great as well. Regardless of how the CSS is generated, 
the key missing component now is to allow users customize 
and save their .css preferences using an extensible set 
of preferences without having them open their CSS file 

Ideally, each user customization (e.g. whether to show 
certain classes of words in italics) would be managed as 
a user preference. Given specific settings for those 
preferences, a CSS file can be created that will cause 
the pages to display as the user desires.

Users comfortable with CSS already change their 
[[Special:Mypage/monobook.css]] files to accomplish the 
customization today. The majority of users, however, are 
sqeamish even about copy-pasting sample CSS over their 
[[Special:Mypage/monobook.css]]. We are just looking to 
assist those users with modifying their CSS preferences.

I suggested the solution that I hoped would be the least 
amount of developer work: allowing the "preload" query 
string parameter to overlay existing 
[[Special:Mypage/monobook.css]]. By allowing that option 
to overlay the existing .css, we could write our own CSS 
generation in the form of ParserFunctions.

If I understand your reply above, it seems to recommend a 
more complete solution, i.e. adding user preferences and 
somehow linking those preferences to the server-side 
generation of users' css files.
Comment 4 Niklas Laxström 2008-10-06 08:25:29 UTC
The Gadgets extension looks just suitable solution for this request.

Note You need to log in before you can comment on or make changes to this bug.