MediaWiki talk:Monobook.css/Archive 3

From Wikipedia, the free encyclopedia

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.

Contents 1 borders around thumbs 2 talk page boxes ala the french wiki 3 Consistent list alignment 3.1 Definition lists 4 NavFrame/NavHead format 5 Proposed addition to Monobook.css 6 Coordinates in article heading

borders around thumbs

On main.css, there are the following rules:

div.thumb {
    margin-bottom: 0.5em;
    border-style: solid; border-color: White;
    width: auto;
}
...
div.tright {
    clear: right;
    float: right;
    border-width: 0.5em 0 0.8em 1.4em;
}
div.tleft {
    float: left;
    margin-right:0.5em;
    border-width: 0.5em 1.4em 0.8em 0;
}

Looks to me that borders are being misused, the effect intended is that one of margins. Here, on Monobook.css, you have

#content div.thumb {
    border-color: #F8FCFF;
}
...
.ns-0 * #content div.thumb {
    border-color: white;
}

just to change the color of these borders, to match the page background (and this is more annoying because IE doesn't support transparent borders, and so, we can't use border-color: transparent. Was there a good reason borders where used instead of margins? --Miles 15:33, July 16, 2005 (UTC)

Miles, if you will notice I have added an example image and horizontal rule to illustrate the purpose of using a border instead of a margin. ...

---

... The margin will not prevent the horizontal rule from coming in contact with the image frame, but a border which matches the background does. —Mike 07:07, July 21, 2005 (UTC)

Thanks. Now it makes perfect sense. --Miles 03:18, July 30, 2005 (UTC)

It might make perfect sense in this case, but it is a hack, and wreaks havoc with colored background boxes (like are recommended for every portal). Here's what I mean:

So it's not a no-brainer, obvious hack to do. On one hand, we wreck portal use of thumbnails but on the other, rules don't look great.

I'd thought something like this would work:

hr {
   margin: 0 auto 0 auto;
}
div.tright {
   clear: right;
   float: right;
   margin-left:0.5em;
   border-width: 0 0 0 0;
}
div.tleft {
   float: left;
   margin-right:0.5em;
   border-width: 0 0 0 0;
}

But it doesn't work like it should. It's OK on IE, but bad on Mozilla Firefox. This should be fixable, right?

--FJM 09:59, 8 August 2006 (UTC)

The "rules" that cause the problems (the ones under headings) are actually lower borders, if you look at the CSS code, not rules at all. So fiddling with hr won't do much. —Simetrical (talk • contribs) 19:21, 8 August 2006 (UTC)

Ah, so Mike's h-rule example above isn't actually the whole reason for having these white-borders-as-margins.

<h2>Borders around Thumbs header test</h2> (See http://bugzilla.wikimedia.org/show_bug.cgi?id=6575 for the above weirdness)

I've added an example at the top of this section that shows the wanted behavior. --FJM 09:24, 9 August 2006 (UTC)

Can you not add "border-color: white; border-color: transparent;": won't MSIE stick with white because it doesn't understand transparent, but all other browsers override white with the second border-color declaration? This way it's only slightly broken in the broken browser—so sad, too bad. —Michael Z. 2006-08-08 15:20 Z

If you make the border transparent, you may as well go with margins. The point of using borders instead is to not have them be transparent, so that the pseudo-rules under level 1 and 2 headings don't run into them. —Simetrical (talk • contribs) 19:21, 8 August 2006 (UTC)

OK, it seems that Mike's description of the "border which matches the background" "prevent[s] the horizontal rule from coming in contact with the image frame" isn't a good way to describe what happens. Actually, the opaque border which matches the background actually paints over any elements that are below it. And a float element will only move text out of the way; it doesn't deal with "graphic" elements like h-rules or borders of text boxes (you can see the problem with the dotted "source" box under the section header — the float doesn't reduce the width of that border or of the h2 bottom-border.)

But I do have a solution for my problem. (And yes, it's a hack on a hack.)

--FJM 12:48, 9 August 2006 (UTC)

talk page boxes ala the french wiki

/* Style pour les pages de discussion ; gestion de la coloration indentative */
.ns-1 dd, .ns-3 dd, .ns-5 dd, .ns-7 dd, .ns-9 dd, 
.ns-11 dd, .ns-13 dd,.ns-15 dd, .ns-101 dd, .ns-105 dd { 
   margin: 0;
   padding: 0;
}

.ns-1 dl, .ns-3 dl, .ns-5 dl, .ns-7 dl, .ns-9 dl, 
.ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-105 dl { 
   border-top: solid 1px #F0F080; 
   border-left: solid 1px #F0F080; 
   padding-top: 0.5em; 
   padding-left: 0.5em; 
   margin-left: 1em; 
}

.ns-1 dl, .ns-3 dl, .ns-5 dl, .ns-7 dl, .ns-9 dl, 
.ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-105 dl 
{ background-color: #FFFFE0; }

.ns-1 dl dl, .ns-3 dl dl, .ns-5 dl dl, .ns-7 dl dl, .ns-9 dl dl, 
.ns-11 dl dl, .ns-13 dl dl, .ns-15 dl dl, .ns-101 dl dl, .ns-105 dl dl
{ background-color: #FFFFEE; }

.ns-1 dl dl dl, .ns-3 dl dl dl, .ns-5 dl dl dl, .ns-7 dl dl dl, .ns-9 dl dl dl, 
.ns-11 dl dl dl, .ns-13 dl dl dl, .ns-15 dl dl dl, .ns-101 dl dl dl, .ns-105 dl dl dl
{ background-color: #FFFFE0; }

.ns-1 dl dl dl dl, .ns-3 dl dl dl dl, .ns-5 dl dl dl dl, .ns-7 dl dl dl dl,
.ns-9 dl dl dl dl, .ns-11 dl dl dl dl, .ns-13 dl dl dl dl, .ns-15 dl dl dl dl,
.ns-101 dl dl dl dl, .ns-105 dl dl dl dl
{ background-color: #FFFFEE; }

.ns-1 dl dl dl dl dl, .ns-3 dl dl dl dl dl, 
.ns-5 dl dl dl dl dl, .ns-7 dl dl dl dl dl, 
.ns-9 dl dl dl dl dl, .ns-11 dl dl dl dl dl, 
.ns-13 dl dl dl dl dl, .ns-15 dl dl dl dl dl,
.ns-101 dl dl dl dl dl, .ns-105 dl dl dl dl dl
{ background-color: #FFFFE0; }

.ns-1 dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl, 
.ns-5 dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl, 
.ns-9 dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl, 
.ns-13 dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl, 
.ns-101 dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl
{ background-color: #FFFFEE; }

.ns-1 dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl, 
.ns-5 dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl, 
.ns-9 dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl, 
.ns-13 dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl, 
.ns-101 dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl
{ background-color: #FFFFE0; }

.ns-1 dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl, 
.ns-5 dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl, 
.ns-9 dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl, 
.ns-13 dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl, 
.ns-101 dl dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl dl
{ background-color: #FFFFEE; }

.ns-1 dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl, 
.ns-5 dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl, 
.ns-9 dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl, 
.ns-13 dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl, 
.ns-101 dl dl dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl dl dl 
{ background-color: #FFFFE0; }

.ns-1 dl dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl dl, 
.ns-5 dl dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl dl, 
.ns-9 dl dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl dl, 
.ns-13 dl dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl dl, 
.ns-101 dl dl dl dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl dl dl dl 
{ background-color: #FFFFEE; }

With some colorchanges please. _→AzaToth 00:49, 31 January 2006 (UTC)

Oppose strongly. This is something users should put in their own stylesheets. I find it hideous (see for example fr:Discussion MediaWiki:Monobook.css) and the effort necessary for me to override this is daunting. Requests for major changes like this is why they should be discussed on the Village Pump first, not this obscure talk page. -- Netoholic @ 20:57, 1 February 2006 (UTC)

I agree with Netoholic: no, thank you. —Michael Z. 2006-02-1 21:10 Z

ObAOL: Me too. I was wondering: is there a simple mechanism whereby we could drop this into a standard place and allow users to include it into their personal CSS file? I know that you can do this with JS, but I'm not conversant enough with CSS to even start :-( If this were possible, we could have a "bank" of standard CSS chunks which people could use. HTH HAND —Phil | Talk 08:16, 2 February 2006 (UTC)

Good idea. There is the @import rule, but I don't know how it works. You can also have the css inserted by a javascript. :-) — Omegatron 15:21, 3 February 2006 (UTC)

I think you may be able to insert the contents of a page at User:USERNAME/PAGE.css by putting something like the following in your monobook.css. @import must be at the top of the style sheet, before any regular declarations. Warning: not tested. —Michael Z. 2006-02-05 17:24 Z

   @import "/w/index.php?title=User:USERNAME/PAGE.css&action=raw&ctype=text/css";

I don't know why but whenever I test it both using the import function or directly from my monobook.css file it doesn't come out correctly, is there an element that we're missing? Jtkiefer^{T | C | @} ---- 19:08, 5 February 2006 (UTC)

To see an example of importing in use, see my css file on Commons: [1]. I do this to avoid having to make changes across all wikis. —Mike 19:10, 5 February 2006 (UTC)

I figured out the same thing the other day. Also for javascript. See meta:User:Omegatron/monobook.css and meta:User:Omegatron/monobook.js.

Also, I made a modified version of this talk page css with blue instead of yellow and not as much ugliness (in my opinion). A user script that parses each person's comments and puts them in nice boxes would be even better... — Omegatron 04:50, 8 February 2006 (UTC)

Consistent list alignment

[update: this affects only Monobook and Chick skins—I'm proposing fixing both. —Michael Z. 2006-02-01 23:57 Z]

Ordered and unordered lists have different left margins, which confuses the hierarchy of mixed lists. Ordered lists have a left-margin: 3.2em applied, to allow three digits to appear without crowding. Unordered lists have left-margin: 1.5 em, enough so that the left edge of the bullet is slightly inside the left edge of regular text.

The problem with this is that when mixed nested lists occur together, their hierarchy becomes confused, because ordered lists with single-digit numbers appear where a subordinate unordered list would appear:

Default list format

• Unordered list item—level 1.
• Unordered list item—level 1.
  • Unordered list item—level 2.

1. Ordered list item—level 1.
2. Ordered list item—level 1.
   1. Ordered list item—level 2.
3. Ordered list item—level 1.

A real example is in Romanization of Ukrainian#Table of romanization systems. Look at the notes below the table, the third heading "Notes for the Ukrainian National system": Item nos. 1 and 2 appear to be subordinate to "Transliteration can be rendered in a simplified form", but they are actually not, and shouldn't be confused as part of that bullet point. Please note that this style sheet problem affects the perceived meaning of web pages. [I have a applied a workaround by manually typing HTML —Michael Z. 2006-02-1 22:02 Z] [removed "fix", because it breaks other skins —Michael Z. 2006-02-01 23:51 Z]

I propose adding a 3-em left margin to unordered lists: then their starting text would align correctly:

Added 3-em left margin to ordered lists only

• Unordered list item—level 1.
• Unordered list item—level 1.
  • Unordered list item—level 2.

1. Ordered list item—level 1.
2. Ordered list item—level 1.
   1. Ordered list item—level 2.
3. Ordered list item—level 1.
99. Ordered list item—level 1.
999. Ordered list item—level 1.

This appears to display correctly in MSIE/Windows, Firefox, and Safari, using monobook.css. Any objections? —Michael Z. 2006-02-1 21:04 Z

I'm worrying that by doing this change that we'll break articles that were made with these margins in mind... just the reverse case of your example. I know that the bullets are often used in tight spaces, like in Deus Ex's infobox. -- Netoholic @ 21:19, 1 February 2006 (UTC)

Good point. Looking at that example, I notice that raw <li> tags were typed by an editor, and that <ul class="noindent"> was added surrounding them (by Tidy?). But I can't find .noindent in any of the style sheets. We could add ul.noindent { margin-left: 1.5em; } to prevent messing with cases like these, but I can see this still being a problem in other cases. Perhaps all lists in tables should not have this rule applied:

        /* consistent margin with numbered lists */
        ul { margin-left: 3.2em; }
      
        /* restore default value for raw list items and lists in tables */
        ul.noindent,  table ul { margin-left: 1.5em; }

I know: it's getting a bit complicated. —Michael Z. 2006-02-1 21:43 Z

Quite. I'd suggest using your workaround to fix that one article, as I don't see a big justification for changing every bullet list everywhere. I was also thinking that bullets are used in discussions and votes quite often, and changing the indent could confuse the context (who someone was replying to). -- Netoholic @ 21:50, 1 February 2006 (UTC)

Good point about discussions too, but although old discussion may be twiddled a bit, this fix would make it easier to create correctly nested lists in discussions, without repeatedly previewing.

It would be too bad though, if we were stuck with these HTML elements, specifically designed to reflect nested structure, always incorrectly displaying nested structure, and having to type raw HTML every time it needs to work. —Michael Z. 2006-02-1 21:57 Z

I've applied the workaround as you suggested by typing some HTML manually. This actually messes up the lists a bit, but wikitext does so in many situations anyway. —Michael Z. 2006-02-1 22:03 Z

It turns out that this problem is the result of a bug in the Monobook and Chick skins. All other skins align the lists correctly by default. This means that any "fixes" applied in the wikitext will break rendering in other skins. Since these two skins are "broken" in relation to all other skins as well as to browsers' default rendering, I'm re-proposing applying the fix to those two skins, so that lists will be rendered consistently (and correctly) across all the skins. —Michael Z. 2006-02-01 23:51 Z

For the monobook skin, that change was applied by "gabrielwicke" over the course of a couple changes in April 2004. He added margin to the ol. I don't support adding more margin to ul's to compensate, due to the examples I showed you. Let's not get complicated. Contact him to see if he remembers any specific reason for the change. I'd rather see any non-project-specific alterations be made to the skins source code, not here. -- Netoholic @ 00:54, 2 February 2006 (UTC)

Thanks. I see he changed the ol's left margin from 1.5em to 2.4em to 3.2em, which looks like space for one, two, and three-digit numbers to the left of the decimal point, while for ul's it remained 1.5em. I'll see if I can get him to look at this issue. —Michael Z. 2006-02-02 01:11 Z

That may be moot, as Gabriel hasn't edited English WP for three months. I've filed bug 4829 at Bugzilla.

Still, it would be good to fix this. Another possibility is to reduce ol's margin-left to 1.5em, or even both of them to 1.0em, but change list-style-position to inside: this would mean that two- and three-digit numbers would have the decimal point aligned differently, but nested lists would work right, and both types of lists would sit closer to the left margin for the sake of lists in tables. —Michael Z. 2006-02-02 01:37 Z

Surely this sort of thing should be in mediawiki:common.css so that all skins use it? Why not simply shift it in there? HTH HAND —Phil | Talk 08:20, 2 February 2006 (UTC)

The problem is a difference in rendering the two different types of lists, in only the two skins Monobook and Chick. Code in Common.css modifies all skins, so that wouldn't be an appropriate place for it. We can apply an overriding declaration to Wikipedia's user-editable Monobook.css and Chick.css, but it would be better still to fix the code in the main Monobook and Chick style sheets which are part of the MediaWiki software.

I've filed a bug report for MediaWiki, and if there is consensus I would also apply the fix in the local style sheets immediately. —Michael Z. 2006-02-02 08:40 Z

Sorry, must not be expressing myself clearly (as usual ). What I mean is that obviously if Monobook and Chick (where is that defined/documented BTW?) are doing something different, they are overriding something which all the other skins have in common. This common code should presumably be in common.css and we should simply remove the override which has been added to monobook.css and chick.css. Where is this common behaviour actually defined? HTH HAND —Phil | Talk 13:51, 2 February 2006 (UTC)

I think there is no main "commmon" style sheet: CSS declarations in each skin override your browser's default rendering. (Common.css is merely a set of editor-accessible add-on styles that apply to all skins.) I've only looked at a couple of the other skins, but it looks like they are all relying on the browsers' default rendering of ordered and unordered lists, and not applying their own different format.

So what you're suggesting would require removing declarations from the main software-included main Monobook style sheet to let the browser do its thing (not the editor-accessible add-on Monobook.css). To see what that would look like, I tried overriding Monobook's formatting by adding margin-left:inherit to a list on the page. That makes the list bullets and numbers overlap the left border in an ugly fashion (this test won't work in MSIE because it doesn't support the CSS 'inherit' value). So I think the Monobook declarations for lists will have to be changed, not removed—but this is no more difficult, and if the values match then the results will, too.

As I mentioned, an early version of Monobook applied margin-left:1.5em to both ordered and unordered lists, but the ordered list was later changed to prevent two-digit and three-digit list numbers from overlapping the left border, while unordered lists were not changed to be consistent. The Monobook CSS declarations for lists appear to have been copied into the Chick skin. This is now a rare but not insignificant problem in the way hierarchical lists convey information in those two skins. —Michael Z. 2006-02-02 16:18 Z

Regarding Netoholic's concern about lists in tight spaces, that is, lists in tables: ordered lists in tables currently have a too-big margin, anyway. We could make lists in tables consistent and more space-efficient than they are now by applying the following override. This is not complicated, and the results are predictable in different browsers. —Michael Z. 2006-02-02 16:41 Z

th ol, 
th ul, 
td ol, 
td ul { 
    list-style-position: inside; 
    margin-left: 0; 
    padding-left: .5em; 
}

We're not talking a change to some structure unique to Wikipedia, so this change should be proposed to the developers -- not changed here on the project-specific CSS. -- Netoholic @ 16:53, 2 February 2006 (UTC)

Why can't we implement an overriding fix in our style sheets now, while we wait for developers to update the software? —Michael Z. 2006-02-02 17:24 Z

With respects, there is no urgency. You have one example of where things dont work ideally, while the current arrangement has been in place for a long time. -- Netoholic @ 17:36, 2 February 2006 (UTC)

How is that a reason not to try it? A fix in monobook.css and chick.css is easily modified or removed, and the feedback from en.wikipedia editors would save the developers lots of debugging cycles. —Michael Z. 2006-02-02 18:39 Z

Change it in your personal stylesheet, but there is too much potential for "surprise factor" and your method is not one I think works everywhere. Wikipedia will not collapse without this, and it's not even that helpful. -- Netoholic @ 05:20, 3 February 2006 (UTC)

What do you mean "my method"? It's the default method of HTML rendering, and also of five out of seven Wikipedia skins. What do you mean it doesn't work everywhere?

Lists are displayed incorrectly. The structure of information is misrepresented in Monobook and Chick skins. The only "suprise" would be that lists would no longer be cockeyed.

What reason is there not to fix this display glitch? —Michael Z. 2006-02-03 06:13 Z

I don't see it as a glitch. So many people use Monobook, and so few use other skins, that one can assume that pages are often designed to look well in monobook. This doesn't seem like a glitch, since it was purposefully added to the monobook skin by the developer. Send it back to them to look at, and leave things be for now. This is not urgent. -- Netoholic @ 06:18, 3 February 2006 (UTC)

Lists are displayed incorrectly. The structure of information is misrepresented, in two of the skins. "Glitch" is being polite. The change was purposely added to solve one problem, and caused another that the developer didn't notice. "Pages are often designed to look well in monobook": what does that mean—we are redefining list structure so monobook's display is right and the HTML hierarchy is wrong?

What did you mean by "your method is not one I think works everywhere"? You keep making up these criticism that have no basis in reality. This style sheet has bugs, and they should be fixed. —Michael Z. 2006-02-03 06:56 Z

Is this the same problem as #indents next to images? — Omegatron 23:44, 5 February 2006 (UTC)

No, that one is a case where things don't render as expected. In this case, everything is rendering correctly, it's just that the specifications in the style sheet for different kinds of lists give them different amounts of indentation. So when the ordered and unordered lists are mixed, the amount of indentation varies between them, and the hierarchical relationship is misrepresented. —Michael Z. 2006-02-06 05:49 Z

Definition lists

While you are at it, I wondered whether you could also look at the indent of inserted by ":" (at the start of a line). I sometimes write things like

---

• Point one.
• Point two. 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.

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.

• Point three.

---

I'd like the bit after the formula to line up with the bit before the formula. This can be achieved by using HTML tags:

---

• Point one.
• Point two. 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.

  

  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.
• Point three.

---

But that's not ideal either :( Is this also a CSS issue? -- Jitse Niesen (talk) 21:34, 2 February 2006 (UTC)

":" translates to the HTML tag <DD>, which, while it can be used to indent, is ultimately not the right way to indent. Can you wrap the <math> structure in a <DIV>? Give me a live example and I'll see if I can help. It's a corner-case, and changing all instances is unpredictable. -- Netoholic @ 05:20, 3 February 2006 (UTC)

If <DD> is not the right way to indent, why does ":" translate to it? Surely, ":" is meant to indent (at least, that is what m:Help:Editing says).

Live examples can be found at Fermat number. But I thought the idea behind wikicode is not to use HTML tags (and, as I said, I know one way of achieving it with HTML tags).

I do agree with Netoholic that it is not urgent, and it might be better to do it via the MediaWiki developers. -- Jitse Niesen (talk) 13:23, 3 February 2006 (UTC)

This is another example where the default rendering of HTML lists has got cocked up in monobook. The part after the formula does line up with the part before it when viewed without style sheets, and in every Wikipedia skin except Monobook and Chick.

Fixing list rendering would make that display correctly, without any awkward workarounds like extra divs. —Michael Z. 2006-02-03 06:13 Z

On the other hand, this is a situation that wikitext can't handle correctly: there seems to be no way of putting all of point two into a single bullet point. Inserting the math equation closes the list item and inserts a paragraph break. Wikitext doesn't support multi-paragraph bullet points. The most correct way is to use line breaks as below, although this doesn't indent the equation (non-breaking spaces could be added for the sake of visual layout). —Michael Z. 2006-02-03 19:30 Z

• Point one.
• Point two. 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.
  
  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.
• Point three.

This just points out some of the weaknesses of using wiki markup. In the strictest sense, ':' should only be used with definition lists, but of course everyone (myself included) uses it for indenting text. The following example provides the best method I have found for creating multi-paragraph bullet points. (You could apply additional indenting to the math using a style statement.) —Mike 19:44, 5 February 2006 (UTC)

NavFrame/NavHead format

Can somebody look into these to make sure they have the same amount of whitespce as the older footers with class="toccolours"? The Navrame classs should have a padding of 5px instead of 2. Circeus 19:10, 11 March 2006 (UTC)

Proposed addition to Monobook.css

de.wikipedia has added several lines in their monobook.css that positions their coordinates template at the top right-hand side of the page just above the horizontal rule associated with the article title. (See de:Kaffee Alt Wien for an example.) They achieve this by giving the top-most container a "coordinates" HTML id in the template file.

I have replicated this in my personal monobook.css and created an alternative version of {{coordinates}} in my playground. Would anyone be opposed to adding the appropriate CSS into Monobook.css in order to make these changes globally?

That would probably cause problems with the {{featured}} template, which already conflicts with some user scripts that put an "edit" link there for the lead. Circeus 14:02, 17 March 2006 (UTC)

Ah, I didn't realize. I just figured that it would take a useful tool and move it to an unobtrusive position outside of the typical article body. - Cybjorg 16:10, 17 March 2006 (UTC)

You mean {{featured article}}, right? I took a look at the layout of that template and I think it would be fairly easy, given the way the de.wikipedia template's CSS is written, to make sure the Featured Article star is given enough room. (They both use pixel-based measures to set how far from the right they appear.) The only drawback is that there would be a Featured Article star–sized space to the right of the coordinates a non-featured article's page. — Saxifrage ✎ 04:24, 20 March 2006 (UTC)

Coordinates in article heading

Over the past several months, I've tried the documented routes of posting at Wikipedia talk:WikiProject Geographical coordinates#Coordinates at the top of the article, bug 4719, and on the village pump (twice), but no joy. So, for documentation, here's what other *pedia have done (as of today).

---

de:MediaWiki:Monobook.css

/* Formatierung betrifft Vorlagen: Geokoordinate, Koordinate2 & Koordinate3 */

#coordinates {  
   position:absolute;
   z-index:1;
   border:none;
   background:none;
   right:12px;
   top:0.3em;
   float:right;
   margin:0.0em;
   padding:0.0em;
   line-height:1.5em;
   text-align:right;
   text-indent:0;
   font-size:85%;
   text-transform:none;
   white-space:normal;
}

/* kleines Globus-Symbol neben der Geookordinate anzeigen */

#coordinates a[href ^="http://"] {
   background: url(http://upload.wikimedia.org/wikipedia/de/d/d4/Gnome-globe.png) center right no-repeat; padding-right: 18px !important;
}

/* für Vorlage:ISSN-Link damit ohne Globus-Symbol */

#issnlink {  
   position:absolute; z-index:1; border:none; background:none; right:12px; top:0.3em; float:right; margin:0.0em;
   padding:0.0em; line-height:1.5em; text-align:right; text-indent:0; font-size:85%; text-transform:none; white-space:normal;
}

---

pt:MediaWiki:Monobook.css#Geocoordenadas

/*

• • Formato do Geocoordenadas
  • da WP:DE
• /

#coordinates {  
 position: absolute;
 z-index: 1;
 border: none;
 background: none; 
 right: 12px; 
 top: 1.5em;
 width: 45.0em;
 /* float: right; */
 margin: 0.0em;
 padding: 0.0em;
 line-height: 1.5em;
 text-align: right;
 text-indent: 0;
 font-size: 85%;
 text-transform: none;
 white-space: normal;
}

#coordinates a[href ^="http://"] {
 background: url(http://upload.wikimedia.org/wikipedia/de/d/d4/Gnome-globe.png) center right no-repeat !important;
 padding-right: 18px !important;
}

---

nl:MediaWiki:Monobook.css

/* Voor Sjabloon:Coördinaten */

#coordinates {  
  position: absolute;
  z-index: 1;
  right: 12px;
  top: 0;
  background: #fff;
  padding-left: .5em;
  float: right;
  text-align: right;
  font-size: 85%;
}

#coordinates a[href ^="http://"] {
  background: url(http://upload.wikimedia.org/wikipedia/de/d/d4/Gnome-globe.png) center right no-repeat;
  padding-right: 18px !important;
}

---

Obviously, these won't work for classic and others (the german and portugese have variants for "Nostalgia"). But please put something into monobook, as the natives are getting restless while waiting for our overlord "admins" to act (see yesterday's {{CoorHeader}} that breaks various pages).

--William Allen Simpson 10:55, 21 March 2006 (UTC)

---

After experimentation, the current Template:Coor title dms values to be inserted here are:

#coordinates {  
 position:absolute;
 z-index:1;
 border:none;
 background:none;
 right:30px;
 top:3.7em;
 float:right;
 margin:0.0em;
 padding:0.0em;
 line-height:1.5em;
 text-align:right;
 text-indent:0;
 font-size:85%;
 text-transform:none;
 white-space:nowrap;
}

--William Allen Simpson 15:52, 1 April 2006 (UTC)