MediaWiki talk:Monobook.css

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Geeoharee (talk | contribs) at 18:04, 4 June 2004 (→‎Reduce the white space in tables and the side bar). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

People may want to examine main.css.

Tabs at top of page body

I have found the tabs to be extremely confusing. It has taken me 2 days to finally figure out that the leftmost tab is more or less randomly labeled (ok, ok, I know there's logic behind it, but it took me 2 days to figure it out--sort of--). Some of the labels used are not consistent with standard conventions. And the behavior isn't always consistent with standard conventions.

  1. Consistency of text in left-most tab. Right at the moment (for me) it says "message". I don't want to send or leave a message, so I'm never going to click on that tab. I'm not even sure what it does, although I *suspect* that it displays the current version of this page. I don't know why it doesn't say "current". Sometimes it says "about", sometimes "article", sometimes "special", sometimes all kinds of things, none of which mean anything in particular to me. I suggest that, if you're in editing mode, it should always say "current" or "article" to display the current version of the page. Do I or anyone else care whether the article is a special article or some other odd-case kind of article? No. I just want the current version.
  2. Word choice for left-most tab. "About" should always display the name of the software and the current version. That's by standard convention under Mac and Windows and I think X interfaces, too. "Message" should always allow you to type an instant message or email message. There's no reason for either of these text choices to be used except with those meanings.
  3. Behavior of tabs: Tabs in standard interfaces switch back and forth among different displays. So, at the moment, the Discussion tab is current for me. If I click one of the other tabs and then click Discussion again, I should return to where I am. But I don't; I am given an *empty* Editing page. I have to use my browser's back button to get back to this edit. This is not standard behavior for tabs and it's more confusing than NOT having the tabs. Secondly, clicking the Watch tab when it appears should bring up a different display (standard tab behavior). It doesn't; it actually *performs a function* and changes the status of something (adds it to my watchlist), which is actually a little scary. It wasn't scary when it was a link that said "Add to my watchlist", but I do not expect tabs to perform functions.
  4. I'm not even sure what all of the tabs do (e.g., the "+") because I have been thoroughly intimidated by the fact that the ones I *have* clicked do not do what I expect them to, and I don't want to be mucking things up by clicking something I don't understand. And I'm a bold, experienced computer user!
  5. Consistency of labels for same function. Argh, let's see, when I'm displaying the article, there's a tab called View Source but not a tab called Edit. Or--wait--is it only in MediaWiki that it's called view source and everywhere else it's called edit? Huh, hang on, if I go to the discussion page, there's an Edit tab. What the heck is view source, then? I'm confused all over again.
  6. Pop-up help messages for tabs are inconsistent. At the moment, they are:
    • Article/Message/Special/etc.: "View the content page". Very nice! Very consisent! Tab shld be this consistent and clear.
    • Discussion: "Discussion about the content page." First pop-up was a verb form (view...); this is a noun ("discussion"); make consistent. E.g., "View discussions about the content page".
    • Edit: "You can edit this page." Now it's chatty rather than a verb or a noun. How about "Edit this text" (so that it applies either to content page or discussio page)?
    • Move: "Move this page"; good simple verb form.
    • History: "Past versions of this page". Noun again. And not the most helpful interpretation; I think that for newcomers (and for me) the most important thing is that we can "View edit history of this text".

Elf | Talk 17:00, 3 Jun 2004 (UTC)

+ is for posting a comment, view source is for protected pages. I am not sure there is a problem with these. Dori | Talk

Most of this isn't changed in the stylesheet.

  1. "Message" is what MediaWiki pages are called instead of articles. Suggest changes at MediaWiki:Nstab-mediawiki.
  2. "About" is the current name for the Wikipedia namespace. Suggest changes at MediaWiki talk:Nstab-wp
  3. Regarding behavior of tabs - they are not really tabs. They are links to separate pages.
  4. The "+" is a link to "post a comment"
  5. "View Source" is what you see on protected pages. All pages in the MediaWiki namespace are now protected.
  6. Pop-up help messages for talk pages can be discussed at MediaWiki talk:Tooltip-talk and MediaWiki talk:Talkpage
  7. The "You can edit this page" can be discussed at MediaWiki talk:Tooltip-edit
  8. "Past versions of this page" can be discussed at MediaWiki talk:Tooltip-history

Angela. 17:53, 3 Jun 2004 (UTC)

Angela, I think you missed the point on #3. To any user familiar with standard interfaces, it looks like a tab, and the expectation is that it will behave like a tab. Elf's observations are on-target. If they are not really tabs, then they should not look like tabs, or else confusion will result. I like the idea of using tabs to get to the various pages associated with the content page, but this implementation needs some work.

There is a somewhat complex relationship between the content page, the talk page for the content, the edit page for the content, the history of the content, the edit page for the talk page of the content, and the history of the talk page of the content. The current tabbed presentation only obscures or confuses that relationship.

The Watch option should be an option box -- as it is under the standard skin. I can't think of any way to present Move other than either as a command button (like "Save page" is now), or as a tool in the toolbox box.

There is, perhaps, a better place to put each of these individual points, but I think we're using this page right now to discuss what the English Wikipedia-specific style sheet should be like. For now, let's keep these all together here. -Rholton 19:22, 3 Jun 2004 (UTC)

Point #1 is very valid. Some more consistency would be nice, why not use 'article' for articles and 'content page' for everything else? (and 'user page' for userpages) ✏ Sverdrup 19:57, 3 Jun 2004 (UTC)

Ok, I wasn't saying they shouldn't not look like tabs, just saying that there isn't a way to make them behave like tabs because they're not tabs. This is beyond the scope of changing the stylesheet. Perhaps a [http://sourceforge.net/tracker/index.php?func=browse&group_id=34373&atid=411195&set=custom&_assigned_to=0&_status=1&_category=100&_group=100&order=open_date&sort=DESC&offset=0

F sourceforge request] would be better. I disagree everything should be done on this page. Changing the interface text is not the same as changing the stylesheet. It will be a lot easier to do if separate discussions are kept on the correct talk pages. Angela. 20:01, 3 Jun 2004 (UTC)

Font

Issues related to default fonts.

Font size

Kudos for using relative font sizes. Default is a small font size, however; too small for comfort. So I can change my browser settings for this site but when I then click on an external link, the fonts there are overwhelmingly large. Sure, an experienced Wiki user can change his/her skin, but most readers will be hit and run, looking for info, not to settle in and customize their interfaces. I *like* the sizes of headings; relative sizes are now much clearer between the different levels of headings and much different from body text, esp. with the hairline for the top-level headers. Elf | Talk 17:41, 3 Jun 2004 (UTC)

So--I guess voting has been suggested:

Make body text larger

  1. Elf | Talk 17:41, 3 Jun 2004 (UTC)
  2. sannse (talk) 17:46, 3 Jun 2004 (UTC)
  3. Angela 17:53, 3 Jun 2004 (UTC)
  4. Michael Warren 18:02, 3 Jun 2004 (UTC)
  5. Rholton 19:25, 3 Jun 2004 (UTC)
  6. Fredrik (talk) 20:23, 3 Jun 2004 (UTC)
  7. Dori | Talk 23:19, Jun 3, 2004 (UTC)
  8. Arwel 00:20, 4 Jun 2004 (UTC)
  9. mav 00:43, 4 Jun 2004 (UTC)
  10. Popsracer 01:04, 4 Jun 2004 (UTC)
  11. jallan 02:13, 4 Jun 2004 (UTC)
  12. Tim Starling 03:33, Jun 4, 2004 (UTC)
  13. Mikez 09:53, 4 Jun 2004 (UTC) (what is a small font in MonoBook, is completely unreadable in Standard skin, and what is small in Standard, is ordinary in Mono... I think that's no good)
  14. Jamesday about 144% (120% squared) instead of the 123% of x.small or 9px seems like a good test - that should be user interface medium for many people - then maybe people will ask for smaller.
  15. NealMcB 16:39, 2004 Jun 4 (UTC)

Body text size is fine

  1. blankfaze | •­• 02:31, 4 Jun 2004 (UTC) - mine is perfect
  2. Chopchopwhitey 03:45, 4 Jun 2004 (UTC) Default size is good on Linux Firefox 0.8.

Font typeface

See also: Wikipedia talk:Serif or sans-serif

Don't specify a font. Leave as browser default

  1. Angela 17:53, 3 Jun 2004 (UTC)
  2. Rholton 18:42, 3 Jun 2004 (UTC)
  3. Dori | Talk 23:19, Jun 3, 2004 (UTC)
  4. mav 00:49, 4 Jun 2004 (UTC)
  5. TreyHarris 00:58, 4 Jun 2004 (UTC)
  6. jallan 02:21, 4 Jun 2004 (UTC)
  7. Jorge Stolfi 03:30, 4 Jun 2004 (UTC)
  8. Chopchopwhitey 03:50, 4 Jun 2004 (UTC)
  9. Lupo 09:08, 4 Jun 2004 (UTC)
  10. Jamesday 14:35, 4 Jun 2004 (UTC) but if one has to be there, sans-serif of some sort.
  11. NealMcB 16:39, 2004 Jun 4 (UTC)

Combine serif texts with sans-serif menus

  1. till we ☼☽ | Talk 21:44, 3 Jun 2004 (UTC)

Comments on Font Typeface

I think I agree with Angela, though I'm not entirely sure what she means by "browser default". In IE6, if you specify sans-serif, you are forced to use Arial. That, to me, is not any better than forcing me to use any other font. IE does have a font preference, but it makes no distinction between Serif or Sans-serif. If no font (or font style?) is specified, then the user's choice is used. That's how the standard skin works. That allows me to use Arial Unicode MS, which eliminates all those little boxes, and which I now use as my "default" font for all browsing. -Rholton 18:40, 3 Jun 2004 (UTC)
I think I mean just don't specify anything. Angela. 20:01, 3 Jun 2004 (UTC)
Yes. Wikipedia should not be forcing any common font or any common font size on users who employ different browsers on different sizes of terminals and set their screen at various different resolutions. Some users may have visual problems and need larger fonts. The user should come first. jallan 02:21, 4 Jun 2004 (UTC)
Note that the user font size is taken into account already, somebody who increased the IE default size gets a larger wikipedia. The question is if the IE default (equals 16px) is better than our own default (122% of 9pt minimum currently). -- Gabriel Wicke 11:52, 4 Jun 2004 (UTC)

Color of links

The main problem I've seen here is that visited edit links are the same colour as visited articles. Which means if you have clicked on an edit link it is no longer possible to tell whether the article exists or not. -- sannse (talk) 17:49, 3 Jun 2004 (UTC)

I would suggest the colour scheme presented at Wikipedia:Village_pump#Link_colours as best, which also seems to address sannse's problem. -- Michael Warren 18:00, 3 Jun 2004 (UTC)

That doesn't change the problem with visited edit links I'm afraid (I have it on User:Sannse/monobook.css and still see the same problem). -- sannse (talk) 20:39, 3 Jun 2004 (UTC)
Yeah, it looked like it did, but it must have been a temporary thing (if you hit Back, it does seem to stay red on the page you return to, but if you reload, it goes to the visited link colour). Can the CSS be that finely tuned? -- Michael Warren 20:44, 3 Jun 2004 (UTC)
The active link colour is set the same as the edit link - that's why it looks OK when you hit Back (I intend to change this on mine, and think it shouldn't be done this way on the default) -- sannse (talk) 21:21, 3 Jun 2004 (UTC)
Even worse, links to stubs below the user-defined threshold and to unwritten articles have the same red color. At least that one needs to be changed. andy 07:48, 4 Jun 2004 (UTC)

I'm not sure about stubs, but the other default colours were: a { color: #0000FF; } a:active, a:visited { color: #800080; } a.new { color: #CC2200; } a.interwiki, a.external { color: #3366BB; } - which is slightly different from the example mentioned above. This doesn't solve the visited edit link problem though -- sannse (talk) 16:49, 4 Jun 2004 (UTC)

Return to MediaWiki 1.2 defaults

  1. Angela 17:53, 3 Jun 2004 (UTC)
  2. Fredrik (talk) 20:23, 3 Jun 2004 (UTC)
  3. Elf | Talk 20:55, 3 Jun 2004 (UTC)
  4. till we ☼☽ | Talk 21:44, 3 Jun 2004 (UTC)
  5. Dori | Talk 23:19, Jun 3, 2004 (UTC)
  6. mav 00:51, 4 Jun 2004 (UTC) (please, please, please!)
  7. jallan 02:23, 4 Jun 2004 (UTC)
  8. Jorge Stolfi 03:34, 4 Jun 2004 (UTC) (I suppose MediaWiki 1.2 is like the "standard" skin, is it?)
  9. andy 07:48, 4 Jun 2004 (UTC)
  10. Lupo 09:08, 4 Jun 2004 (UTC)
  11. Mikez 09:53, 4 Jun 2004 (UTC)
  12. Jamesday 14:35, 4 Jun 2004 (UTC) though some change for stub color is probably worth voting on later - just not the same as "completely missing article".
  13. NealMcB 16:39, 2004 Jun 4 (UTC)

Don't return to MediaWiki 1.2 defaults

  1. blankfaze | •­• 02:34, 4 Jun 2004 (UTC) - I just got things how I like them!

External link icon

No icons by default

  1. Dori | Talk 23:19, Jun 3, 2004 (UTC) (only if color changes between ext and int lks obviously)
  2. Maximus Rex 23:27, 3 Jun 2004 (UTC)
  3. Arwel 00:21, 4 Jun 2004 (UTC)
  4. mav 00:52, 4 Jun 2004 (UTC) (only if MediaWiki 1.2 link color defaults are restored)
  5. jallan 02:25, 4 Jun 2004 (UTC)
  6. 03:35, 4 Jun 2004 (UTC) (only if color changes between ext and int lks obviously)
  7. Lupo 09:08, 4 Jun 2004 (UTC) if link colors are changed to make the distinction
  8. Mikez 09:53, 4 Jun 2004 (UTC) (even more important than adding more link colours)
  9. Jamesday 14:35, 4 Jun 2004 (UTC)

Icons by default

  1. Timwi 23:24, 3 Jun 2004 (UTC)
  2. Gabriel Wicke 12:45, 4 Jun 2004 (UTC)

Other

  1. Angela 17:53, 3 Jun 2004 (UTC) (It depends whether the external link colour is changed.)
  2. Elf | Talk 02:24, 4 Jun 2004 (UTC) (I like the idea of distinguishing external links. I think icon is OK. But it's confusing when everything not in the article namespace has this icon--e.g., "Edit summary" and "public domain" text on each edit page display this link, and to most people these are not external links, they're maybe help pages, so using the same icon is confusing. )
  3. Phil | Talk 11:02, Jun 4, 2004 (UTC) (I have already suggested—to User:Gwicke who originated the idea—the possibility of having a different icon for an Interwiki link as opposed to a link which is truly external to the wikipedia project. I wonder if it would be possible to present us with a selection that we can choose in our CSS file?)
Changed the default to no styling for interwiki now apart from the 1.2 colour (that's the same for external). That should eliminate most of those icons on meta. -- Gabriel Wicke 12:09, 4 Jun 2004 (UTC)

Underlining links

I was among those who voted for underlined by default (I have since changed my mind), but now there is a bug and removing the check from the "Underline links" option does not change the behavior. Should we force it on users this way (this also seems to negate browser settings)? Dori | Talk 03:48, Jun 4, 2004 (UTC)

I wish I had known of a vote. This is disastrous! Little horizontal lines everywhere cutting through the text! AHHHHHHHH! My browser's no-underlining of links is even superceded by this! Ackbar! --AquaRichy 07:04, 4 Jun 2004 (UTC)

Me too. This also removes the hover indicator. The link colour is changed already, so the main reason (links look too similar to text) should be mostly gone since yesterday. -- Gabriel Wicke 12:18, 4 Jun 2004 (UTC)
You can override it in your user CSS. The rest of us like our underlines. -- Cyrius|✎
  1. I don't know the css - syntax and don't really have time nor interest to learn it.
  2. And why why why is there a preference, if it is neglected??? I don't demand you to see links whithout underbars, but since I don't like them, please let me use the possibility to get rid of them, OK?
Mikez 09:53, 4 Jun 2004 (UTC)

My vote is that link underlining in the default skin should respect the user's browser settings. Ditto for link colors (except of course for the external and missing-article link colors, which are not defined by the browser and so must be chosen Wikipedia.) Jorge Stolfi 13:16, 4 Jun 2004 (UTC)

Color of non-main namespace pages

Should non-article pages have a different background color than articles?

(Non-article = talk:, as well as user:, wikipedia:, special:, MediaWiki:, template:, category:, and their talk pages)

yes

  1. mav 00:58, 4 Jun 2004 (UTC) (this is needed to establish more differentiation between content and metadata and help ensure our article count is not inflated/polluted by pseudo-namespace pages like Sandbox:maveric149).
  2. TreyHarris 02:00, 4 Jun 2004 (UTC)
  3. Elf | Talk 02:21, 4 Jun 2004 (UTC) (I don't know that I care what color--except that gray with current scheme for rest of page would be wayyyy tedious.)
  4. jallan 02:26, 4 Jun 2004 (UTC)
  5. Dori | Talk 03:28, Jun 4, 2004 (UTC) (making me vote again :)
  6. Jorge Stolfi 03:37, 4 Jun 2004 (UTC)
  7. Chopchopwhitey 03:53, 4 Jun 2004 (UTC)
  8. Lupo 09:08, 4 Jun 2004 (UTC)
  9. Mikez 09:53, 4 Jun 2004 (UTC)
  10. Timwi 13:30, 4 Jun 2004 (UTC)
  11. KRS 13:36, 4 Jun 2004 (UTC)
  12. Jamesday 14:35, 4 Jun 2004 (UTC)

no

  1. Yellow color is ugly. If you have any color, please make it something more tasteful. Latitudinarian 02:22, 4 Jun 2004 (UTC)
    • This vote is not a vote for any particular color (see below for that) - it is a vote to have non-articles be different color than white. --mav 04:05, 4 Jun 2004 (UTC)
  2. Gabriel Wicke 12:22, 4 Jun 2004 (UTC)

If they did have a different color:

Color everything that is not an article yellowish, again

  1. till we ☼☽ | Talk 21:44, 3 Jun 2004 (UTC)
  2. Dori | Talk 23:19, Jun 3, 2004 (UTC) (not that I care that much about yellowish, but anything different from articles)

Color everything that is not an article pastel orange

  1. Yay! Pastel orange! ugen64 01:17, Jun 4, 2004 (UTC)

Color everything that is not an article light blue

  1. Lupo 09:08, 4 Jun 2004 (UTC) (BTW, see m:Gallery of user styles#Lupo's minor tweaks for something quite akin to what I voted for here.)
  2. Mikez 09:53, 4 Jun 2004 (UTC) Probably better then light yellow together with the surrounding colours of MonoBook. (Changed my vote) --\Mikez
  3. Timwi 13:32, 4 Jun 2004 (UTC)
  4. KRS 13:39, 4 Jun 2004 (UTC)

Color everything that is not an article light gray

Comment only: if light gray is chosen, the color for the autogenerated edit summaries on RC will have to be changed (it's a light gray currently, and thus won't be readable anymore.) Lupo 10:03, 4 Jun 2004 (UTC)
  1. KRS 13:39, 4 Jun 2004 (UTC)

Different pale background colors for each type of non-article page

  1. Jamesday 14:35, 4 Jun 2004 (UTC) (but pale yellow if not this)

Other

In 1.2 I never saw a difference in color between the namespaces. It may be my monitor settings. Maximus Rex 02:15, 4 Jun 2004 (UTC)
I eventually did, but didn't realize it had a meaning until somebody explained it to me. -- Gabriel Wicke 12:25, 4 Jun 2004 (UTC)

Category page color

Should be the same color as other non-article pages

Should be the same color as article pages

  1. TreyHarris 02:00, 4 Jun 2004 (UTC) Categories are part of the content, not an ancillary. I'd also be okay with a third color.

Yet a third color (suggest one if you like; not part of poll)

The fact that MediaWiki:Monobook.css only does a difference for logged in users

Try it yourself. Log in, and links are underlined, log out, and they are not. This is useless, I think we should give up changing the default skin if we are not changing it for everybody, it's just silly to log in and discover 20 small tweaks that make the overall UI much better. ✏ Sverdrup 07:54, 4 Jun 2004 (UTC)

Hey, I didn't know that! If that's what it takes to get rid of the underlines, I will not log in on en: ! Mikez 09:53, 4 Jun 2004 (UTC)
Rather, there is another option for me, I'll keep the standard skin from now on. \Mikez

Reduce the white space in tables and the side bar

Monobook's line heights are just too big in tables and in the side bar. Reducing them to 1em or 1.2em gives a much better layout. Lupo 09:08, 4 Jun 2004 (UTC)

Black and tan Miniature smooth-haired dachshund
They look OK to me. But there is a spacing problem in thumbnail captions; here's an example. Huge space between 1st and 2nd line but there is no break in the actual text, it's wrapping.
Also--how did we end up with those rectangle thingies as magnifying icons? I thought that the vote a month or so back preferred the magnifying glass? Elf | Talk 17:54, 4 Jun 2004 (UTC)
Amen, I didn't even work out what the rectangle thingies DID for a week or so! Magnifying glass much more intuitive for new users

Rissa 18:04, 4 Jun 2004 (UTC)

Interlanguage links back at the top

I find having the interlanguage links at the bottom of the sidebar a nuisance. Part of Wikipedia's strengths is the fact that many articles exist in several languages, and we should emphasize on that, not hide it! (I usually have to scroll—and I have a big screen!— to see them.) It would be relatively easy to have them back at the top of the article, either above the top "tabs" or just below them, but above the first header. Lupo 09:08, 4 Jun 2004 (UTC)

Also: how many different language wikis do we have? 100? 150? We need a system for langlinks that scales well. I don't think the current sidebar solution works well at all with more than 10 langlinks ✏ Sverdrup 10:06, 4 Jun 2004 (UTC)
At the bottom, below any categories or other article content and metadata, would be good. The left column spot is too prominent. Jamesday 14:35, 4 Jun 2004 (UTC)

No printable pages

It appears to me that the option of printable pages has disappeared. They also appeared to be the most saveable pages (if I wanted to save the article). Not popular enough? - Nilmerg 11:59, 4 Jun 2004 (UTC)

WHen printing it switches to print automatically. What do you think of the option of offering "simple layout" and "high contrast/accessible" versions? Jamesday 14:35, 4 Jun 2004 (UTC)

Better now

Now that the blue is darker, it is much better. However, the contrast between unvisited and visited links is almost nonexistent, the violet has to be made darker or a different hue altogether can be tried.

By the way, what's with the underlines for links suddenly appearing and as suddenly disappearing? KRS 13:20, 4 Jun 2004 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Monobook.css&oldid=3936659"