Last modified: 2014-06-08 00:46:15 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 13242 - Add class to the document to differentiate between logged-in/logged-out status
Add class to the document to differentiate between logged-in/logged-out status
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 11610 20576 34413 (view as bug list)
Depends on:
Blocks: css 22771
  Show dependency treegraph
 
Reported: 2008-03-04 02:20 UTC by Danny B.
Modified: 2014-06-08 00:46 UTC (History)
8 users (show)

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


Attachments

Description Danny B. 2008-03-04 02:20:38 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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-04 02:22:47 UTC
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.
Comment 2 Danny B. 2008-03-04 03:06:18 UTC
(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.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-04 03:11:21 UTC
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.
Comment 4 Danny B. 2008-03-04 03:53:51 UTC
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 }.
Comment 5 Splarka 2009-09-10 11:09:59 UTC
*** Bug 20576 has been marked as a duplicate of this bug. ***
Comment 6 FT2 2009-09-10 11:28:29 UTC
+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.
Comment 7 Andrew Garrett 2009-09-10 11:35:00 UTC
(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.
Comment 8 Andrew Garrett 2009-09-10 11:35:42 UTC
(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.
Comment 9 FT2 2009-09-10 12:11:36 UTC
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.
Comment 10 Splarka 2009-09-10 12:29:46 UTC
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.
Comment 11 Douglas Gardner 2009-09-10 22:20:08 UTC
(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)
Comment 12 FT2 2009-09-10 23:02:01 UTC
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.
Comment 13 Danny B. 2010-02-07 23:30:08 UTC
*** Bug 11610 has been marked as a duplicate of this bug. ***
Comment 14 Olaf Lenz 2011-06-24 19:30:59 UTC
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' );
  }

}
Comment 15 Krinkle 2012-03-05 00:53:46 UTC
*** Bug 34413 has been marked as a duplicate of this bug. ***
Comment 16 Subfader 2012-03-05 11:21:34 UTC
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.)
Comment 17 Theaitetos 2013-05-14 16:01:57 UTC
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.
Comment 18 Jackmcbarn 2014-06-08 00:46:15 UTC
It appears that the fix for bug #47812 fixed this as well. Closing.

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


Navigation
Links