MediaWiki talk:Common.css/Archive 6

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 4

→

Centralizing discussion

Should MediaWiki talk:Handheld.css and MediaWiki talk:Print.css redirect here? Seems kinda silly to have separate pages personally. --MZMcBride (talk) 05:18, 19 September 2008 (UTC)

Yes. --- RockMFR 05:21, 19 September 2008 (UTC)

Yes, I agree. Centralising the discussion is usually a good thing.

--David Göthberg (talk) 14:06, 19 September 2008 (UTC)

Yes; that would benefit both those involved regularly, and occasional visitors. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:12, 19 September 2008 (UTC)

All right. Moved the content to this page, redirected the pages, and noted the redirects at the top of this page. --MZMcBride (talk) 15:30, 19 September 2008 (UTC)

Jumping edit window

Resolved.

I want to pre-set the proper height of the edit toolbar.

We who have slower computers or slower Internet connections have a problem that the edit window "jumps" down when the edit toolbar buttons are loaded. (The buttons are loaded by JavaScript, so they load after the rest of the page has rendered.) This is not only ugly and confusing, this also causes errors. Since if we click the first line of text in the edit window, that click will not be processed until the page has finished rendering and the toolbar has been added. And that means that click instead lands on the toolbar, thus inserting some item in the edit window! And sometimes we don't even notice that and such unintended additions get published. (For instance, I once by accident added my signature to a widely used template in that way. Very embarrassing. Everyone wondered why my signature was visible on all those pages.) It also causes a similar problem when we click lines further down in the edit window. If I click say text-line 10 during page load, then when the page has finished rendering the cursor will land on line 9 instead! Very confusing.

I have now found a simple solution to this. We can pre-set the proper 22px height for the toolbar div in MediaWiki:Common.css. Like this:

/* Pre-set height for the edit toolbar so the edit window
   doesn't "jump" down when the toolbar images are loaded. */
#toolbar { 
    height: 22px;
    margin-bottom: 6px; 
}

The "margin-bottom: 6px;" is old code we already have in MediaWiki:Common.css, and I think we should keep that margin. I have tested this in all skins and it works for all of them. For users who have JavaScript disabled this will add 22px of space, but I tested and I think that looks okay.

--David Göthberg (talk) 14:37, 19 September 2008 (UTC)

This has driven me crazy for a very long time. If there's a fix for this, please implement it. (And perhaps we should consider implementing it by default in MediaWiki....) --MZMcBride (talk) 16:43, 19 September 2008 (UTC)

I support the change, I've been using this CSS personally for a long time. P.S. I only wish you'd move all the lengthy comments to a separate page. —AlexSm 17:38, 19 September 2008 (UTC)

Done - Thanks guys for supporting this fix.

MZMcBride: Yeah, this should probably be added to the default in MediaWiki. We web masters learnt already in the 1990's that image tags should have their size set so the page doesn't jump when the images load. (Only that in this case the image tags aren't there until the javascript inserts them.)

AlexSm: You evil evil man! You knew how to fix it and you didn't tell us? And I hope you like the shorter comment I wrote there? /* Edit window toolbar */

--David Göthberg (talk) 03:44, 20 September 2008 (UTC)

For what it's worth, the space doesn't appear at all if you have the toolbar disabled in your preferences, and users with disabled javascript who get tired of seeing the empty space can also hide it in their monobook.css. —Dino guy 1000 16:52, 25 September 2008 (UTC)

Dinoguy1000: Oh, thanks for pointing that out. And I double checked, you are of course right. Now how do I sign this message without my toolbar? Argh! :))

--David Göthberg (talk) 23:26, 25 September 2008 (UTC)

Clear:both for category listings

Resolved.

Pretty often I find categories where some right-floating box overlaps the category listing, and that looks really bad. The most common case is when one of the "Wikimedia Commons" boxes are used. See for instance this example. (And that is one of the less ugly examples.)

My usual fix is to apply the {{clear}} template. However most users don't know they can fix it like that and I just realised we can automate this with some CSS. So I would like to add this code to MediaWiki:Common.css:

/* Prevent boxes from overlapping the category listings. */
#mw-subcategories, #mw-pages, #mw-category-media {
    clear: both;
}

I have of course tested it in my own user space.

--David Göthberg (talk) 11:44, 24 September 2008 (UTC)

here is an even uglier example. Support anything that would stop this happening :D (also)Happy‑melon 12:31, 24 September 2008 (UTC)

Done - Since no one has complained and I think this is uncontroversial I went ahead and did the update. So anyone that takes a look at the examples we link to above might not see the problem anymore. (But if you are "lucky" you might still have the old MediaWiki:Common.css version cached in your browser and see how ugly it was.)

Happy-melon: Wow! That was a really nasty example. :))

--David Göthberg (talk) 23:46, 25 September 2008 (UTC)

MediaWiki:Print.css

Now that Brion has enabled MediaWiki:Print.css, someone who knows what they're doing should move the handful of print rules here to that page. (also)Happy‑melon 21:24, 4 September 2008 (UTC)

Have to wait till rev:40414 (current is 40356). —AlexSm 21:54, 4 September 2008 (UTC)

As far as I can see we are still at revision 40356, but I tested and MediaWiki:Print.css now seems to be fully working and loading in all skins. (Well I just tested in some skins.)

Here is the current output of the magic word {{CURRENTVERSION}}: 1.43.0-wmf.4 (2111e6d)

Note: The version you see above will be whatever is the current version when you read this.

--David Göthberg (talk) 09:44, 7 September 2008 (UTC)

I think this is what we need to move to Print.css (from Common.css and Monobook.css):

#content cite a.external.text:after {
    display: none;
}

.navbox {
    display: none;
}

.infobox.sisterproject {
    display: none;
}

.ns-0 .ambox {
    display: none;
}

#privacy, #about, #disclaimer {
    display: none;
}

.editlink, .noprint, .metadata, .dablink {
    display: none
}

Some of these could be removed if all the skins used commonPrint.css (some skins use wikiprintable.css, or their own print stylesheet, or no special print stylesheet). --- RockMFR 16:43, 7 September 2008 (UTC)

I would like to add ".ns-0" to pretty much all of those declarations. That would make it so they only are hidden for article printing, while when printing any other type of page such items would be visible. Since I think that if for instance a navbox is demonstrated/shown on a talk page or "Wikipedia:" page and you print that, then you want to see those things. And if you print the documentation of a template then you really want to see the template examples.

(I haven't yet double checked your code above, but it seems about right.)

--David Göthberg (talk) 00:01, 8 September 2008 (UTC)

See Bugzilla:15613... it would be nice if the contents of some kinds of boxes were printable even if the box decorations themselves were not. There are some cases where it's desireable to do so. See the experimental Ponte Vecchio for an example of that. The "Quick Reference" material should be printed if the article itself is (or, better, it would be nifty to be an option at print time! but that's a bit much) ++Lar: t/c 13:18, 16 September 2008 (UTC)

First of all, "Lejonel" was right over at Bugzilla:15613 that this is/should be handled by the CSS files here at Wikipedia. So he/she did right in closing that bug report as "resolved, invalid". And Lar: I assume you are the one that filed that bugzilla report? In that case thanks for pointing out the "printable version" view. Since that has specific issues (see below).

But now on to business:

The reason the "Quick Reference" box in the Ponte Vecchio article currently doesn't print is that it uses the "navbox" class. And navboxes are currently set to not print. (And I think it should stay that way.) So you need to remove that class and set the borders and colours in some other way.

Yes, we can fix the functionality you want. I assume you want that when the box prints it should be expanded, with text content, with black or grey borders, but without the background colours. Right? That we can do. (Unless the collapsible function messes with it, I haven't checked the details yet.)

And I did take a look, it seems the MediaWiki:Print.css is loaded as a regular CSS file (not with 'media="print"' set) in the "printable version" display. (You get to that version by clicking "Printable version" in the toolbox menu to the left. What that function mostly does is to remove the menus and only keep the page content.) But since it also makes the MediaWiki:Print.css a "regular" CSS file then we can make things display the same way on the "printable version" as when they actually print!

But don't rush away fixing anything. This was just my quick answer. This is tricky stuff and we need to investigate this properly before we change a lot of stuff. (I for one have it on my to-do list to investigate and clean up the printing stuff. Just so many other things to do that are more urgent.)

--David Göthberg (talk) 17:35, 16 September 2008 (UTC)

Actually I was encouraged by Lar to file the bug. Thanks for your response David, I'm encouraged a resolution is possible - and possibly simple(ish). Kind regards --Joopercoopers (talk) 22:44, 16 September 2008 (UTC)

I don't hack around with .css much so forgive me if these are clueless questions but what are the next steps here, David? Does someone need to make up a test print.css to try some of this stuff out? Create another div style for "fast facts" kind of things and add that to print.css? My thinking is that the box and decorations don't need to print (well maybe a outline around the facts might be nice) just the collapsed stuff. Thanks for any advice here. Also does a personal print.css have to have everything in it, or just the things you're adding or overriding (that is, does the MW one form a base?) ++Lar: t/c 02:27, 19 September 2008 (UTC)

Lar: Short answer: You can just sit back and wait and we'll fix most of this for you.

Long answer: I don't think any one of us who do work with these CSS files currently have a good grasp of the print handling, so currently I can not give you a good answer what code changes are needed. And now we have this brand new MediaWiki:Print.css where we will move most or probably all of the print styles. So we will investigate and test things and clean up this stuff. And write some documentation about it in Wikipedia:Catalogue of CSS classes. As I said it is on my to-do list, and I think some of the others here have it on their to-do lists.

--David Göthberg (talk) 04:22, 20 September 2008 (UTC)

Good deal. I think the notion of introducing a new style/class for "fast facts"/"Quick Reference" (or whatever one wants to call it) is related but separate, right? ++Lar: t/c 17:56, 21 September 2008 (UTC)

The MediaWiki:Print.css is now working

This comment was moved here from the talk page of MediaWiki:Print.css since that talk page has been redirected here.

The MediaWiki:Print.css now seems to be fully working and loading in all skins. (Well I just tested in some skins.) At the moment it is empty except for the "attention admins" explanation at its top.

--David Göthberg (talk) 09:33, 7 September 2008 (UTC)

I've added the code above to Print.css, and removed the corresponding items from Common.css, on the assumption that caching is not an issue - when the cache expires, people should be presented with new copies of both Common.css and Print.css. If that's not the case, do shout and we'll have to leave the code in common.css for the usual time. Happy‑melon 17:49, 26 September 2008 (UTC)

I did some thinking, and I think they unfortunately do not time out at the same time. Since MediaWiki:Print.css were added to the rendered pages around 4 September. For instance say a user surfed in that day and thus loaded the Print.css for the first time. So his Print.css will time out on 5 October. However the user might have visited Wikipedia before and his Common.css and Monobook.css might time out and be reloaded today. Thus he will be without any print styles until 5 October.

--David Göthberg (talk) 08:50, 27 September 2008 (UTC)

Creating editnotice

It might be a good idea to move two big comments

/*ATTENTION ADMINISTRATORS:
...
/* VALIDATOR NOTICE:
...

from MediaWiki:Common.css to MediaWiki:Editnotice-8-Common.css, utilizing new WP:Editnotice system. After that same editnotice can be also transcluded into this discussion page. —AlexSm 18:22, 29 September 2008 (UTC)

P.S. This discussion page is getting bigger than tech village pump, where's the (supposedly set up) archiving bot? —AlexSm 18:22, 29 September 2008 (UTC)

Excellent idea - now done. I'll do the same for the other stylesheets I think. It's nice to have those links finally work! Happy‑melon 18:59, 29 September 2008 (UTC)

I would mention that as another advantage, but I think they did work in preview. —AlexSm 20:22, 29 September 2008 (UTC)

Woo-hoo. :-) --MZMcBride (talk) 02:43, 30 September 2008 (UTC)

Navbox padding and line spacing

{{editprotected}}

Hi. Please replace the .navbox-group section with the following, where the last three lines are additions:

.navbox-group {           /* group style */
  white-space:nowrap;
  text-align:right;
  font-weight:bold;
  padding-left:1em;
  padding-right:1em;
  padding-top:0.35em;
  padding-bottom:0.35em;
  line-height:1.1em;
}

Similarly, please replace the .navbox-list section with the following, where the last three lines are additions:

.navbox-list {
  border-color:#fdfdfd;   /* Must match background color */
  padding-top:0.25em;
  padding-bottom:0.25em;
  line-height:1.4em;
}

The above is meant to be the equivalent of adding

|groupstyle = padding:0.35em 1.0em; line-height:1.1em;
|liststyle  = padding:0.25em 0; line-height:1.4em;

to a Navbox's transclusion.

The consensus for this? By virtual WP:SILENCE in response to my adding the immediate above to hundreds of Navbox templates. By "virtual" I mean that I cannot recall any objection made after a Navbox-based template was amended as immediately above, certainly not within a week or two of the edit and usually longer (months).

The rationale? When I've added the above, I've included two explanatory comments thus:

|groupstyle = padding:0.35em 1.0em; line-height:1.1em; <!--reduces wide gap between wrapped groupname lines-->
|liststyle  = padding:0.25em 0; line-height:1.4em; <!--otherwise lists can appear to form continuous whole-->

The line-heights address the spacing problems while the paddings ensure that groupnames/lists don't brush too close to each other as a consequence of the amended line-heights. Here's a demonstration:

Hopefully the improvement in the linewrapping of the groupnames and the visibility of each list as a distinct block is apparent. Sardanaphalus (talk) 14:14, 17 September 2008 (UTC)

I'm sorry, but those changes are going to clash in a very nasty way with nested navboxes or subgoups. On it's own it may seem a good solution, but ohter templates rely on padding being zero. Hence, adding this code may break a lot of navboxes. — Edokter • Talk • 17:44, 17 September 2008 (UTC)

(edit conflict)

Not done - Sorry. As has already been explained to you over at Template talk:Navbox#Suggesting amendments to default group/liststyle by Edokter and CapitalR that would break navbox subgroups. Besides, some/most of us think your line spacing is too narrow. Your example above doesn't have links. When the text above are underlined links it becomes very narrow. Can it be that you have set your preferences to not underline links?

I am not sure, but Sardanaphalus aren't you the one who have brought this up every now and then and each time we have explained to you that it will break things? (I don't want to search through 12 months of logs to find the different times when someone has suggested these things...)

For everyone else: CapitalR is our resident navbox expert, he is the guy who cleaned up the old system with navboxes and made the current version of the navboxes.

--David Göthberg (talk) 17:59, 17 September 2008 (UTC)

I switched my preferences to underlined links, took a look at a variety of Navboxes using the less gappy line-spacings -- and there's no problem. Besides, if there was a problem with the tighter line-spacing, I imagine I'd've heard about it one way or another by now, given the hundreds of Navbox-based templates I must've amended. Don't you notice how the current default Navbox line-spacing is not in the same kind of proportion as that between lines of text in articles?
As regards avoiding problems with subgroups, I guess I need to amend the styling within the {{Navbox}} source and then post an {{editprotected}} there..? Then I can work on integrating subgroups with the amended line-spacings to make it possible to amend the defaults here. I'm sorry if all this is déjà vu, but I'm trying to find some way to formalize these amendments; there's a user who persistently removes the styling from templates on the grounds of it not being standard rather than dysfunctional. Removing it, though, is chicken or the egg, as the amended styling needs to be seen by people if a consensus is to be built (by WP:SILENCE if nothing else). I infer consensus for the amended styling as there are now hundreds of templates carrying it (via group/liststyle parameters) and I've received no negative reports about its effect. Surely you don't think the effect of the wide spacing between wrapped groupname lines and continuous-look of the lists -- i.e. the "Before" navbox above -- is to be preferred to the "After" navbox formatting or something in its spirit?
I think CapitalR has been and is on a wikibreak. Understandable. He understands (or at least doesn't mind) the rationale.

Sardanaphalus (talk) 22:40, 17 September 2008 (UTC)

Per WP:SILENCE (which, mind you, is only an essay) I have to say I disagree with adding the styles to individual navboxes. You are basically trying to implement a style change that goes virtually undetected because the changes are easy to miss. It blocks potential future expansions of such templates... What if another (beginning) template editor adds a subgroup, finds that it is not padding properly and becomes frustrated at his failed attempt, all becuase he does not see, or understand the extra styling that you put in? I'm asking you to please stop and revert your style changes you have made so far; I feel that the editability of templates is severely hampered this way. The current style and padding is carefully chosen to allow the widest range of implementations, but your changes only represents your personal preference. — Edokter • Talk • 00:30, 18 September 2008 (UTC)

I can add a "padding:0;" to the default subgroup liststyle; see below. If the current styles have been carefully chosen, it looks like the readability of wrapped lines has been overlooked or sacrificed, needlessly.

Sardanaphalus: I like you, we have worked well together many times before. So I feel sorry that I now have to be a bit rough on you. There are some things you don't seem to understand:

1: I find it likely that the reason that people don't revert your edits to those templates are that most editors don't know what that code means and thus don't dare to change something they don't understand.

2: You can't just throw around {{editprotected}} requests and ask that people solve the technical problems for you. We have told you that your code will break things. So you need to code up the entire system with navboxes with subgroups and navboxes in navboxes and test it carefully. The usual place to do that is in your user space. That is, you need to copy the code of the involved navbox meta-templates into some test pages in your user space and apply the changes and run the tests there. (And apply and test the changes in CSS styles to your own monobook.css, but I think you already know that part.) Then when you have a working technical solution then you can announce the solution at the proper talk pages and ask people to come and take a look and test it. (Sure, sometimes if you present an idea others like it and do the coding and testing for you. But this doesn't seem to be such a case.)

3: Personally I do prefer the wider line spacing for link lists. Such lists are not article text. Instead they are fairly dense, hard to read, link lists. So they need that line spacing to be readable. Not all Wikipedians are 18 years old and have 20/20 vision. If you want to change the navbox style that now have been widely used for quite some time then you need to bring it up for discussion at the proper talk pages and achieve a consensus for the change. It sure would help if you then have working code to show for it. Because if people can just say "it will break this and that" then normally you can never achieve a consensus for it.

--David Göthberg (talk) 00:59, 18 September 2008 (UTC)

But they also daren't send me a message to say they don't like the amended formatting?
I don't think I am throwing around editprotected requests and asking people solve technical problems for me. I requested specific changes above for which I supplied code. I can see that, given the current setup, subgroups and perhaps other features are likely to be adversely affected. So I made the suggestion in 2. above. Is it worth pursuing?
Okay, if the default list line-height is to be wider than something like 1.4em, let's also amend lists' default top/bottom padding to create the blocks effect in "After" above rather than the continuous look in "Before", no?
As mentioned in response to Edokter above, I could set "padding:0;" as the initial default subgroups liststyle.
In light of 2. in my previous post, I guess this discussion should move back to Template talk:Navbox, no?

Sardanaphalus (talk) 09:35, 18 September 2008 (UTC)

I've been reminded that I have a monobook.css page of my own, so have begun experimenting with {{Navbox}} customization there. I'm sorry that my original request was so inappropriate; I was just trying another way to address the situation. Sardanaphalus (talk) 19:53, 7 October 2008 (UTC)

Autoarchiving this page

Some days ago Happy-melon did set up autoarchiving for this page. He set it to 21 days. I changed it to 40 days and added minimum 7 threads left. (40 days so comments remain through the 31 days CSS caching and then some days.) Then Happy-melon changed it back to 21 days but left the minimum 7 threads setting.

I have noticed that the bot has not yet come here to archive anything, so I checked. Apparently the bot doesn't automatically come to MediaWiki talk pages. Instead we have to ask the bot owner to set it up. But the bot page states: "NOTE: Before requesting automatic archiving on an article's talk page or a Wikipedia forum, please establish a consensus that archiving is really needed there." So I thought we could just as well get a proper consensus here before we ask the bot owner to set it up.

Even thought I am pretty sure what you guys will answer, here goes: So, do you want autoarchiving, and for how many days?

--David Göthberg (talk) 04:03, 1 October 2008 (UTC)

Auto-archiving sounds fine. But I recall one of the bots was set up where there were already archives and it tried to Archive_1, creating a mess. (I think it was MediaWiki talk:Common.js/Archive 1.) So as long as the bot archives to the correct place, I think it's fine. I don't really have a preference with regard to how often to archive. --MZMcBride (talk) 04:59, 1 October 2008 (UTC)

I think we definitely need autoarchiving here, because threads tend to get left for huge periods of time otherwise and no one here is ever bored enough to clear them up. At first I liked your idea for 40 days, I changed it because it didn't seem to be doing anything. Now that you say it just needs setup I'd suggest we try it on 40 days and see what happens. If the page stays too long we can always go back to 21 days. Happy‑melon 08:21, 1 October 2008 (UTC)

I have asked Misza13 to tell his archiving bot to start archiving this page.

MZMcBride: Thanks for the heads-up. I asked if the bot will honour the {{User:MiszaBot/config}} settings or not.

Happy-melon: Right, the 40 days was mostly thought "for starters" and then we'll see. But as I stated above, due to the CSS caching there might be reason to keep sections for a little more than 31 days.

--David Göthberg (talk) 23:01, 1 October 2008 (UTC)

The bot today did its first archiving run on this page and it worked perfectly. And I left a thank you note on the bot owner's talk page.

--David Göthberg (talk) 21:36, 2 October 2008 (UTC)

Table of contents margin

Per a brief discussion at User talk:Ed Fitzgerald#Spacing?, how would people feel about this?:

#toc { margin-top: 10px; }

—Wknight94 (talk) 15:38, 15 July 2008 (UTC)

10px seems like quite a bit of room. We changed the margin-top of class="infobox" a while ago and I still see the repercussions of doing so today. TOC's CSS been the way it is for a long time, and I can't really see a reason to increase the spacing. From the articles I glanced at, there seems to be plenty of room.... --MZMcBride (talk) 22:17, 15 July 2008 (UTC)

I can see what Ed Fitzgerald is going for. See Ron Darling. His blank lines and comments seem to add more than 10px. Try adding the CSS line above to your personal monobook.css and you'll see it's not really that much. —Wknight94 (talk) 22:36, 15 July 2008 (UTC)

There's some sort of way to make something like this only work on NS:0 (the article namespace). If we're to implement this change, it should be only for articles. There are a variety of situations in which people have placed TOCs in tables or floated them and they align correctly with other elements. --MZMcBride (talk) 19:35, 19 July 2008 (UTC)

If we should do this then I think it should be the same top margin that the infobox uses. That is 0.5em. That also means that users that zoom (choose larger text size) will get a proper margin. And as MZMcBride pointed out we should make the selector picky so this doesn't interfere with any other usage cases. So here is my code suggestion:

.ns-0 #bodyContent > table#toc  {
    margin-top: .5em;
}

It only selects a TOC that is in the page text area, and in an article. If it is put inside a div or table or is put on any other page this code will not be used. (It will not even get the top margin in the edit preview window.:) This uses the child selector ">" so this code will not work for IE 5 and 6. But will work on IE 7 and most other browsers. So in IE 5 and 6 we get the old narrower top margin.

I took it for a spin, it looked pretty good in my Firefox at least. I think I like it.

If we want this, should it be put in Common.css or Monobook.css ?

--David Göthberg (talk) 13:06, 1 September 2008 (UTC)

I have now investigated this more. Most of the other skins already have the wider top margin on the table of content. Thus I would like to add this code to MediaWiki:Monobook.css, so it doesn't interfere with the other skins:

/* TOC margin in articles. */
.ns-0 #wikiPreview > table#toc,
.ns-0 #bodyContent > table#toc {
    margin-top: .5em;
}

Since I like full WYSIWYG I added the necessary selector to make it work in the edit preview too. This code works fine in my Firefox 2 and my Opera 9. As expected the code has no effect in my Internet Explorer 5.5, but also does no harm.

--David Göthberg (talk) 05:16, 20 September 2008 (UTC)

Looks fine. Though, I don't ever remember seeing #wikiPreview.... I assume that's something for &action=submit ? --MZMcBride (talk) 16:01, 20 September 2008 (UTC)

Yes, the div that surrounds the text in the preview above the edit window has the id="wikiPreview". Thus that is the id closest outside of the TOC table when in edit preview, so that is the id we have to use before the child selector ">" in that case. As we discussed above we want to make the selector as picky as possible so this doesn't interfere with any other usage cases, like when people put the TOC inside some table to handle its placement or similar.

While the div that surrounds the text in normal pages has the id="bodyContent".

Since you asked I checked all the CSS files. The only declaration that uses the "#wikipreview" is a declaration in "common/shared.css", the first CSS file loaded in all skins. That declaration sets a 1em margin between the preview area and the edit toolbar. I guess originally that div was simply put there by the devs out of good habbit. All "areas" in the rendered pages have a div with some id on them, thus we can do all kinds of neat things when we skin the pages. Many of those ids are still not used in our CSS files.

--David Göthberg (talk) 07:29, 21 September 2008 (UTC)

Done - I added the code above to MediaWiki:Monobook.css. And it looks good in the articles.

--David Göthberg (talk) 01:10, 26 September 2008 (UTC)

Thank you very much...

This section was moved here from the talk page of David (me). Ed Fitzgerald is the user who originally requested more margin. --David Göthberg (talk) 03:22, 1 October 2008 (UTC)

...for the note about the ToC margin change, I had no idea it was in the works. I very much appreciate it, and I will take steps now to remove the additional spacing I had added into some articles. Ed Fitzgerald ^{t / c} 01:48, 26 September 2008 (UTC)

Well, sometimes we work a bit slow. I hope people will like it and not protest, since not many people were involved in the decision so it is a weak consensus. (But none of the people involved were against it, and that is a good sign.) However I doubt people will even notice, since it is a rather small change. I hope you think the new margin is enough? Since I wouldn't want it larger, and I usually like to have more margins and space on pages than most... The others didn't have much of a point of view on how large to make the margin.

--David Göthberg (talk) 02:25, 26 September 2008 (UTC)

I'm not sure I've actually seen it, yet. Ed Fitzgerald ^{t / c} 04:19, 26 September 2008 (UTC)

Ok, I'm pretty sure I've seen it now, and I don't want to seem ungrateful, but, boy, I wouldn't mind a little more space -- it still seems a little bit constricting as it is. Do you think anyone would object to a bit more? If yes, so be it, but you did ask.... Ed Fitzgerald ^{t / c} 17:33, 30 September 2008 (UTC)

End of section moved here from the talk page of David (me). --David Göthberg (talk) 03:22, 1 October 2008 (UTC)

Right, 0.5em isn't that much margin. So since I have seen how much space you add in the articles I was expecting your reaction. Most of us here didn't seem to have that much of a point of view on how big a margin we should have.

One thing I am sure of is that we should measure the margin in "em", that is character size not pixels. Since that means that people who zoom (choose larger text size in their browser) will get a larger margin. Which will look right for them.

So just to choose something I suggested the same margin as the infoboxes currently use, thus when they are placed next to each other they line up nicely. I thought that would be a good start. (But note, they should not normally be placed next to each other like that.) And that 0.5em margin happened to look about right for my personal taste.

So, we now have the code for it in place and it seems to work well. The next step is to test and see what margin most people prefer. So Ed Fitzgerald: Since you are the one that want the change I suggest you code up some examples and show them over at the Village pump to get some opinions. And then I suggest we'll go with whatever is the best compromise based on what people think.

--David Göthberg (talk) 03:22, 1 October 2008 (UTC)

David: Thank you, but I wouldn't presume to even try coding anything, since it's well above my abilities! I know what looks right, but that doesn't translate into an ability to implement a change.

BTW, the spacing I introduced wasn't necessarily my preferred amount, merely what was avialble to me with the tools I had at hand. Ed Fitzgerald ^{t / c} 21:46, 1 October 2008 (UTC)

Ed Fitzgerald: Okay, I have put it on my to-do list to code up an example so you can see how to do it. I will put that example on your talk page and then you can add wording etc, and copy that to the Village pump.

--David Göthberg (talk) 22:33, 1 October 2008 (UTC)

My thanks again. I look forward to seeing how it's done. Ed Fitzgerald ^{t / c} 07:37, 12 October 2008 (UTC)

class texhtml should have the "white-space: nowrap" property

I've seen TeX formulas rendered to HTML wrap around in the most absurd places, including immediately before the closing | of an absolute value. -- Army 1987 (t — c) 11:03, 11 October 2008 (UTC)

Seems sensible. What rule are we looking at? Something like:

.texhtml {white-space:nowrap;}

?? Happy‑melon 13:07, 11 October 2008 (UTC)

Yes. There already is span.texhtml { font-family: serif; } in http://en.wikipedia.org/skins-1.5/common/shared.css, maybe it'd make more sense to add whitespace: nowrap; in the braces there. -- Army 1987 (t — c) 13:31, 11 October 2008 (UTC)

Done We can't edit that file (only the developers can change it), but I've added it here. Happy‑melon 16:14, 11 October 2008 (UTC)

dd vs notice vs dablink

<dd> (which is produced by ":"), the notice class, and the dablink class all are supposed to pretty much the same thing - indent the text. However, each of them is implemented in a completely different way. <dd> (defined at [1]) uses margin-left: 2em;; notice uses margin: 1em; padding: 0.2em;; dablink uses padding-left: 2em;. Shouldn't these all be made consistent? --- RockMFR 16:34, 18 September 2008 (UTC)

RockMFR: What is a "notice" that you talk about? I see there is a "notice" class in MediaWiki:Common.css, is that what you are thinking of? But when and for what is it used?

And disambiguation links used to be done by using a ":" and then italics text. Now there are a whole bunch of templates for doing the disambiguation links and they seem to look the same. Do they use the dablink class in MediaWiki:Common.css?

So what do you mean? You should probably clarify with some examples here or you will probably not get much comments.

--David Göthberg (talk) 14:11, 29 September 2008 (UTC)

Margins of definitions, ordered lists, and unordered lists

Definition term 1: Definition 1
Definition term 2: Definition 2
Definition term 3: Definition 3

Ordered list item 1
Ordered list item 2
Ordered list item 3

Unordered list item 1
Unordered list item 2
Unordered list item 3

As you can see above, the margins of definitions, ordered list items, and unordered list items are different for some reason. I suggest the following...

dd,ol,ul{margin-left:2em;padding:0;}

It should give us the following...

Definition term 1: Definition 1
Definition term 2: Definition 2
Definition term 3: Definition 3

Ordered list item 1
Ordered list item 2
Ordered list item 3
Ordered list item 4
Ordered list item 5
Ordered list item 6
Ordered list item 7
Ordered list item 8
Ordered list item 9
Ordered list item 10

Unordered list item 1
Unordered list item 2
Unordered list item 3

Good? Bad? Ugly? LA (T) @ 20:03, 18 September 2008 (UTC)

I say good. — Edokter • Talk • 21:06, 18 September 2008 (UTC)

Almost good. I like your suggested lower 2em left margin for the ordered lists. (Same as the definition lists already have.) I always thought the ordered lists were too indented so I have often avoided using them. But don't add 2em left margin to the unordered lists, since I would like that the dot images for the ul's should align with the numbers for the ol's. (Instead of the start of text aligning.) The current 1.5em left margin for the ul's does that well for my IE 5.5 and my Firefox 2. My Opera 9 needs a little more margin for the ul's so you could raise it to 1.6em as a compromise (I have tested it), but I would prefer to keep the lower 1.5 left margin anyway, since I don't like if the ul's indent too much. (Note that you can't have lower than 2em left margin for the ol's since when 10 or more items they need space for two numbers.)

--David Göthberg (talk) 14:03, 19 September 2008 (UTC)

David...If you look, you will see that the markers do line up. The periods after the numbers in the ordered list align with the center of the bullets in the unordered lists. The point is to line up the text. Any way that I could convince you that this is a really good thing? LA (T) @ 20:04, 19 September 2008 (UTC)

Nope, you can't convince me. First of all ordered lists and unordered lists usually are not shown that close to each other. So it is more important to me that the unordered list doesn't get too indented since that will look bad next to the normal unindented text. Secondly, most ordered lists have less than 10 items thus just having one digit, and then I think it looks best if the unordered dots line up with the centre of the digits. When there are two digits I probably would like the dots to line up with the midpoint between the two dots! And I definitely don't like to line up the bullets with the tiny dots after the digits (as in your current example above), that just doesn't look balanced.

--David Göthberg (talk) 04:05, 20 September 2008 (UTC)

Looks good to me. I don't think the unordered list looks "too indented", and I doubt there's much point in debating the exact relative alignment of bullets and numbers: as David himself notes, ordered and unordered lists next to each other aren't very common, and, even when they do occur, I'd say having the text properly aligned is most important. —Ilmari Karonen (talk) 16:23, 27 September 2008 (UTC)

I'd use padding—that's what Firefox, Safari, Opera and IE8 use for lists. —Ms2ger (talk) 16:30, 27 September 2008 (UTC)

I agree that this looks good. It's about time we lined these up correctly. Happy‑melon 09:58, 28 September 2008 (UTC)

I should perhaps clarify: I do agree with the suggested 2em left margin for the ordered list. And it seems everyone here agrees on that. So I think that change can probably be applied immediately without hesitation. I only have a minor disliking of increasing the margin for the unordered list to 2em, while all the other editors here seems to like the 2em margin. So I am outnumbered on that. Thus I think that change should be applied too. So it seems you guys can go ahead with both changes. Unless of course you want to be careful and first announce this at the Village pump.

Ms2ger: I thought I understood the reason behind using padding instead of margin as you suggest. In theory it should be beneficial when there are left floating boxes before the lists. Currently for instance the left floating {{shortcut-l}} has a problem to coexist with lists. But I did some tests and using padding was even worse. Perhaps I misunderstand how to use padding for this? So Ms2ger: Could you code up an example of how it should be done if you know how to do it? I would love if you could solve the problem with left floating boxes + lists.

--David Göthberg (talk) 13:49, 29 September 2008 (UTC)

I didn't see any difference between margin and padding with floats—consistency with browser defaults in the only reason I have for using padding. —Ms2ger (talk) 16:23, 29 September 2008 (UTC)

Done I've implemented this. Happy‑melon 12:51, 19 October 2008 (UTC)

(unindent) Nobody tested with this with lists over 1,000 items? By hardcoding an ident the entries that are four digits or more are now running over the boundaries of the page. This code should either be reverted or made only to apply to the (Main) namespace. --MZMcBride (talk) 03:57, 20 October 2008 (UTC)

Example:

Foo
Bar

--MZMcBride (talk) 04:05, 20 October 2008 (UTC)

I've gone ahead and reverted this. It broke both computer browsers and handheld browsers. On handheld browsers, it not only broke with four-digit integers, but even two-digit integers had issues with hitting the edge of the page. Perhaps a combination of selectors for only the (Main) namespace on this stylesheet coupled with an explicit override in Handheld.css would be best, but I don't have the time or inclination to test. :-) Just please be careful before re-implementing this code. Broken layouts are no fun. ;-) --MZMcBride (talk) 21:15, 20 October 2008 (UTC)

Red tinting of edit box on fully protected pages

The addition

.mw-textarea-protected { background:#FFD8D8; }

would mean that administrators will not be able to accidentally miss full protection when it applies to a page. This is a repeating source of divisive disputes and "bad conduct" allegations related to page protection.

The relevant edit to common.css gained some support at WP:AN but was reverted with a request to discuss here. At the time, the discussion at AN was as follows:

== Editing protected pages ==

Protected pages - the text box area now shows up in light RED when edited.

This should help to avoid the occasional problem when an administrator edits such a page and for whatever reason, doesn't realize or notice it's been protected (despite the header). FT2 ^{(Talk | email)} 01:07, 22 October 2008 (UTC)

Having been the victim of having a page protected when you weren't looking, I think this is an excellent idea. ^{Shell babelfish} 01:10, 22 October 2008 (UTC)

It happened to me once to, I simply didn't notice it was protected. 68.10.122.209 (talk) 01:28, 22 October 2008 (UTC)

Hahahahahahahahahahahaha. No. ╟─Treasury§Tag►contribs─╢ 07:21, 22 October 2008 (UTC)

Doesn't work for me: I just tried editing the main page, and didn't see anything out of the ordinary. A couple of possibilities: I'm using Opera and I'm using the Classic skin. --Carnildo (talk) 07:08, 22 October 2008 (UTC)

Might be the skin - I've tested it in Opera (windows) and it seems to work there as well. Did this change only happen to the css for monobook? ^{Shell babelfish} 07:21, 22 October 2008 (UTC)

Did you bypass your local cache? The change was made to Common.css, so it should affect all skins, though that page is cached for 30 days unless bypassed explicitly. --MZMcBride (talk) 08:27, 22 October 2008 (UTC)

I just tried to edit the main page also -- a quick flash of red which I could have missed, then I was down the page in the Edit field. Maybe that's what happened to Carnildo? Doug Weller (talk) 08:40, 22 October 2008 (UTC)

This should be fixed so it works for pages which are transcluded in cascade-protected pages - the current signpost, for example.

It was then reverted with the request to discuss here prior to any reinstatement.

So... is there consensus for this change?

The effect would be as follows: a page that an administrator attempts to edit, that is fully protected, would have the edit box's background tinted light red (#FFD8D8). This would help administrators to realize that a page is protected if they miss the warning at the top (as can routinely and too easily happen), and would provide a visual hint that assists administrators to consider posts and edits to protected pages before posting. FT2 ^{(Talk | email)} 14:23, 22 October 2008 (UTC)

Support. Will reduce some unnecessary friction with no obvious downside.--Scott MacDonald (talk) 14:26, 22 October 2008 (UTC)
I like the red tint, it serves as a way to prohibit admins from saying they didn't know they were editing a protected page. MBisanz ^talk 14:27, 22 October 2008 (UTC)
Fine. Stifle (talk) 15:20, 22 October 2008 (UTC)
Excellent idea. — Lomn 15:21, 22 October 2008 (UTC)
No objection from me. Admins can always override this setting in their personal skin CSS pages. --MZMcBride (talk) 16:32, 22 October 2008 (UTC)
Very good idea; I'd appreciate the reminder. ^{Shell babelfish} 16:40, 22 October 2008 (UTC)
Do it. I was a bit surprised when I saw it the first time, but this'll be a definite help. Hersfold ^(t/a/c) 16:41, 22 October 2008 (UTC)
Definitely do it. I think DG overreacted reverting it. Relax! Happy‑melon 16:53, 22 October 2008 (UTC)
I can't see any reason not to support this change. I haven't made the mistake myself, but I've come close. The slight tint will help avoid any slip-ups. - auburnpilot talk 17:52, 22 October 2008 (UTC)
Support, an excellent idea. --TheDJ (talk • contribs) 18:18, 22 October 2008 (UTC)
Support, even though I'm not an administrator myself... I can definitely see how this would be useful. —Dino guy 1000 18:38, 22 October 2008 (UTC)
An excellent idea, with no real downside. EVula // talk // ☯ // 19:01, 22 October 2008 (UTC)
Excellent idea. Sam Korn ^(smoddy) 20:09, 22 October 2008 (UTC)
By all means. Like most good ideas, I'm struck by the fact that we don't do this all ready. Xymmax ^{So let it be written} _{So let it be done} 20:11, 22 October 2008 (UTC)
I'd prefer a color other than the sickly-looking pink currently suggested, but the idea's good. --Carnildo (talk) 20:52, 22 October 2008 (UTC)
- The color can easily be overridden in your monobook by picking a new color for .mw-textarea-protected. The pink is a perfectly fine color for now; if everyone hates it, I'm sure we'll hear about it once we implement it. ;) EVula // talk // ☯ // 21:26, 22 October 2008 (UTC)
As this will only affect admins it might as well be done as it will prevent excuses and accidents when edits are made to fully protected pages. Any administrator who dislikes it can edit their own monobook.css and override it with their own choice of colour, or make it white again, but it would be better for it to be applied universally with an option to opt-out, rather than to opt-in. It also solves a problem of edits being made to a fully protected template that were supposed to be made to a sandbox first (as they look identical in edit mode). ~ User:Ameliorate! ^{(with the !) (talk)} 21:20, 22 October 2008 (UTC)
Great idea. I've added it to my own monobook.css in any case. Yes, the pink is indeed rather, um... pink, but then it's meant to jump out at you. Full support. —Ilmari Karonen (talk) 22:25, 22 October 2008 (UTC)
Support the idea, as some admins have a hard time with this. I personally don't like it, so I've disabled it in my monobook.css, but I can see how it will be beneficial to others. - Rjd0060 (talk) 04:19, 23 October 2008 (UTC)

I've reinstated the code - it's clear that the support for this is overwhelming. Happy‑melon 22:53, 22 October 2008 (UTC)

I'm not seeing any light-red tinting. Ah. Bypassed my cache. It's working now. Someone at AN mentioned that caching can last for up to 30 days. If any admins accidentally edit a protected page and claim they didn't see the tinting, it is worth remembering that they may not have cleared their cache. Carcharoth (talk) 04:20, 23 October 2008 (UTC)

Strong oppose. Such pink background is much less readable. It literally hurts my eyes and causes me migraine. This new setting here at Wikipedia overrides the settings users have in their operating systems and/or in their web browsers for text areas. Some have for instance yellow/brown or green text on black background since that is what their eyes can handle. I have set my operating system to use light beige (#FFFBF0) background, since with the white background I can only edit about one hour a day. With the pink background I can not edit at all.
It should not matter if a page or template is protected or not, an admin should not do bad edits on non-protected pages either. And any editor should use a /sandbox instead of doing test edits to any deployed template, no matter if it is protected or not.
In-spite the very big warnings on MediaWiki:Common.css FT2 himself did several edits to it to test out what colour to use. He should instead have tested it in his own /monobook.css first, and then brought it up for discussion so others could have double checked it. That just goes to show that this is more a problem of educating the admins and the other editors, than adding more colour to just one type of pages.
Carcharoth: Wikipedia has the CSS pages set to 31 days of caching. Any edits or any mistakes done on these CSS pages will be visible for up to 31 days for those users who happens to (re)load the CSS pages during the time the CSS page has that content.
--David Göthberg (talk) 11:09, 23 October 2008 (UTC)

David, if you're using a custom monobook, you should be able to cancel this out easily anyway. If not, someone here can cancel it out for you in your monobook.css if you want. And how often do you edit protected pages anyway? I'd image for less than an hour a month, much less a day. The issue, by the way, is not "admins doing bad edits" on protected pages, as you say in your edit summary. The issue is that all admins have, at some time or another, edited a protected page to make good changes unintentionally because the protection is so very easy to miss - we're not challenged very much by the system to say "oi, adminy person, think on!". But now we will be, for the benefit of the 'pedia, admins and editors. ➨ ❝ЯEDVERS❞ a sweet and tender hooligan 11:23, 23 October 2008 (UTC)
I think Rjd0060 (talk · contribs) coded such a thing to cancel out the effect of this change, so that should solve a lot of objections. MBisanz ^talk 14:56, 23 October 2008 (UTC)
As I'm sure David knows, he can simply add .mw-textarea-protected { background:#FFF !important; } to his .css page to disable the coloring. Since he appears to be the only one in opposition to this change (at least of those who have commented here), I'd suggest he does that. And as much as I'd like to take the credit for writing the code, somebody else did it. - Rjd0060 (talk) 15:02, 23 October 2008 (UTC)

I have to say I agree: it's absolutely fine for you to not like it, DG, but what's so difficult about overriding it in your personal CSS? You know how to do that better than most. A minority of the tiny fraction of users who have the opportunity to experience this new styling might also experience the same concerns; but since admins are inevitably going to be more technically competent than the average editor, it should also be trivial for them to implement the same override. I do think you're missing the point over the actual purpose of this formatting: to use an example of mine, maybe if I'd had the red background I would have made these edits to the sandbox page where they were supposed to go! I'm open to discussion on the exact colour (I personally think that all 'uber serious' warnings should use the same background colour (#FEE) as the 'speedy' mbox classes), but the principle is extremely sound. Happy‑melon 15:39, 23 October 2008 (UTC)
Redvers: Actually, I spend several hours a day looking at (and doing some edits to) protected templates. That is my main work here at Wikipedia nowadays. That is why I became an admin, so I could continue to take care of the templates I had created since several of them had become high-use and thus protected.

Everyone: And of course I have already overridden the background colour for the edit window by adding .mw-textarea-protected { background: #FFFBF0; } to my personal /monobook.css. Otherwise I couldn't have done any of my job here today.

But this is not about me, instead what I worry about is the new/other admins. Many admins don't know anything about CSS coding and don't even know they can create a personal /monobook.css page. So they don't even know that they can get rid of that pink background, so they might not even bother to ask about it. Thus they will continue to suffer.

But I wasn't aware that some people have problems to keep track of in which window they edit. Ah well, we all have our quirks and specific type of mistakes we tend to do. So perhaps you guys really do need a different colour. (I don't mean that in a bad way. I have some special protections installed since there are some silly mistakes I tend to do.)

But please change to something much nicer, like some nice beige background or so, for the sake of the non-CSS-savvy admins. Or even better: A red border instead, thus not interfering with the reading of the page code itself. Try this one for instance:

/* Red border for the edit window for protected pages. */
.mw-textarea-protected { 
    background: #FFFFFF;
    border: 2px solid #b22222;
}

Like this.

That's the same nuance as the mbox "delete" red.

--David Göthberg (talk) 20:02, 23 October 2008 (UTC)

It just doesn't have the same impact, and belive me, impact is what's needed. How do you find the text in the 'speedy' mbox templates? Obviously you're not reading text like that all the time, but if it causes you problems wouldn't it cause problems there? I'm open to changing the colour: I've changed my mind and think that #FDD would make an acceptable compromise background colour for all our serious warnings, but I hope the background is there to stay. Happy‑melon 20:45, 23 October 2008 (UTC)

As a non-CSS-savvy admin who actually supports the change, I wonder if the ability to disable the new background could be incorporated into a gadget, that could simply be checked in preferences by those who are not happy with it. I don't even know if that's possible from a technical standpoint, but it could be a beneficial option if it is. - auburnpilot talk 20:50, 23 October 2008 (UTC)

That's not nearly as effective, and I don't think your rationale for keeping it out ("think of the newbie admins!") holds much water. Get a bot to spam all 859 admins with instructions to override the style. Voila, problem solved. EVula // talk // ☯ // 21:12, 23 October 2008 (UTC)

A sitenotice on watchlists would be better than spamming. I don't think there's a way to narrow this to just admin watchlists, but it hardly matters if non-admins see it or make the change. ➨ ❝ЯEDVERS❞ a sweet and tender hooligan 21:36, 23 October 2008 (UTC)

How about making the border thicker? Say, 25 pixels? There's no way you're going to miss something like that. --Carnildo (talk) 23:37, 23 October 2008 (UTC)

ROFL try it! Trust me, it looks utterly ridiculous :D Happy‑melon 07:53, 24 October 2008 (UTC)

Happy-melon: I hardly ever see the speedy mboxes. And I was one among many that disliked the speedy colour back when a vocal minority demanded it. (As far as I remember it was a minority, but we gave them the speedy colour to get them off our backs, and most of us didn't care enough anyway.) And we don't spend a long time staring at the text in the speedy boxes, not at all like editing page text or template code in an edit window. And besides, the background that FT2 did set for the protected pages' edit windows are much darker than the speedy mboxes.

And regarding impact: I think it has too much impact, which I think will do that many admins will simply override it back to the standard background. Thus it has zero impact on those admins, instead of sufficient impact.

EVula: Spamming the current admins with information about this doesn't help the future new admins that much.

But anyway, I don't think I have more to say about this. And I see I am clearly outnumbered on this.

--David Göthberg (talk) 21:49, 23 October 2008 (UTC)

I can add it to my "now you're an admin!" message for my promotions. :P EVula // talk // ☯ // 21:51, 23 October 2008 (UTC)

Strong oppose to this idea, but not for the same reasons as David. I believe that only truly global styles should be added to Common.css, and not the styles that are only useful to a small percent of visitors or editors. Admins already have MediaWiki:Protectedpagewarning, you could do whatever you want to make it more visible without affecting the site performance for other users. Admins already have MediaWiki:Sysop.js which could add the same CSS as above without affecting the site performance for other users. —AlexSm 04:04, 24 October 2008 (UTC)

This is an extremely good point. What I would suggest is that we configure MediaWiki:Sysop.js to import a stylesheet MediaWiki:Sysop.css, so we can move this style there. Happy‑melon 07:53, 24 October 2008 (UTC)

I have now done this, adding "importStylesheet("MediaWiki:Sysop.css");" to MediaWiki:Sysop.js and then moving the style rule to that .css page. I've redirected MediaWiki talk:Sysop.css to this page, so this discussion should continue here. I very slightly altered the colour, making it a tiny bit lighter (it's now the same as the background for the CSD templates). What does everyone think about making this the 'standard' serious background, and changing things like, eg, the "you are editing an old revision of this page" warning (MediaWiki:editingold) and other similar warnings (MediaWiki:Revision-info, MediaWiki:Cascadeprotectedwarning, etc). We should also take the opportunity to reformat all of these messages to use {{fmbox}}, so another style there would be useful; that discussion should go to Template talk:fmbox. Happy‑melon 13:08, 24 October 2008 (UTC)

Could we move body.page-Main_Page #ca-delete selector there? (I thought we disabled main page deletion). — Dispenser 15:04, 28 October 2008 (UTC)

It is disabled; the relevant code is available at http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php

As to your question, yes, that code can probably be moved. We also hide the move tab, no? Though it's important to remember that some admins (like myself) have Sysop.js disabled. --MZMcBride (talk) 16:04, 28 October 2008 (UTC)

Request for Rule

Hi, please could the following rule be added to this CSS file, for a temporary period during the Main Page redesign proposal. Many thanks, Pretzels^Talk! 23:11, 28 October 2008 (UTC)

#pretzelsmainpageproposal-head { background: white url('http://upload.wikimedia.org/wikipedia/en/c/c4/Faded_globe.PNG') no-repeat;}

Done, I see no problem with this. Remember that viewers will need to bypass their cache to see it. —Ilmari Karonen (talk) 23:30, 28 October 2008 (UTC)

For reference: This has previously been discussed on this talk page. See the now archived discussion: MediaWiki talk:Common.css/Archive 5#Request for background-image rule.

--David Göthberg (talk) 21:44, 29 October 2008 (UTC)

Huge thanks guys. I'll be sure to pop back to mention when it's safe to remove it. Pretzels^Talk! 01:58, 30 October 2008 (UTC)

Warning box with log excerpt

I am planning to add the code below to MediaWiki:Common.css, per an idea by Nihiltres and discussion at Template talk:Fmbox#New type, section break 1.

/* For recreating deleted page warning, reupload deleted file warning 
   and protected page warnings. Including their log entries. */
div.mw-warning-with-logexcerpt {
    border: 1px solid #BB7070;
    background: #FFDBDB;
    padding: 0.25em 0.9em;
}

That will make most of the warning notices that has a deletion log excerpt below them get a pink background and a thin red border, instead of a transparent background and a thick blue border. This will make them look like the other warning notices. This puts the deletion log excerpt within the pink box. Like this:

WARNING: This page has been protected so that only administrators can edit it. Please ensure that you are following the protection policy.

08:16, 27 September 2008 Davidgothberg (Talk | contribs | block) protected Template:Fmbox [edit=sysop] (indefinite) [move=sysop] (indefinite) (This box...) (hist) (Change)

For comparison, here is a plain editnotice that might appear under a warning notice.

I have of course tested the code in my user space.

--David Göthberg (talk) 05:14, 30 October 2008 (UTC)

Looks great to me. --MZMcBride (talk) 05:56, 30 October 2008 (UTC)

Done - I have added the CSS code above. And it looks very nice. See for instance this upload form for an image that was once deleted. Or try to create its description page, and you get the pink warning with a log excerpt.

--David Göthberg (talk) 06:48, 30 October 2008 (UTC)

Hmm... I'd rather see the log entries visually offset from the rest of the message, but that's just me, and if it bothers me enough, I'll eventually just hack something up in my monobook.css... —Dino guy 1000 07:57, 30 October 2008 (UTC)

Dinoguy1000: Yeah, I too prefer to have something that delimits the message text and the log entry. Over at Template talk:Fmbox#New type, section break 1 I show an example with a horizontal ruler (in the same colour as the border) between them. I'd like to hear what you and others think about that, so you are welcome to go there, take a look and comment. Since now three users have expressed that they want some kind of delimiting, and only one have objected, I added a horizontal ruler to the four messages involved: MediaWiki:Protectedpagewarning, MediaWiki:Semiprotectedpagewarning, MediaWiki:Recreate-deleted-warn and MediaWiki:Upload-wasdeleted.

--David Göthberg (talk) 14:45, 30 October 2008 (UTC)

I have now added the line "div.fmbox-warning," in MediaWiki:Common.css on top of the declaration shown in the example above. If anyone wonders about that see my explanation at Template talk:Fmbox#Div based warning messages.

--David Göthberg (talk) 01:46, 2 November 2008 (UTC)

This really needs to be changed so the pink background only applies to the log notice and not the editing box. See [2] for example. Spellcast (talk) 02:20, 2 November 2008 (UTC)

Spellcast: The awful pink background inside the edit box for protected pages is a separate issue. See discussion #Red tinting of edit box on fully protected pages above for that discussion. I was one of the users that strongly opposed that edit box background. Unfortunately the majority of users wanted it. But you should add your opinion up there, perhaps the opinions can be swayed.

—David Göthberg (talk) 03:03, 2 November 2008 (UTC)

Well, it's a shame readability has to be sacrificed. Any admin with common sense won't miss the eye catching pink log notice (which is fine). But as aesthetically unpleasing as the pink edit box is, I'm just glad you can change it with your monobook. Spellcast (talk) 03:34, 2 November 2008 (UTC)

Geo class documentation

Resolved.

This explanation is perhaps mostly for User:Quarl, since he is the one who added the geo classes and their documentation to MediaWiki:Common.css back in 4 April 2007. I'll ask him to come here and comment. Everyone else is of course also welcome to comment.

The geo classes currently have their documentation placed as a large comment inside MediaWiki:Common.css. I am planning to move that documentation to the /doc page of Template:Coord/link, since that is the place the comment currently points to for more information. (I'll leave the comment that points to that template.)

Any comments put in the CSS files are downloaded by every visitor to Wikipedia, since MediaWiki does not strip away the comments in the CSS files. This causes some unnecessary load for both the end user and our servers. Thus we normally instead document classes in other places. And it has the added advantages that we can use full wikimarkup such as bold text and wiki links in the documentation, and any user can help update and clarify the documentation since it then usually is placed in a non-protected page.

One option could be to move parts of the geo class explanation to Wikipedia:Catalogue of CSS classes. But I think the catalogue should only have short explanations, and when needed then point to more detailed explanations placed in a template /doc page or a "Wikipedia:" page that covers the subject. Thus moving the geo class documentation to Template:Coord/link seems to be the natural choice in this case, since that is the place that the comment currently points to for more information.

--David Göthberg (talk) 23:00, 3 November 2008 (UTC)

Move the entire explanation, and add a link to the CSS, to where the documentation will be located. Easy peasy. --TheDJ (talk • contribs) 23:15, 3 November 2008 (UTC)

Quarl added the classes at my request. I am happy for most of the text to be removed from the CSS as you suggest, but would ask that the line:

Note that the classes "geo", "longitude", and "latitude" are ~~not just styles but also~~ used by the Geo microformat, so the names should not be changed.

remain (although the text I have struck-through, above, could be deleted). Thank you.

I have use {{UF-coord-classes}} to copy the explanation to Wikipedia:WikiProject_Microformats/classes, which is already mentioned on Wikipedia:Catalogue of CSS classes. It would be better to and change the CSS comment's reference to point to that, in case those classes are also applied by other templates in future. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:32, 3 November 2008 (UTC)

Hehe, this is exactly why I often announce changes like this before I do them, since about 50% of the times people suggest some changes.

Andy Mabbett: Okay, I guess we can leave that sentence about it being a microformat, for now. Although I think that really belongs in the documentation, not in the CSS code. So you should instead put that explanation into the page we will link to from the CSS comment.

It is slightly ambiguous where you want me to link the explanation, I take it you want the comment to link to Wikipedia:WikiProject_Microformats/classes#Geo, right? (Thus not to Wikipedia:Catalogue of CSS classes, right?)

But as far as I understand it the template that uses those classes directly is Template:Coord/link. And linking in the way you suggest breaks the connection to that template. I can't find an easy way to find out where the classes are used by following the link Wikipedia:WikiProject_Microformats/classes#Geo. So we/you have to find a better way to link this. Either by placing a better explanation at Wikipedia:WikiProject_Microformats/classes#Geo or by keeping the link to Template:Coor link in the CSS code and instead link from that template to the other things.

Partly based on the input of Andy above, this is what I am now thinking of changing the code and comments to:

/* Geographical coordinates. 
   See [[Template:Coord/link]] for how these are used. 
   The classes "geo", "longitude", and "latitude" are used by 
   the [[Geo microformat]], so the names should not be changed. */
.geo-default { display: inline; }
.geo-nondefault { display: none; }
.geo-dms { display: inline; }
.geo-dec { display: inline; }
.geo-multi-punct { display: none; }
.longitude, .latitude {
    white-space: nowrap;
}

--David Göthberg (talk) 00:47, 4 November 2008 (UTC)

Wouldn't this be neater?

/* Geographical coordinates defaults. 
   See [[Template:Coord/link]] for how these are used. 
   The classes "geo", "longitude", and "latitude" are used by 
   the [[Geo microformat]], so the names should not be changed. */
.geo-default, .geo-dms, .geo-dec  { display: inline; }
.geo-nondefault, .geo-multi-punct { display: none; }
.longitude, .latitude             { white-space: nowrap;}

It's a little less clear, but much more code-efficient, and this page isn't going to be viewed by laymen anyway. Happy‑melon 12:18, 4 November 2008 (UTC)

Happy-melon: Yes, your code is more efficient. And depending on how one sees it it is slightly more clear, or slightly less clear, but not that much difference in clearness. So I now prefer your version.

--David Göthberg (talk) 19:46, 4 November 2008 (UTC)

On reflection, I'm happy with Happy-melon's text, too. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:49, 4 November 2008 (UTC)

Done - I have now compacted the geo classes code and comments in MediaWiki:Common.css. I used Happy-melon's version above. That took it from 1443 bytes to 379 bytes.

--David Göthberg (talk) 21:49, 4 November 2008 (UTC)

Plainlinks implementation

I think the politest response is "what the hell is going on here?"... we seem to have hacks laid upon hacks built upon other hacks; presumably some of these have been fixed and others are deprecated. Can we try and work out which bits, if any, of this glut:

/*Add formatting to make sure that "external references" from [[Template:Ref]] do
  not get URL expansion, not even when printed. The mechanism up to MediaWiki 1.4 was
  that the HTML code contained a SPAN following the anchor A; this SPAN had the class
  "urlexpansion", which was not displayed on screen, but was shown when the medium was
  "print". The rules below ensure (a) that there is no extra padding to the right of
  the anchor (displayed as "[<number>]"), (b) that there is no "external link arrow" for
  the link, and (c) that this SPAN of class "urlexpansion" is never shown.
  ~~~~
*/
.plainlinksneverexpand {
    background: none ! important;
    padding: 0 ! important;
}
.plainlinksneverexpand .urlexpansion {
    display: none ! important;
}
 
/* Make sure that ext links displayed within "plainlinksneverexpand" don't get
   the arrow...
*/
.plainlinksneverexpand a {
    background: none !important;
    padding: 0 !important;
}
 
/* With MediaWiki 1.5, the mechanism has changed: instead of a SPAN of class "urlexpansion"
   following the anchor A, the anchor itself now has class "external autonumber" and the
   expansion is inserted when printing (see the common printing style sheet at
   http://en.wikipedia.org/skins-1.5/common/commonPrint.css) using the ":after" pseudo-
   element of CSS. We have to switch this off for links due to Template:Ref!
*/
.plainlinksneverexpand a.external.text:after {
    display: none !important;
}
.plainlinksneverexpand a.external.autonumber:after {
    display: none !important;
}

is still needed? I honestly doubt any of it ist still required. Happy‑melon 12:18, 4 November 2008 (UTC)

It's definetly a good point. Lets see.

class "plainlinks" (monobook/main.css) : this is for links that should not get the external link symbol.
class "plainlinksneverexpand" (Common.css) : this is for plainlinks that should not be "written out" when you use CommonPrint.css
a.external.text:after and a.external.autonumber:after are the current methods used for this "writing out"

So the last two definitions are definitely needed at this time. However, plainlinksneverexpand are also used by the coordinates, and by the v.d.e in navboxes it seems (in print, you don't want a labal arrow, nor a written out link for these). The first .plainlinksneverexpand is double with the "plainlinks" definition in monobook/main.css. I'm guessing this is why the navbox/coord use this class, because plainlinks is skin specific.

So to clean this up neatly, we would require:

move plainlinks to shared.css
remove all definitions of plainlinksneverexpand except the last two.
convert any coordinates/navbox/etc that depend on plainlinksneverexpand to use class="plainlinks plainlinksneverexpand" instead.

--TheDJ (talk • contribs) 13:21, 4 November 2008 (UTC)

Sounds to me like 'plainlinksneverexpand' is just reinventing 'plainlinks noprint'. Any reason not to use the more intuitive class pairing? Happy‑melon 14:52, 4 November 2008 (UTC)

Because plainlinks is monobook specific, and you do want to print, you just don't want to print the URL (when you print a link you get: name-of-link (the actual url). In the coordinates case, you do want the name-of-link, but not the url appended to it. Not that it's something that cannot be fixed, it will however require some planning i think. --TheDJ (talk • contribs) 16:13, 4 November 2008 (UTC)

Sorry, of couse you're right; not printing the url expansion is different to not printing the whole link. As you say, some planning is required. Happy‑melon 17:05, 4 November 2008 (UTC)

I was under the impression that plainlinksneverexpand is just the older version of plainlinks... --MZMcBride (talk) 18:35, 4 November 2008 (UTC)

plainlinks is from May 2004 and plainlinksneverexpand is from May 2005 apparently. --Splarka (rant) 08:58, 5 November 2008 (UTC)

Am I right in believing that 'plainlinksneverexpand noprint' == 'plainlinks noprint'? I think we should be creating a 'noexpand' class so we can replace 'plainlinksneverexpand' by 'plainlinks noexpand' (and potentially set 'noexpand' to do other similar things in other places). Happy‑melon 17:47, 5 November 2008 (UTC)

Yes that's correct. noprint means don't print a thing. it does not matter what kind of other styling is applied in such a case. And yes, I agree with you on creating noexpand to replace plainslinksneverexpand. The classes should become.

plainlinks: this is a class, that cancels out any special "styling" of links. Currently only used for monobook external links, because it is the only skin that adds icons and stuff to links at this time.
noprint, this cancels the printing of any element during printing.
nourlexpansion (better name than noexpand in my opinion), this (should) cancel the namedlink expansion to: name (link), when printing.

We need to identify however the cases that currently only use plainlinksneverexpand, and that in the new case would require "plainlinks noexpand". That conversion will have to start by changing all those definitions to "plainlinksneverexpand plainlinks noexpand". The most important ones atm, seems to be {{Ref}} and {{Coord/link}}, but there are some more. and then a couple that probably cannot be found by the search index yet. --TheDJ (talk • contribs) 19:09, 5 November 2008 (UTC)

P.S. First usage of plainlinksneverexpand in {{ref}}. --TheDJ (talk • contribs) 19:16, 5 November 2008 (UTC)

Ah, I am happy that you guys are taking a look at this. Since some months ago I experimented with this for the mboxes, and partly failed. We use "plainlinks" in the mboxes since pretty much all their "external" links are just to other MediaWiki projects. When printing articles we simply hide the entire {{ambox}}. But on other pages we want to print the mboxes. (For instance the {{ombox}} based {{policy}} box.) But normally the message text is much more important than the links in those boxes. Thus I don't want the URLs to expand, since that makes the message much less readable. But when I tried to apply the "plainlinksneverexpand" class the mboxes became totally transparent, even loosing their borders.

So, if you can make the plainlinksneverexpand/noexpand/nourlexpansion/nourlexpand (whatever you prefer to call it) work with the mboxes too, then it would be a good thing. Although it is not especially important. But since the "plainlinksneverexpand" breaks the mboxes then it probably breaks many other things too.

--David Göthberg (talk) 21:17, 5 November 2008 (UTC)

That's because the rule ".plainlinksneverexpand { background: none ! important; padding: 0 ! important; }" doesn't make sense. I don't think it would ever be necessary to remove the padding and background from the container element. Unless someone proves me wrong, I suggest just removing that block of code.

I also think that, for the last two rules, "content:none;" or "content:"";" would make more sense than "display:none;"—there might be implementation issues, though. —Ms2ger (talk) 18:05, 6 November 2008 (UTC)

Proposal for plainlinks

I propose we make the following changes the above code to the much shorter version listed here below. At the same time, we change the ref and coord templates (keeping plainlinksneverexpand as an additional keyword due to potential 30 day caching).

/* Add formatting to make sure that "external references" from [[Template:Ref]] do
   not get URL expansion, not even when printed. The anchor itself now has
   class "external autonumber" and the url expansion is inserted when printing (see the common
   printing style sheet at http://en.wikipedia.org/skins-1.5/common/commonPrint.css) using the
   ":after" pseudo-element of CSS. We have to switch this off for links of Template:Ref!
*/
.nourlexpansion a.external.text:after,
.nourlexpansion a.external.autonumber:after {
    display: none !important;
}

{{Ref}} will use: <span class="reference plainlinks nourlexpansion plainlinksneverexpand">

{{coord/link}} will use: <span class="plainlinks nourlexpansion plainlinksneverexpand">

{{ambox}} and friends would use: <table class="metadata plainlinks nourlexpansion ambox

{{Tnavbar}} (2uses) would use: <span class="plainlinks noprint">

These should be the most important changes, and if someone could run something on the database to figure out where else plainlinksneverexpand is used, then we would know for sure. :D --TheDJ (talk • contribs) 19:23, 6 November 2008 (UTC)

Technically, for the moment the {{ambox}} has no use of the "nourlexpansion" class, since it has the "metadata" class which currently means the same thing as "noprint". But the other mboxes should have use of "nourlexpansion", since they do print. (Provided the "nourlexpansion" class doesn't mess them up.)

But I have been planning to change the metadata class (and all the other such noprinting classes) so it only stops printing on articles. Since when we show and discuss templates on for instance talk pages then we usually want to see everything if we print those pages. And then the ambox will have use of the "nourlexpansion" class. I just haven't had the time yet to investigate all this printing related CSS stuff properly.

By the way: Unfortunately we can not change the "noprint" class so it allows printing on non-article pages, since that one is also coded in common/commonPrint.css. So if/when we change the "metadata" class to only not print on article pages, then I think we should perhaps change the {{tnavbar}} to use <span class="metadata plainlinks nourlexpansion"> instead. Since I think the v-d-e links should be visible when we print template examples we are discussing on for instance talk pages.

And regarding finding cases that currently use "plainlinksneverexpand": For that we can simply use Special:Search. I did a search in template space only, and found 12 cases. I checked some of those cases and they used "noprint plainlinksneverexpand", which is kind of silly since "plainlinksneverexpand" has no effect when the item anyway doesn't print. But note that we have discovered the hard way that Special:Search often doesn't show 100% of the occurrences, since we have noticed it misses some cases we know exist. And it shows different hits to different users! (But the same user gets the same hits on each search.) But if several users do the searches then it seems we find pretty much 100% of the cases, so usually that is good enough. (My wild guess is that there are several search servers, each with an incomplete search database, and that users get load balanced onto those servers based on the user's IP number or so, so each user always gets the same search server.)

--David Göthberg (talk) 18:44, 8 November 2008 (UTC)

P.S. The rest of this is up to an editor with admin privileges. --TheDJ (talk • contribs) 21:24, 10 November 2008 (UTC)

v t e Before
group1's name	Lorem · ipsum · dolor · sit · amet, · consectetur · adipisicing · elit, · sed · do · eiusmod · tempor · incididunt · ut · labore · et · dolore · magna · aliqua. · Ut · enim · ad · minim · veniam, · quis · nostrud · exercitation · ullamco · laboris · nisi · ut · aliquip · ex · ea · commodo · consequat. · Duis · aute · irure · dolor · in · reprehenderit · in · voluptate · velit · esse · cillum · dolore · eu · fugiat · nulla · pariatur. · Excepteur · sint · occaecat · cupidatat · non · proident, · sunt · in · culpa · qui · officia · deserunt · mollit · anim · id · est · laborum.
group2's name	Curabitur · pretium · tincidunt · lacus. · Nulla · gravida · orci · a · odio. · Nullam · varius, · turpis · et · commodo · pharetra, · est · eros · bibendum · elit, · nec · luctus · magna · felis · sollicitudin · mauris. · Integer · in · mauris · eu · nibh · euismod · gravida. · Duis · ac · tellus · et · risus · vulputate · vehicula. · Donec · lobortis · risus · a · elit. · Etiam · tempor. · Ut · ullamcorper, · ligula · eu · tempor · congue, · eros · est · euismod · turpis, · id · tincidunt · sapien · risus · a · quam. · Maecenas · fermentum · consequat · mi. · Donec · fermentum.
group3's name	Pellentesque · malesuada · nulla · a · mi. · Duis · sapien · sem, · aliquet · nec, · commodo · eget, · consequat · quis, · neque. · Aliquam · faucibus, · elit · ut · dictum · aliquet, · felis · nisl · adipiscing · sapien, · sed · malesuada · diam · lacus · eget · erat. · Cras · mollis · scelerisque · nunc. · Nullam · arcu. · Aliquam · consequat. · Curabitur · augue · lorem, · dapibus · quis, · laoreet · et, · pretium · ac, · nisi. · Aenean · magna · nisl, · mollis · quis, · molestie · eu, · feugiat · in, · orci. · In · hac · habitasse · platea · dictumst.

v t e After
group1's name	Lorem · ipsum · dolor · sit · amet, · consectetur · adipisicing · elit, · sed · do · eiusmod · tempor · incididunt · ut · labore · et · dolore · magna · aliqua. · Ut · enim · ad · minim · veniam, · quis · nostrud · exercitation · ullamco · laboris · nisi · ut · aliquip · ex · ea · commodo · consequat. · Duis · aute · irure · dolor · in · reprehenderit · in · voluptate · velit · esse · cillum · dolore · eu · fugiat · nulla · pariatur. · Excepteur · sint · occaecat · cupidatat · non · proident, · sunt · in · culpa · qui · officia · deserunt · mollit · anim · id · est · laborum.
group2's name	Curabitur · pretium · tincidunt · lacus. · Nulla · gravida · orci · a · odio. · Nullam · varius, · turpis · et · commodo · pharetra, · est · eros · bibendum · elit, · nec · luctus · magna · felis · sollicitudin · mauris. · Integer · in · mauris · eu · nibh · euismod · gravida. · Duis · ac · tellus · et · risus · vulputate · vehicula. · Donec · lobortis · risus · a · elit. · Etiam · tempor. · Ut · ullamcorper, · ligula · eu · tempor · congue, · eros · est · euismod · turpis, · id · tincidunt · sapien · risus · a · quam. · Maecenas · fermentum · consequat · mi. · Donec · fermentum.
group3's name	Pellentesque · malesuada · nulla · a · mi. · Duis · sapien · sem, · aliquet · nec, · commodo · eget, · consequat · quis, · neque. · Aliquam · faucibus, · elit · ut · dictum · aliquet, · felis · nisl · adipiscing · sapien, · sed · malesuada · diam · lacus · eget · erat. · Cras · mollis · scelerisque · nunc. · Nullam · arcu. · Aliquam · consequat. · Curabitur · augue · lorem, · dapibus · quis, · laoreet · et, · pretium · ac, · nisi. · Aenean · magna · nisl, · mollis · quis, · molestie · eu, · feugiat · in, · orci. · In · hac · habitasse · platea · dictumst.