MediaWiki talk:Common.css

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

This talk page is automatically archived by Werdnabot. Any sections older than 31 days are automatically archived to MediaWiki talk:Common.css/Archive 3. Sections without timestamps are not archived.

.IPA class

Please look at http://bugzilla.wikimedia.org/show_bug.cgi?id=11019

CSS IPA class uses font-family of IPA fonts _only_ for Internet Explorer and rely on glyph substitution for any other browser. It's interesting aproach, but doesn't work that good. First of all, glyph substitution is fallback and it isn't really intended to be used as much as possible! There are real results of glyph substitution. Same problem is with similar classes.

I'm sorry about imageshack, but i'm not registred here.

-- Lukas Vacek

I don't think there can be situation where result of automatic font subsitution is better then directly selecting ideal IPA font. If I understand font substitution well that .IPA class with inherit is important even for browser with font substituion. I would like to know your opinions. But it's probably not so much important, because people interested in language issues and using not tested browser would be probably able to change appropriate css style.

-- Lukas Vacek

IPA hack replaced by JS

In one of the next edits IPA { CSS hack can be removed, since it's been replaced by JavaScript: see MediaWiki talk:Common.js/Archive Nov 2007#IPA style for IE ∴ AlexSm 15:10, 27 December 2007 (UTC)

Which lines exactly need to be removed? — Edokter • Talk • 15:58, 29 December 2007 (UTC)

It's definitely the declaration

.IPA {
    font-family: "Chrysanthi Unicode", "Doulos SIL", Gentium, GentiumAlt, Code2000, "TITUS Cyberbit Basic", "DejaVu Sans", "Bitstream Cyberbit", "Arial Unicode MS", "Lucida Sans Unicode", "Hiragino Kaku Gothic Pro", "Matrix Unicode";
    font-family /**/:inherit;
}

but CSS IE hacks is not my area expertise, so I would ask User:Tgr first. He did mention that IE users with JS turned off will not see IPA properly; also, if /**/ hack indeed doesn't work in IE7, why is it still used in Common.css several times and not replaced by something else... ∴ AlexSm 21:04, 29 December 2007 (UTC)

Unnecessary semicolons

Do CSS specs really require these extra semicolons? Since they looks ugly and also add several extra bytes, what's the point of adding them? ∴ AlexSm 14:26, 19 January 2008 (UTC)

While technically not required, they act as seperators between CSS statements. It is more a matter of coding consistency to end each statement with a semi-colon. They add nothing in either server- or client load. — Edokter • Talk • 14:52, 19 January 2008 (UTC)

The specification (at w3.org) notes that each statement must be terminated by a semi-colon or an end of block, and earlier incarnations (iirc) mandated the semi-colon, so continued use is there for (a) completeness, and (b) safety that if someone expands the definition by adding an extra clause/element then the existing markup is complete for that to happen. It is when shortcuts (eg PHP just using "<?") that faults can more easily get accidentally introduced. Safety first with coding completeness consistency! --AlisonW (talk) 15:10, 19 January 2008 (UTC)

I'd have to agree, I can't count the number of times I've broken CSS I was editing because I forgot to insert a seperating semicolon... =P --Dinoguy1000 17:06, 19 January 2008 (UTC)

Okay then. However, if "safety first" was really an objective, then only bureaucrats should be able to edit these files, and only after consensus. There were a number of times the code was broken by either careless or lazy; and remember that for some visitors the result was cached for a long time ∴ AlexSm 19:46, 19 January 2008 (UTC)

handhelds

as handhelds have limited viewable area, I suggest adding following (or similar):

@media handheld {
  .infobox,
  .messagebox,
  .metadata,
  .ambox,
  .NavFrame {
    display: none
  }
}

This to prevent optional things like infoboxes, navboxes, message boxes and other metadata to be displayed. _→AzaToth 21:11, 29 January 2008 (UTC)

Demonstration of div problems in Wikipedia on handheld device.

Also, there's an issue on my Sidekick with the sidebar taking up half the screen. I imagine this is the same with other handheld devices as well. I'll try to get a photograph of it. Cary Bass ^demandez 21:15, 29 January 2008 (UTC)

Also .navbox? Are there amboxes that aren't also metadata? See source of {{ambox}}. –Pomte 21:27, 29 January 2008 (UTC)

You might want to try Opera Mini, which seems to handle Wikipedia pages better. —Remember the dot ^(talk) 17:35, 14 February 2008 (UTC)

Redirects in italic

{{edit protected}} In order to be more visible, redirects appear in italics in categories and on special pages, but it's still hard to find them among long long lists. I would like to apply them a different colour like it is the case on the French-language Wikipedia, example:

• Template:En icon All pages with titles beginning with Jonathan
• Template:Fr icon All pages beginning with Jonathan

See how much better they stand out from the crowd (if you don't like the green colour, you can choose another one, it doesn't mind me). 16@r (talk) 23:48, 11 February 2008 (UTC)

I think this warrants a little more discussion istead of an "immediate edit", so I've disabled the editprotected template. Personally, I think showing redirects in italics are sufficient. — Edokter • Talk • 00:00, 12 February 2008 (UTC)

I don't think it's a good idea to do any coloring in Common.css unless a background color is also specified. Different skins use somewhat different background colors, and colors won't necessarily look the same on all of them. Some users might even use light-on-dark custom CSS, although that's kind of masochistic anyway. That green is kind of ugly on Monobook, in my opinion.

As to the issue itself, I think it's an okay idea. It should be more useful than not, provided the color isn't too garish. —Simetrical (talk • contribs) 00:49, 12 February 2008 (UTC)

What about adding a redirect icon beside the links in the same way that we have external-link icons? Nihiltres^{t.l} 01:38, 12 February 2008 (UTC)

Oh yes! Good idea! 16@r (talk) 02:07, 12 February 2008 (UTC)

I'll try some code out on my local (browser [Safari], not monobook.css) CSS file to make this happen … I'll have to make a resized version of a redirect icon, though that's just a matter of scaling a PNG (SVGs wouldn't be converted :'( ) Nihiltres^{t.l} 17:01, 14 February 2008 (UTC)

Template:Selfref

I removed the use of the class "plainlinks selfreference" from this template since it is not defined here. We should probably define a class simply named "selfref" and similar to "dablink". What do you think about it? 16@r (talk) 00:14, 16 February 2008 (UTC)

That's because it is not a class, but two seperate CSS selectors, one of which is defined im main.css. "selfreference" is not defined, however it is customary to assign classnames to templates for future use and custom CSS/scripting so users can filter them out. I have reverted it. — Edokter • Talk • 00:36, 16 February 2008 (UTC)

line-spacing with sub & sup

There was a discussion on the VP about the linspacing with sup and sub 2 weeks ago. I promised I would take another look at it, but I was offline for over a week and therefore didn't really get around to it until yesterday. I think I have now found a way to implement this, without breaking any of the major browsers that are in use. It is based on User:Mzajac/monobook.css/Superscript fix. I removed the explicitly defined font size from Mzajac's solution, which was causing unpredictable cross-browser results. I now simply rely on "inheritance". I have also added an IE6 specific CSS line because IE6 does not properly recognize "vertical-align: baseline;". This should not conflict with any other browsers, and IE7 will ignore it.

/* Avoid superscript and subscript text from breaking the line-spacing */
/* Based on [[User:Mzajac/monobook.css/Superscript fix]] */
/* Added _vertical-align: bottom; from http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&productId=1&postId=5341 */
sup, sub {
    vertical-align: baseline;
    _vertical-align: bottom; /* IE6 hack */
    position: relative;
}
sub {
    bottom: -0.25em;
}
sup {
    bottom: 0.33em;
}

This code is tested and confirmed to work with: Safari 3, FF 1-3, Opera 9.25.3721, IE6 and IE7. I'm pretty sure that Safari 2 and earlier Opera versions accept this as well but was unable to test it. I guess the IE6-hack might put some folks off. I don't really like it myself either, but I also don't see another way to fix this without adding JS into the mix, and that seems kinda over the top to me. Comments ? --TheDJ (talk • contribs) 11:59, 19 February 2008 (UTC)

an alternative proposal. Just so we consider all the options. —Random832 17:00, 19 February 2008 (UTC)

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. Some nested superscripts with your proposal x^yzxyzπ. 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. Some nested superscripts with my proposal x^yzxyzπ. 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. Single superscript with your proposal x^y. 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. Single superscript with my proposal x^y. 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.

Mine expand where room is needed but will fit into the available space when there is space - yours are squeezed down so it is hard to tell they are superscripts, and eventually run up into the next line. —Random832 17:05, 19 February 2008 (UTC)

I hate to say it, but all the examples of possible fixes I've seen (both here and on the referenced discussions) fail miserably in my browser (IE7), either by pushing the line of text really far down, or by allowing the superscripts to run up into the line above. —Dinoguy1000 18:01, 19 February 2008 (UTC)

Here is an example with no extra styling at all - the problem with pushing the line of text down is unavoidable. —Random832 19:00, 19 February 2008 (UTC)

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. Test: x^yzxyzπ. 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.

Hmm, i had not considere multiple sub/sup levels on IE and it also does indeed look less than pretty on Firefox with multiple levels. Well that only leaves 2 options

1. we javascript the addition fo add line-height: 0; for the various browsers in common.js
2. we add line-height: 0; to the browser specific CSS hacks in Mediawiki

I'll start by writing something that does 1 so we can test it. --TheDJ (talk • contribs) 19:42, 19 February 2008 (UTC)

The multiple nested sups or subs are not realistic. No matter what solution is being presented, it always screws up one browser or the other. And we have to account for all other skins as well. So I recommend just let the browsers handle it. The ultimate cause is that Wikipedia uses a fairly tight linespacing in the first place. — Edokter • Talk • 20:00, 19 February 2008 (UTC)

Adding something like

if( is_opera || is_safari || is_gecko) {
    importStylesheet( 'User:TheDJ/lineheight.css' );
}

to MediaWiki:Common.js would fix it for 3 major browsers. And I guess we just have to forget about IE. The multiple nested subs are sometimes used in Chem and Math articles, so I do not think it is wise to fully ignore those. The biggest problem is that is is Yet Another Stylesheet. I'm counting 12 for myself now, on any given page. I do prefer the readability however. --TheDJ (talk • contribs) 20:07, 19 February 2008 (UTC)

If it does come to a JS fix, please do not use another separate external CSS file. Instead define appendCSS (see below), which is useful by itself, and then simply use appendCSS('sup, sub {line-height:0}') —AlexSm 21:11, 19 February 2008 (UTC)

function appendCSS(text){
 var s = document.createElement('style')
 s.setAttribute('type', 'text/css')
 if (s.styleSheet) s.styleSheet.cssText = text //IE
 else s.appendChild(document.createTextNode(text))
 document.getElementsByTagName('head')[0].appendChild(s)
 return s
}

I see no other way to fix this without CSS. I'm moving this proposal to the MediaWiki talk:Common.js --TheDJ (talk • contribs) 14:41, 21 February 2008 (UTC)

The ultimate cause is that Wikipedia uses a fairly tight linespacing in the first place. well, not really - it uses 1.5 spacing, which has plenty of room for a single superscript, but the problem is, right now, the line-height of the superscript _not_ being set to 0 means it tries to apply the extra half-line space _above the superscript_. —Random832 04:07, 24 February 2008 (UTC)

I don't think making the line-height:0 a browser-specific hack is necessary - it doesn't make anything any _worse_ on IE. —Random832 04:08, 24 February 2008 (UTC)

I thought you said it had adverse affects with IE6 and multiple level sup/sub ? Or did I remember that incorrectly? --TheDJ (talk • contribs) 10:27, 27 February 2008 (UTC)

Updates

Is there any solution immanent for this?

See a screenshot of the problem at Image:Wikipedia-Gibson-article-screenshot-supscript-problem.png. This is taken from the William Gibson article, using the font DejaVu Sans (my default in Opera, Ubunutu Linux). A handful of fonts show the same problem.

(It's the single superscript tags that should be the main cause for concern (not the multiple-nested tags), as these are everywhere, and appear both unprofessional and confusing.)

Thanks. -- Quiddity (talk) 02:01, 13 March 2008 (UTC)

There is no progression on this. I don't have IE, so I cannot verify what IE does or does not do. Also, I tried for over 2 weeks to get somewhere on this issue. My experiences tell me that few people actually care about solving the issue apparently. Otherwise there would be progress. --TheDJ (talk • contribs) 02:10, 20 March 2008 (UTC)

Some nested superscripts with 1em x^yzxyzπ. 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. x^y

Illegible paragraphs with citations

A problem that I raised below is that paragraphs effectively disapear when you cite references, as you should. This is because they push the lines further apart, so that they are the same height as paragraph gaps. See Sydney Hilton bombing for an example of how bad this can look when there are lots of citations (2nd or 3rd section).

One solution is to increase paragraph gaps slightly. Another is to not increase line height for first sup. A third is to have refs produce a different sup style.

Note that I am just talking of the simple, common single sup. The Hilton bombing article actually looks fine in IE with all CSS turned OFF, ie default behavior. But hard to read with wikipedia style. Tuntable (talk) 23:49, 20 March 2008 (UTC)

Request Unicode font: Everson Mono

I would like to request the "Everson Mono Unicode" font be added to the Unicode list, please. J. Myrle Fuller (talk) 01:01, 21 February 2008 (UTC)

Why? —Remember the dot ^(talk) 05:56, 21 February 2008 (UTC)

Infobox top margin tweak

{{editprotected}}

I'd like to request that margin-top: 5px; be added to the .infobox class. Presently, infoboxes collide with the bottom margin of amboxes, brought up here, as well as disambig hatnotes, brought up here.--Father Goose (talk) 00:46, 25 February 2008 (UTC)

Strongly agree. Wish I'd suggested it months ago! For examples of the problems, see Articles of Confederation (ambox) and Apollo 11 (hatnote). -- Quiddity (talk) 01:10, 25 February 2008 (UTC)

Don't you mean .ambox? And no, it isn't a good idea, as the boxes would fail to stack. Just insert a <br/> or {{-}} to create some space. — Edokter • Talk • 01:15, 25 February 2008 (UTC)

Sorry, I got confused by your message at WT:AMB#buffer?. I'll have a look. — Edokter • Talk • 01:30, 25 February 2008 (UTC)

 Done, though I used 0.5em; margins should scale. — Edokter • Talk • 01:39, 25 February 2008 (UTC)

W00t.--Father Goose (talk) 02:37, 25 February 2008 (UTC)

Ambox prints

{{editprotected}}

Per discussion at Template talk:Ambox#Ambox prints: Article message boxes should not be visible when printing Wikipedia articles. Thus directly after the last .ambox class in Common.css we suggest adding this code:

/* Removes article message boxes from paper printouts. */
@media print {
    .ambox {
        display: none;
    }
}

That's all.

--David Göthberg (talk) 13:40, 27 February 2008 (UTC)

 Done. — Edokter • Talk • 15:40, 27 February 2008 (UTC)

Thanks Edokter. And nice shortening of the comment to that code.

--David Göthberg (talk) 01:01, 28 February 2008 (UTC)

tinyurl.com

{{edit protected}} The moronic spamfilter has tinyurl dot com on the spam blacklist. This page (edit: and MediaWiki:Monobook.css) contains a reference so other Wikipedia sites can't copy the template over as-is.

Someone please change the link or hit whoever put it on the spamfilter over the head. --Ævar Arnfjörð Bjarmason 11:56, 28 February 2008 (UTC)

Well, it's not moronic if you actually want to use a spam blacklist to stop people from linking to their sites. Since otherwise they could just use tinyurl . . . —Simetrical (talk • contribs) 18:33, 28 February 2008 (UTC)

I don't see the problem; just remove the URLs when copying to your wiki. It's only in the comments anyway, so it has no effect on functionality. It is just there for reference. — Edokter • Talk • 18:37, 28 February 2008 (UTC)

I agree, there is no problem with the link itself, since it is inside comments. I do, however, see the problem with the whole large section which is NOT supposed to be there. It should just state "ATTENTION ADMINISTRATORS: SEE TALK PAGE BEFORE EDITING", and then any long explanations should be on the talk page. P.S. Also, the suggestion to use "CSS Validation" after changes is imho irresponsible. —AlexSm 19:04, 28 February 2008 (UTC)

Extra CSS for Navboxes

/* default skin for navigation boxes 
 * See [[Template:navbox]]
 */
table.navbox {
	background-color: #f9f9f9;
	border: 1px solid #aaa;
	clear: both;
	font-size: 90%;
	margin: 1em 0em 0em;
	padding: 2px;
	text-align: center;
	width: 100%;
}
.navbox .title, .navbox tr:not(:first-child) th {
	text-align:center;
	width:100%;
	background-color: #ccf;
}
.navbox .subtitle {
	text-align:center;
	background:#ddf;
}
.navbox td.imageleft {
	vertical-align:middle;
	padding-left:7px;
	width:0%;
}
.navbox td.imageright {
	vertical-align:middle;
	padding-right:7px;
	width:0%;
}
.navbox th {
	padding-left: 1em;
	padding-right: 1em;
	/* Interference with titles * white-space:nowrap; * wrapped */
	background:#ddf; /* changed from #ccf */
	text-align:right; /* Center */
}
.navbox th.odd td{
	width:100%;
	font-size:95%;
}
.navbox th.even td {
	width:100%;
	font-size:95%;
	background:#f7f7f7;
}
@media print {
	.navbox {
		display: none;
	}
}

{{Edit protected}}{{Navbox}} has been using inline CSS for the navbox. This is very messy, hinders portability to other skins, and increases the size of pages. Back in December has I had worked the templates but had not finished the CSS that would go here. I've since expanded the CSS included to nearly all inline CSS with deviation from the old default noted in comments. — Dispenser 21:16, 2 March 2008 (UTC)

 Not done for now - work out exactly what needs to be added and hammer out any issues. A sandbox would be ideal - perhaps the test wiki? Happy‑melon 15:51, 3 March 2008 (UTC)

Just a few comments:

• (navbox.th): background-color and background are the same.
• tr:not(:first-child) is not IE compatible.
• white-space:nowrap; makes wrapping impossible in long headers.

— Edokter • Talk • 21:37, 2 March 2008 (UTC)

• I missed that, good spot.
• The :not element is currently only supported by Firefox. And was previously removed following a discussion. I'm adding it back in because there are still old navbox that have not been converted to the template.
• Id had forgotten about this element being used in the headers too, so I've disabled it. It'll likely be kept in {{navbox}} due to backwards compatibility.

— Dispenser 00:56, 3 March 2008 (UTC)

Is there a sandbox where we can check out this new version of the navbox styling if I add this CSS to my own monobook ? I'm especially interested in verifying how ".navbox .title, .navbox tr:not(:first-child) th {" is handled in Safari 3. --TheDJ (talk • contribs) 11:44, 3 March 2008 (UTC)

:not(:first-child should be fine in Safari (WebKit), see Comparison of layout engines (CSS). However, since :not is not supported by both IE and Opera, it cannot be used in Common.css; :first-child is debatable, since only IE6 can't handle it. I don't think it's difficult to "invert" rules a little and to get rid of :not part. —AlexSm 15:01, 3 March 2008 (UTC)

Procedural note: Any updates to Common.css will take about 30 days to fully take effect (due to client-side caching). Any updates to a template will happen in a matter of hours. So... the template updates should probably wait a month after the updates to Common.css to ensure compatibility. Especially since navbox is so widely used. --MZMcBride (talk) 22:00, 2 March 2008 (UTC)

• Is it possible/advisable/acceptable to try adding the equivalent of

|groupstyle = line-height:1.1em; padding:0.35em 1.0em;
|liststyle  = line-height:[1.4em or 1.5em];

to this CSS, in order to:

1. Ensure there isn't a wide gap between lines when groupnames are wrapped;
2. Ensure the gap between lines wrapped within a list is smaller than the gap between the last line of a list in one group and the first line of the next...?

For comparison, here's one Navbox without the above parameters followed by one with:

"With" seems better formatted and more user-friendly (especially in the distinction between group lists, backgrounds notwithstanding) to me. Sardanaphalus (talk) 14:08, 3 March 2008 (UTC)

Have amended the above by removing the "white-space:normal;" from the proposed groupstyle; I realize this would cause most groupnames not already using &nbsp;s or {{nowrap}}s etc to become crunched. I think, however, this means that "groupNstyle" parameters will be needed so that wrapping longer groupnames suitable can be allowed using " within Navboxes. Anybody reading this? Sardanaphalus (talk) 00:34, 5 March 2008 (UTC)

.navbox th.odd td { … }
.navbox th.even td { … }

This is incorrect, you probably mean tr.odd td and tr.even td. —Ms2ger (talk) 17:12, 9 March 2008 (UTC)

That does seem more logical. Another thing i'm wondering about is if some of the CSS that now uses values in px, should not use values in em instead. This would be a big change and we better make sure we do it correctly. (also considering the rate at which stuff gets copied into other language wiki's ) --TheDJ (talk • contribs) 10:46, 21 March 2008 (UTC)

Updated code

{{editprotected}} I have updated and simplified User:Dispenser's code to avoid breaking navboxes in the wild, to reflect current usage in {{Navbox}} and to get better fall-back for older browsers (I hope). Code and changelog in the table below:

CSS for navboxes
Old code: /* default skin for navigation boxes */ table.navbox { background-color: #f9f9f9; border: 1px solid #aaa; clear: both; font-size: 90%; margin: 1em 0em 0em; padding: 2px; text-align: center; width: 100%; } table.navbox th { background-color: #ccf; padding-left: 1em; padding-right: 1em; } @media print { .navbox { display: none; } }
New code: /* default skin for navigation boxes * See [[Template:Navbox]] */ table.navbox { background: #f9f9f9; border: 1px solid #aaa; clear: both; font-size: 90%; margin: 1em 0em 0em; padding: 2px; text-align: center; width: 100%; } .navbox .title { text-align: center; width: 100%; background-color: #ccf; padding-left: 1em; padding-right: 1em; } .navbox tr:first-child th { text-align: center; background-color: #ccf; white-space: normal; } .navbox .subtitle { text-align: center; background: #ddf; } .navbox td.imageleft { vertical-align: middle; padding-right: 7px; width: 0%; background: white; } .navbox td.imageright { vertical-align: middle; padding-left: 7px; width: 0%; background: white; } .navbox th { padding-left: 1em; padding-right: 1em; background: #ddf; } .navbox td { font-size: 95%; } .navbox tr.odd { background: white; } .navbox tr.even { background: #f7f7f7; } @media print { .navbox { display: none; } }
Gave .title and tr:first-child th their own ruleblocks, so older browsers can use .title. Removed the width from tr:first-child th, because it would mess up templates like {{Forms of cricket}}, and from td for {{Arbitration enforcement/Archive navbox}}. Moved the margin on the image cells to where they are now and specified a background to avoid them being colored by the striping code. Removed text-align:right; from the headers, this causes unwanted effects on, for example, {{ButtholeSurfers}} and {{2007-08 in South American Football (CONMEBOL)}}. Made the styles for the td's affect all cells, not only those in specifically marked up rows. Put the striped backgrounds on the rows instead of the cells (that just made more sense to me).

It doesn't put all of {{Navbox}}'s styles in the global css, because that would mess up other templates. —Ms2ger (talk) 18:48, 21 March 2008 (UTC)

Can we hold on for a moment? We are on the verge of implementing a complete new codebase for navbox (see Template talk:Navbox), complete with it's own set of CSS. That makes any disussion on the current CSS code a bit redundant. So I have boldly disabled the edit request for the time being. — Edokter • Talk • 18:54, 21 March 2008 (UTC)

Small text is small

The font-size property-value for .messagebox.small and .messagebox.small-talk is currently set to "85%", but on my browser (Safari), it's so miniscule that it's unreadable. This is because I suspect Safari is reducing the text twice -- once I suggest using the standard CSS relative keyword "smaller", or else use 90-94% where it's not so drastic a change. This would also conform to the other set font-size values currently in use on Common.css. Either that, or just remove the font sizing entirely and let that be a sub-style to this class. —Down10 ^TACO 06:50, 13 March 2008 (UTC)

Every browser has some issue with font sizes. IE for example has issues with 'small' and 'smaller'; they end up bigger the the rest when fontsize is changed. Can you point out an example, where you see the problem? I'll inverstigate if there is indeed a double reduction. — Edokter • Talk • 13:08, 13 March 2008 (UTC)

Horizontally scrollable table

Do we have a template for horizontally srcollable tables? Would be helpful on pages which have a table like this. --STTW (talk) 16:36, 15 March 2008 (UTC)

Ehm, why not simply changing the orientation of that table? (Rotate it 90 degrees.) Or simply keeping the rows as is but put each year block on top of each others? See? There are many simple and easy to read solutions that are better than using a horizontally scrolling table.

--David Göthberg (talk) 17:02, 15 March 2008 (UTC)

Yes vertical table is better, would ask the table contributor to do something about it. --STTW (talk) 17:13, 15 March 2008 (UTC)

I usually use style="overflow:scroll" on long tables. —Remember the dot ^(talk) 18:08, 15 March 2008 (UTC)

That works (in combination with a div). — Edokter • Talk • 18:13, 15 March 2008 (UTC)

That only works on some web browsers, creates havoc on other...

--David Göthberg (talk) 19:42, 15 March 2008 (UTC)

Can you be more specific? I have never had a problem with style="overflow:scroll" on any browser. —Remember the dot ^(talk) 20:43, 15 March 2008 (UTC)

I have tried on linux firefox and it works. Thanks for making the appropriate changes in the table. --STTW (talk) 12:34, 16 March 2008 (UTC)

Span and ID

Hello,

On wikipedia, I can go directly to any part of a page via <span id="SomeLocation" /> (like WP:NOT#STATS), however on the wikis I adminster, this syntax does not work. (I actually see the actual text, brackets and everything). Is there something I need to change on my wiki's Common.css file??

Thank you. Timneu22 (talk) 23:37, 15 March 2008 (UTC)

As I understand it, certain HTML tags are only permitted when placed on a HTML whitelist in your configuration. — Edokter • Talk • 00:09, 16 March 2008 (UTC)

Can you expand on this? What do I need to do? Timneu22 (talk) 00:33, 16 March 2008 (UTC)

You'll need to change the MediaWiki software to make "span" an allowed tag (nothing to do with Common.css). See m:Help:HTML in wikitext for more information; either that, or the text somehow ended up in a <nowiki> tag. Gracenotes^T § 01:06, 16 March 2008 (UTC)

Mmmm. But I do have SPAN enabled. It works in other pages/templates. It just seems that specfically, span id="blah" isn't doing the trick. Timneu22 (talk) 01:26, 16 March 2008 (UTC)

OK, I have it figured out... but it doesn't make sense:

• <span id="SomeLocation" /> - doesn't work
• <span id="SomeLocation"></span> - does work.

This is a first for me... both of those mean the same thing! Oh well. Thanks for your help, everyone. Timneu22 (talk) 01:30, 16 March 2008 (UTC)

That is a bit unusual. The help page on Meta noted that there are different types of allowed tags, and <span> is included in the type that must be paired. Why the form <span id="foo"/> works on English Wikipedia and not on your wiki makes no sense to me, though. Gracenotes^T § 02:11, 16 March 2008 (UTC)

I believe you have to set $wgUseTidy to true. —Ms2ger (talk) 09:03, 16 March 2008 (UTC)

Space between paragraphs please (References)

The CSS seems to put very little space between paragraphs. Hardly visible. This makes some articles very hard to read. Suggest at least 1/2 extra line. The HTML default is not too bad.

The problem with paragraphs is worst when you have references. That is because the references slightly increase the line height. In this paragraph I have added some dummy references to demonstrate this point here and here. When you have lots of references in an article (as you should) it becomes very hard to see where paragraphs start.

Fiddling with my preferences is not the issue, I care about what the huge number of other readers will see. I would therefor urge that the default CSS be changed to increase the gap slightly. Note how the previous paragraph has been split apart. Put a references on every other line and it becomes unreadable. 04:57, 19 March 2008 (UTC)Tuntable

Unfortunately, <P> is defind in main.css, so a dev must change it. Current code is:

P {
   MARGIN: 0.4em 0px 0.5em;
   LINE-HEIGHT: 1.5em
}

You could copy it to your monobook.css and increase the top margin (the 0.4em part) to your liking. — Edokter • Talk • 11:13, 19 March 2008 (UTC)

The style does not need to changed by a dev, and will not be changed by a dev. Monobook is a stable style that we aren't going to go randomly fiddling with. You can override it on this page (or in MediaWiki:Monobook.css), that's the whole point of "cascading". (By the way, standards specify that XHTML element names are case-sensitive, so that should be "p", not "P". The property names are case-insensitive, but having them caps is kind of ugly.) —Simetrical (talk • contribs) 15:38, 19 March 2008 (UTC)

That's how the IE Dev toolbar shows it to me... don't know if it is actually uppercase. — Edokter • Talk • 16:57, 19 March 2008 (UTC)

It isn't. That's just IE's normalization. Also, the issue with sub- and superscript increasing the lineheight is being discussed above. —Ms2ger (talk) 18:58, 19 March 2008 (UTC)

If the IE dev toolbar is uppercasing XHTML element names, in CSS or otherwise, the IE dev toolbar is wrong. —Simetrical (talk • contribs) 15:01, 20 March 2008 (UTC)

• There is obviously a problem. Have a look at my test paragraph above. Or have a look at an article with lots of references, such as Sydney Hilton bombing -- it really looks bad.

• The last thing that we want is each page to have its own CSS, this is a global problem.

• A Global change needs to be considered very carefully. But that does not mean that it should not be considered at all. Otherwise problems can never be fixed.

• I'm not sure where in the cascade the change should be made, that is secondary. Just not per page.

• I'd suggest increasing it slowly, to gather feedback and check things don't break badly. Eg. 1.5 to 1.6 to 1.7. 1.7 is probably enough.

• Might also think about the sup/sub, reduced the amount of raising slightly.

01:17, 20 March 2008 (UTC)Tuntable

I took a look at Sydney Hilton bombing and at first I thought: "What is Tuntable complaining about? It looks great." Then I realised that it might look okay to me since I use 800x600 in screen resolution (I got sensitive eyes) so I turned it up to the more common 1024x768, and then it looked terrible just like Tuntable says. So I agree with Tuntable, we need to increase the height of the paragraph breaks.

But note, increasing it slowly is not really an option, since the CSS pages here at Wikipedia is set to a cache time of 30 days. So it takes 30 days before all users see the change.

By the way, why isn't your signature a link to your user page or talk page Tuntable? You really should fix that.

--David Göthberg (talk) 03:17, 20 March 2008 (UTC)

I honestly don't see much of a problem here. It looks okay to me. —Simetrical (talk • contribs) 14:59, 20 March 2008 (UTC)

See the unresolved thread above, #line-spacing with sub & sup, including the problem-demonstration image Image:Wikipedia-Gibson-article-screenshot-supscript-problem.png (that's a single paragraph in my browser) for discussion of the references superscript Leading problem. -- Quiddity (talk) 17:58, 20 March 2008 (UTC)

MZMcBride has updated the code to include sup, sub {line-height: 0;}. That fixes the superscript-ref problem for me (in Firefox/Opera, in Linux). Everyone else? -- Quiddity (talk) 19:21, 21 March 2008 (UTC)

I see no noticable differences in articles. However I do see plenty of broken message boxes now that use <sup>, obsfucating half it's content. Example: {{GA}} (static link, now fixed). — Edokter • Talk • 20:49, 21 March 2008 (UTC)

Oop. Forgot to leave a note here. : - ) --MZMcBride (talk) 21:23, 21 March 2008 (UTC)

Just to clarify. This code that was added does not do anything on IE (at least IE6), it seems to be fully ignored. There is currently no CSS that works "perfect" for IE. There is some code we could add by using some IE specific javascript and that would "help", but it would break when there are sup's of sup's. Therefore it does not seem worth the trouble. I guess we could increase the lineheight for paragraphs to accommodate the IE users, but I'm not a big supporter of that idea. I have no idea why GA was using "sub" and I'm surprised that the issue wasn't visible before.... which browser were you using Edokter, IE6 or IE7 ? I guess it behaves differently due to the custom CSS that is set on messageboxes. --TheDJ (talk • contribs) 00:07, 22 March 2008 (UTC)

I use IE6, and I noticed GA suddenly had a chunck missing due to (ab)using non-embedded <sup> tags; ie. it didn't have any non-zero height elements before and after it, making the enrire line zero-height. This is not due to custom template CSS, just how line-height is supposed to work; containers like tables and divs ignore the actual height. I don't know how many other templates may be using this construction, but I am tempted to change it to 1em as opposed to the default 1.5em, and the now hardcoded 0em. — Edokter • Talk • 00:59, 22 March 2008 (UTC)

Frankly, I don't have any concern for those who are using bad HTML to accomplish what they want to accomplish. That instance of <sup> should have used <small>, and we shouldn't be encouraging people to use the wrong tag. This exact same view is taken with respect to other aspects of the site such as the parser -- that is, there's no guarantee that badly-written HTML (e.g., in user signatures) that works one day is guaranteed to work the next. Unless there is a legitimate reason to revert other than "it may 'break' a few templates," the addition should stay. Cheers. --MZMcBride (talk) 02:55, 22 March 2008 (UTC)

I found another problem caused by the zero line-height; all inline templates using {{fix}}, such as {{citation needed}}, as well as the citation themselves, overlap the next line of text if it wraps at the end of the line. MZMcBride's' "fix" is causing more trouble then it's worth. As the standard line-height is 1.5em, I propose we set it to 1em for <sup> and <sub>; that should (partially) fix these overlaps, while still have the intended effect of fixing spacing issues caused by citations. — Edokter • Talk • 18:02, 22 March 2008 (UTC)

Perhaps this is a browser-related thing? 'Cause I can't see this effect anywhere using Firefox. Can you upload a screenshot? --MZMcBride (talk) 18:43, 22 March 2008 (UTC)

Yes, it happens on IE only; that doesn't make it less of a problem. I'll make a screenshot when I get home. — Edokter • Talk • 19:11, 22 March 2008 (UTC)

I'd love to see a screenshot, cause I have trouble understanding what you are describing. It sounds like a text wrapping issue with line-height: 0 ? I'm not directly a fan of setting 1em. It would still increase the line-height of the actual line in case of sup/sub on at least Safari and Firefox if I remember correctly. If this issue you are seeing with sub/sup really is a blocker for IE, than I suggest we remove it, and add the CSS by javascript after doing a user-agent check. --TheDJ (talk • contribs) 20:42, 22 March 2008 (UTC)

break

thumb|Screenshot of IE6 Here's the screenshot. You may notice the spacing between the paragraphs is not altered because the line-height of the "original research" is set to zero, do IE won't account for it's presence between the paragraphs. This only happens when any such tag occupies a line by itself; as soon as something with non-zero line height shares the same line, everything is OK. Also Firefox does not show this problem because it doesn't allow a line break at that exact point before the tag (not even if there is a space).

Now, I can see why Mz set the sup/sub lineheight to zero; to make browsers think there is nothing raising above the line, but as you see it has it's side effects. However, if setting it to 1em has the same effect as 0em in non-IE browsers, I'd prefer that. — Edokter • Talk • 22:56, 22 March 2008 (UTC)

The ref sups all include class="reference". Can't we just use that to limit it? -- Quiddity (talk) 23:58, 22 March 2008 (UTC)

Well that would be less invasive of course. However, wouldn't you still have the same problem in that case if someone put a ref on a separate line by accident ? I have no idea what 1em does on Opera, and also no clue what it does with multiple levels of sup/sup. I'm not sure if I have the time to test it either this weekend. --TheDJ (talk • contribs) 01:26, 23 March 2008 (UTC)

Per my testing with this test text there seem to be no noticable differences between lineheight 0 and 1em on Safari 2, Safari 3, Firefox 2 and Opera 9. So if 1em helps IE, then I think that will be fine. --TheDJ (talk • contribs) 01:42, 23 March 2008 (UTC)

Done. All: Please report any issues. Cheers. --MZMcBride (talk) 01:44, 23 March 2008 (UTC)