Add class to the document to differentiate between logged-in/logged-out status
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47812

bzimport added a project: MediaWiki-Parser.Via ConduitNov 21 2014, 10:07 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz13242.
Danny_B created this task.Via LegacyMar 4 2008, 2:20 AM
bzimport added a comment.Via ConduitMar 4 2008, 2:22 AM

ayg wrote:

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.

Danny_B added a comment.Via ConduitMar 4 2008, 3:06 AM

danny.b wrote:

(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.

bzimport added a comment.Via ConduitMar 4 2008, 3:11 AM

ayg wrote:

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.

Danny_B added a comment.Via ConduitMar 4 2008, 3:53 AM

danny.b wrote:

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 }.

bzimport added a comment.Via ConduitSep 10 2009, 11:09 AM

herd wrote:

*** Bug 20576 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitSep 10 2009, 11:28 AM

FT2.wiki wrote:

+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.

werdna added a comment.Via ConduitSep 10 2009, 11:35 AM

(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.

werdna added a comment.Via ConduitSep 10 2009, 11:35 AM

(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.

bzimport added a comment.Via ConduitSep 10 2009, 12:11 PM

FT2.wiki wrote:

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.

bzimport added a comment.Via ConduitSep 10 2009, 12:29 PM

herd wrote:

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.

MC8 added a comment.Via ConduitSep 10 2009, 10:20 PM

(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)

bzimport added a comment.Via ConduitSep 10 2009, 11:02 PM

FT2.wiki wrote:

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.

Danny_B added a comment.Via ConduitFeb 7 2010, 11:30 PM

danny.b wrote:

*** Bug 11610 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitJun 24 2011, 7:30 PM

olaf wrote:

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' );
}

}

Krinkle added a comment.Via ConduitMar 5 2012, 12:53 AM
  • Bug 34413 has been marked as a duplicate of this bug. ***
Subfader added a comment.Via ConduitMar 5 2012, 11:21 AM

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

bzimport added a comment.Via ConduitMay 14 2013, 4:01 PM

blakharaz wrote:

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.

Jackmcbarn added a comment.Via ConduitJun 8 2014, 12:46 AM

It appears that the fix for bug #47812 fixed this as well. Closing.

Add Comment