Last modified: 2014-06-08 00:46:15 UTC
Suggesting perhaps class="anonymoususer" (or simply "anonymous" - but that might be confusing) to be added if page is loaded by anonymous user so there can be different style set for registered and anonymous users. There should be also the "registereduser" (or simply "registerd" - but that might be confusing as well) complementary class added to allow balancing of the cascade weight.
We should think carefully about possible implementation-specific limits to the number of CSS classes on an element before we start adding yet more stuff like this. CSS wasn't really designed for this kind of thing. This sort of feature might be best suited to implementation in JavaScript.
(In reply to comment #1) > This sort of feature might be best suited to implementation in JavaScript. Definitely not. CSS is different level than JS. Lot of computers have JS off because of security reasons. And it is very imprudent to have CSS rely on JS. Problems with cascade, necessity of crossbrowser DOM solutions (-> more work) etc. While simple adding of body.kindofuser before current selectors where necessary is a question of second and can be done much more easier than wrestle with JS.
Implementing client-side stuff in CSS is better accessibility-wise than JS, but in terms of implementational complexity it's worse for doing anything remotely complicated. Trying to squeeze stuff into CSS that it was never really intended to handle, when JavaScript is the more logical tool for the job, is of dubious benefit. Not that this is any worse than the page-title class I added. But I'm getting worried about CSS class creep on <body> here.
Page title should have been an id instead of class since it's unique (I actually proposed it in bug 6214) but that's a topic to other place. What kind of complexity you're talking about? Say I want eg. simply different background of pages for anonymous users. Why should I take a canon (JS) to hit this mosquito? Using JS for that wouldn't be logical at all, when I can have body.anonymoususer { some CSS goes here }.
*** Bug 20576 has been marked as a duplicate of this bug. ***
+1 A common problem where this would be helpful is for users who normally edit logged in, but then accidentally edit logged out, exposing their IP and often requiring oversight/suppression. If a CSS element was added to the editing page, depending upon whether logged-in or logged-out, users who wish to avoid accidentally editing logged-out, could set up their monobook.css to style the edit box if they are logged in, which would make it immediately apparent to them (by lack of shading) if they clicked on an "edit" tab when accidentally logged out.
(In reply to comment #6) > +1 > > A common problem where this would be helpful is for users who normally edit > logged in, but then accidentally edit logged out, exposing their IP and often > requiring oversight/suppression. > > If a CSS element was added to the editing page, depending upon whether > logged-in or logged-out, users who wish to avoid accidentally editing > logged-out, could set up their monobook.css to style the edit box if they are > logged in, which would make it immediately apparent to them (by lack of > shading) if they clicked on an "edit" tab when accidentally logged out. > There's no need for a class on <body> for this. If they set it up in their monobook.css, then it obviously wouldn't apply when they were logged-in.
(In reply to comment #7) > There's no need for a class on <body> for this. If they set it up in their > monobook.css, then it obviously wouldn't apply when they were logged-in. > I meant logged-out, of course.
A class on the main edit box would be helpful though. I'm not sufficiently skilled at CSS to be able to tell whether as the edit page stands, a user could add styling to it in their monobook.css (so the edit textbox could have different style logged-in and logged-out). But that's all that's needed for my own concern in this area.
Since r28786 (version 1.12), the anonymous edit warning has had id="mw-anon-edit-warning". It is a sibling of the edit form, and as there are a variable number of siblings between them (due to the toolbox being optional, for example) it is convoluted but possible to style the <textarea> based on the existence of this id: body.mediawiki #mw-anon-edit-warning + * + * + * + * + * + form #wpTextbox1, body.mediawiki #mw-anon-edit-warning + * + * + * + * + form #wpTextbox1, body.mediawiki #mw-anon-edit-warning + * + * + * + form #wpTextbox1, body.mediawiki #mw-anon-edit-warning + * + * + form #wpTextbox1, body.mediawiki #mw-anon-edit-warning + * + form #wpTextbox1, body.mediawiki #mw-anon-edit-warning + form #wpTextbox1 {background-color:#ff8888 !important;} This won't work in IE6 or lower, and may cause problems in Opera 8, but it works in all versions of Firefox back to Mozilla (in theory). The real advantage of this, is, in Mozilla based browsers, you can add it to your userContent.css file, so it will apply to ALL wikis you visit (that are on version 1.12 or higher), not just ones you have an account on. It is a bit fragile, but seems to work fine now. But still, a class on the body or edit form would be doubleplusgood.
(In reply to comment #9) > A class on the main edit box would be helpful though. > > I'm not sufficiently skilled at CSS to be able to tell whether as the edit page > stands, a user could add styling to it in their monobook.css (so the edit > textbox could have different style logged-in and logged-out). But that's all > that's needed for my own concern in this area. > textarea { color : lime; background : black; } (for example)
Works for me. Would still like classes as described, so users can configure their browsers to apply a warning style when they're /not/ logged in, not just when they are.
*** Bug 11610 has been marked as a duplicate of this bug. ***
I would also like this enhancement! Note that it is very simple to create a very simple skin that adds this class to the body tag and otherwise is identical to one of the standard skins: <?php if( !defined( 'MEDIAWIKI' ) ) { die( -1 ); } include 'Vector.php'; class SkinOlenz extends SkinVector { /* Functions */ var $skinname = 'olenz', $stylename = 'olenz', $useHeadElement = true; /* Extend the body element by a class that tells whether the user is logged in or not */ public function addToBodyAttributes( $out, &$bodyAttrs ) { if ($this->loggedin) { $bodyAttrs['class'] = $bodyAttrs['class'] . ' auth'; } else { $bodyAttrs['class'] = $bodyAttrs['class'] . ' noauth'; } } function setupSkinUserCss( OutputPage $out ){ parent::setupSkinUserCss( $out ); $out->addStyle( 'olenz/olenz.css', 'screen' ); } }
*** Bug 34413 has been marked as a duplicate of this bug. ***
I second that request. According to action classes in the body tag https://bugzilla.wikimedia.org/show_bug.cgi?id=4438 there should be classes for the user status: * user-anon * user-logged Maybe expand it for the user rights * user-sysop * etc. Technically this should be no problem since the same is added as javascript variables to the output ("wgUserGroups": ["*"] etc.)
A new class ".isanonymous" would only allow styling of pages as a whole for anonymous users (unless one wants to clutter ones css with thousands of dependencies ".isanonymous > * > table ..."). Wouldn't it be a better to have an additional mediawiki skin, which can be edited via say "MediaWiki:Anonymous.css", which overrides/adds stuff only when users are not logged in? That way, one could redefine the appearance of every single element instead of the page as a whole, like hiding parts of a page or making wikitables green (".wikitable { background-color: green; }"). Especially since (future) extensions might add stuff that can then be changed for anon users accordingly.
It appears that the fix for bug #47812 fixed this as well. Closing.
