MediaWiki talk:Common.css/Archive 4
 | 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 2 | Archive 3 | Archive 4 | Archive 5 | Archive 6 | → | Archive 10 |
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)
- 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)
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)
- 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:
- (in English) All pages with titles beginning with Jonathan
- (in French) 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)
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 xyzxyzπ. 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 xyzxyzπ.
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 xy.
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 xy.
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: xyzxyzπ. 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
- we javascript the addition fo add line-height: 0; for the various browsers in common.js
- 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)
- 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
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 xyzxyzπ. 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. xy
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— Edokter • Talk • 01:15, 25 February 2008 (UTC).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.- 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)
- 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)
/* 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)
- Just a few comments:
- (
navbox.th):background-colorandbackgroundare 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-childshould be fine in Safari (WebKit), see Comparison of layout engines (CSS). However, since:notis not supported by both IE and Opera, it cannot be used in Common.css;:first-childis 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:notpart. —AlexSm 15:01, 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)
- 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:
- Ensure there isn't a wide gap between lines when groupnames are wrapped;
- 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 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 tdandtr.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;
}
}
|
|
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)
- I usually use style="overflow:scroll" on long tables. —Remember the dot (talk) 18:08, 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)
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)
- 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. GracenotesT § 01:06, 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. GracenotesT § 02:11, 16 March 2008 (UTC)
- I believe you have to set $wgUseTidy to true. —Ms2ger (talk) 09:03, 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. GracenotesT § 02:11, 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[1] and here[2]. 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.[3] 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)
- 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)
- 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)
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)
- 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
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)
Template:*mp was designed to fix a Firefox peculiarity with <li> and content boxes. I've put the change into Common.css to make the template obsolete. Let me know if there are any issues. --MZMcBride (talk) 19:57, 27 March 2008 (UTC)
- It makes Special:UserLogin rather funky. Seems to happen when the LI are indented rightwards by a left floating object. The numbers and dots in this example are inside the floating div:
this is some random text
this is some random text
this is some random text
this is some random text
- this is a list item
- this is a list item
- this is a list item
- this is a list item
- this is a list item
- this is a list item
- There's a reason it's not the default on Firefox... See the original discussion for that template (Template talk:*mp#Purpose), where I note: As you can see there, using content-box with a left float can make the bullet be placed to the left of the image, which is probably why margin-box is the default. That shouldn't be a problem with a right float, unless you start worrying about things like bidirectionality. That template was created to solve that problem on the specific layout of the main page (thus the "mp" in its name), where it causes no problem. --cesarb (talk) 11:39, 10 April 2008 (UTC)
- Hmm. Seems like a pretty rare testcase. I'd be more inclined to fix the (few?) instances of breakage and get rid of Template:*mp, but I'll take your word for it if you feel it would be better to not include the code. Cheers. --MZMcBride (talk) 19:27, 10 April 2008 (UTC)
{{editprotected}}
I recently re-wrote the {{Navbox}} internal code to give a lot more flexibility to users, and to put the styles in CSS. The new code is located at User:CapitalR/Navbox, and the test page and explanation of the new features can be found at User:CapitalR/Navbox/test (the CSS is slightly different for the test page; please use the CSS listed on the test page for testing, NOT the CSS below on this talk page; the only difference is that the test page uses "navbox2" instead of "navbox" as the table style name to avoid a conflict with the existing "navbox" styles).
I'm requesting that the current CSS for the "navbox" class be completely replaced by the following CSS:
table.navbox { /* navbox container style */
border:1px solid #aaa;
width:100%;
margin:auto;
clear:both;
font-size:88%;
text-align:center;
padding:2px;
}
table.navbox + table.navbox {
margin-top:-1px; /* single pixel border between adjacent navboxes (doesn't work for IE6, but that's okay) */
}
.navbox-title, .navbox-abovebelow, table.navbox th {
text-align:center; /* title and above/below styles */
padding-left:1em;
padding-right:1em;
}
.navbox-group { /* group style */
white-space:nowrap;
text-align:right;
font-weight:bold;
padding-left:1em;
padding-right:1em;
}
.navbox, .navbox-subgroup {
background:#fdfdfd; /* Background color */
}
.navbox-title, table.navbox th {
background:#ccccff; /* Level 1 color */
}
.navbox-abovebelow, .navbox-group, .navbox-subgroup .navbox-title {
background:#ddddff; /* Level 2 color */
}
.navbox-subgroup .navbox-group, .navbox-subgroup .navbox-abovebelow {
background:#e6e6ff; /* Level 3 color */
}
.navbox-even {
background:#f7f7f7; /* Even row striping */
}
.navbox-odd {
background:transparent; /* Odd row striping */
}
@media print {
.navbox {
display: none;
}
}
This CSS should be mostly backward-compatible with the old code. The only real difference is that the margin of the navbox table is being changed to "margin:auto"; however, based on my tests from the latest database dump, very few, if any, pages will be affected by this change (and if they are, we can quickly fix them). Other than that, the difference should not be significantly noticeable to users.
If this CSS is added, then in about a week I'll see to it that the {{Navbox}} code is updated. I appreciate as many people as possible testing out the new Navbox design, and will be happy to hear all comments and suggestions. Thanks, --CapitalR (talk) 22:56, 31 March 2008 (UTC)
- Since this might seem like a big change and most people here might not know what this is about: CapitalR is the one who made the current navboxes and cleaned up the mess with all the old navboxes last year. His work is usually excellent and last time I checked the code for the new navboxes they seemed like a big improvement over the current ones. Thus I concur with this new CSS code.
- And a second note: Common.css is set to a 31 day caching time. So it might be advisable to wait 31 days before changing to the new navbox code after this new CSS code has been added here. Or you will be flooded with questions like: "Why is the navboxes broken?". We did get that a lot when we deployed the {{ambox}}. But I know, it is frustrating to have to wait 31 days. They really should set the caching time down to say 1 day or at least not higher than 7 days.
- --David Göthberg (talk) 08:13, 1 April 2008 (UTC)
Screen reader hints
{{editprotected}}
It would be useful to have hints for screen readers which could be hidden from normal view.
.screen-reader-only {
display: none;
}
@media aural {
.screen-reader-only {
display: block !important;
}
.no-screen-reader {
display: none !important;
}
}
For example, a table like the following would read as something insane:
| Series 1 | Series 2 | Series 3 | Series 4 | ||
|---|---|---|---|---|---|
| Aunt Agatha | Mary Wimbush | Elizabeth Spriggs | |||
| Madeline Bassett | Francesca Folan | Diana Blackburn | Elizabeth Morton | ||
| Sir Watkyn Bassett | John Woodnutt | ||||
but with some extra hints could display as the following in screen readers:
| Aunt Agatha | Mary Wimbush series 1, 2 and 3 | Elizabeth Spriggs series 4 | |||
|---|---|---|---|---|---|
| Madeline Bassett | Francesca Folan series 1 | Diana Blackburn series 2 | Elizabeth Morton series 3 and 4 | ||
| Sir Watkyn Bassett | John Woodnutt series 1 - 4 | ||||
--h2g2bob (talk) 23:06, 6 April 2008 (UTC)
Not done Sounds like a great idea, but this is Common.css we're talking about here. Come back after exhaustive testing on a variety of browsers and skins, and the support of other .css coders. :D Happy‑melon 10:44, 7 April 2008 (UTC)- This might encounter some of the same problems as Wikipedia:HiddenStructure. GracenotesT § 15:39, 7 April 2008 (UTC)
Tutorial?
Is there a tutorial anywhere on MediaWiki:Common.css? Trav (talk) 19:10, 7 April 2008 (UTC)
IPA fonts
{{editprotected}}
Hi, please edit:
.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;
}
the above to the following:
.IPA {
font-family: "Charis SIL", "Doulos SIL", Gentium, GentiumAlt, "DejaVu Sans", Code2000, "TITUS Cyberbit Basic", "Arial Unicode MS", "Lucida Sans Unicode", "Chrysanthi Unicode";
font-family /**/:inherit;
}
This has been discussed at Template talk:IPA without any significant opposition. All suggestions have been incorporated, AFAIK. The best and more accessible fonts have been moved to the front, fonts bundled with Windows have been moved to the back, and minor fonts have been moved to the back as well. Fonts that are not readily available might have been dropped. --Kjoonlee 21:11, 13 April 2008 (UTC)
CSS namespace detection
We have different colour standards for message boxes that go on different kinds of pages. However, some boxes are used on several kinds of pages. Thus I have been working with namespace detection so that a box can adapt and show the right colours on each type of page.
First I came up with the template {{main talk other}} which works well. But now I have discovered that we can also do such detection in CSS only, which in some cases might be even better. But I am still pondering exactly how and when we could best use CSS namespace detection.
Anyway, I have coded up an example of CSS namespace detection so that others can have a look.
--David Göthberg (talk) 00:25, 19 April 2008 (UTC)
Ambox-speedy class
Just in case anyone wonder why I added this code today:
table.ambox-speedy {
border-left: 10px solid #b22222; /* Red */
background: #fee; /* Pink */
}
It is the exact colours listed for "speedy" at Wikipedia:Article message boxes#Categories and colours and used in {{db-meta}} since a long time now. It has been discussed at Wikipedia talk:Article message boxes#Color coding revision. Some people want to skin those speedy delete templates to other colours so we need to make it a class.
--David Göthberg (talk) 02:07, 19 April 2008 (UTC)
New ambox version
I have made a new version of {{ambox}} that I intend to deploy within some days. {{ambox}} is one of the most widely transcluded templates on Wikipedia and is visible on lots of articles, so this is a rather big update. For more about the new version and to discuss it see Wikipedia talk:Article message boxes#New ambox version. (I am announcing this here since I know this page is watched by a lot of good template coders.)
--David Göthberg (talk) 06:41, 19 April 2008 (UTC)
Font size reduction
This recent change, reducing font sizes from 90% to 88%, has dramatically reduced the size of references as they appear in IE. Is this an important technical fix? If it is not, then I think it should be changed back, since references are virtually unreadable at the current font. Black Falcon (Talk) 20:37, 30 April 2008 (UTC)
- I think 'unreadable' is exaggerated. The change was made to make the fontsize appear consistently between browsers. The value 90% has a nack of floating between two font sizes due to the basic rendering difference between browsers, so it was changed to a 'safe' value of 88% which does render consistently. In that sense, yes, it was an important tecnhnical fix. In fact, you'd see no difference in Firefox, only in IE, which now render it in just 1pt smaller font. If it is deemed to small, it should be changed to 95%; the next 'safe' value. But let's wait for more input before doing that. — Edokter • Talk • 20:53, 30 April 2008 (UTC)
- While references can still be read, it is much harder to view them. I hope you'll pardon my ignorance on most things tech-related, but why is it important to have references render consistently between browsers? (For instance, were Mozilla users experiencing problems when the value was 90%?) Also, is this something that could be made a function of individual user preferences? Black Falcon (Talk) 23:04, 30 April 2008 (UTC)
- You could try adding something like this to your personal monobook, which should boost the font-size back up to 95% (don't forget to clear your cache after saving):
.references-small, .references-2column { font-size:95% !important; }
- Hope that helps. --CapitalR (talk) 23:22, 30 April 2008 (UTC)
- You could try adding something like this to your personal monobook, which should boost the font-size back up to 95% (don't forget to clear your cache after saving):
- (ec) The principle is that every HTML element should be rendered consistently between all browsers. And like I said, Mozilla users will not see any difference; this was primarely en IE fix. We can't put this kind of option in user preferences, but each user has a private monobook.css, where you can tweak each element to your liking by adding custom CSS. For instance, to increase the font size for references, put this code in your monobook.css:
.references-small { font-size: 95%;}- Hope that helps. — Edokter • Talk • 23:23, 30 April 2008 (UTC)
- Thank you for the help. I've copied the code into my monobook.css and the references render at their old size now. Thanks, Black Falcon (Talk) 00:33, 1 May 2008 (UTC)
- This is very hard for me to read. Sorry, we don't all have twenty-year-old eyes; please fix. SandyGeorgia (Talk) 23:27, 30 April 2008 (UTC)
- Then maybe we should not use '.references-small' in {{reflist}}... It wasn't even smaller in IE, so what would be the point for this class? — Edokter • Talk • 00:18, 1 May 2008 (UTC)
- All I know is it was fine before, and it's too small to read now. SandyGeorgia (Talk) 00:20, 1 May 2008 (UTC)
- Then put the code above in your monobook.css. — Edokter • Talk • 00:42, 1 May 2008 (UTC)
- Is that the answer we give our readers who don't have Wiki accounts ? SandyGeorgia (Talk) 02:06, 1 May 2008 (UTC)
- IE is still the most used browser, so maybe users of other browsers should put that code in their monobooks? The font is really too small to read on IE.--Crzycheetah 02:46, 1 May 2008 (UTC)
- Then put the code above in your monobook.css. — Edokter • Talk • 00:42, 1 May 2008 (UTC)
- All I know is it was fine before, and it's too small to read now. SandyGeorgia (Talk) 00:20, 1 May 2008 (UTC)
- Then maybe we should not use '.references-small' in {{reflist}}... It wasn't even smaller in IE, so what would be the point for this class? — Edokter • Talk • 00:18, 1 May 2008 (UTC)
- Given the complaints, it looks like this change should be reversed. Gimmetrow 03:26, 1 May 2008 (UTC)
- Given the consistency issues noted by Edokter, though, I'd think changing the percentage to 95% would be preferable to reverting to 90%. —Ilmari Karonen (talk) 03:47, 1 May 2008 (UTC)
- You've been around long enough - surely you remember the discussions about this? 90% was agreeable to the most people. Go much smaller and too many complained, go much larger and too many people hard-coded smaller text. Gimmetrow 04:28, 1 May 2008 (UTC)
- Given the consistency issues noted by Edokter, though, I'd think changing the percentage to 95% would be preferable to reverting to 90%. —Ilmari Karonen (talk) 03:47, 1 May 2008 (UTC)
- Given the complaints, it looks like this change should be reversed. Gimmetrow 03:26, 1 May 2008 (UTC)
I've reverted. SandyGeorgia, et al. are correct -- IE is widely used and if there are issues with rendering due to this change, it isn't reasonable to have IE users change their user skins. Perhaps the text should be larger, perhaps it should stay at 90%. Personally, I don't really care. But for the moment, if it's causing issues, we shall keep the status quo. --MZMcBride (talk) 04:56, 1 May 2008 (UTC)
- What 'issues' is it causing? And why did your revert all values, even those that didn't casue an issue (like .infobox.sisterproject and .infobox.geography)? I am slightly aggitated by your panic-reverts now. — Edokter • Talk • 11:12, 1 May 2008 (UTC)
- Hrm, a 'panic revert' would have been reverting immediately after the change due to possible issues. I reverted after talk page discussion indicated that there are actual, verifiable issues. And the "solution" to have every person who has issues change their personal skin isn't acceptable. A huge percentage of users view this site logged out (it's something like 90%). If three or four people saw the change already, found the appropriate talk page and change, and complained, it's generally an indication that when everyone else sees the change when the cache expires, it's going to be an even larger problem. I don't see anything that would cause a difference between the effect on references and the effect elsewhere (thus the full revert). If people are having issues, I didn't / don't see an issue with reverting and figuring out a different solution. --MZMcBride (talk) 13:15, 1 May 2008 (UTC)
- The effects "elsewhere" would have only the sisterproject box and top coordinates; reverting those had no basis. BTW, what browser do you use? If it is Mozilla based, you should know that the net effect is that IE would render everything *exactly* as you currently see it; the way it was supposed to be shown. Had you realized that, you would know there is not an "issue", just people complaining about the change. Had I changed it the other way, I'm sure a few Mozilla users would come here and complain the font is "too big". Had SandyGeorgia used Firefox, there would be no complaint.
- So, we should choose between 88% and 95%. 90% should be 'outlawed' due to it's inconsistent rendering, and be replaced with 'safe' values. Really, such an inconsistency would be unacceptable on any other webpage. I already tried to get a discussion going on MediaWiki talk:Monobook.css#Base font size dealing with the root cause of the problem, but there isn't much responses yet. As a result, I am have fixed several templates, and hadn't had any complaints so far. In any case, this should be resolved one way ot the other; it effects many editors building templates, always ending up in templated displaying not as intended in at least oine browser. — Edokter • Talk • 14:33, 1 May 2008 (UTC)
- Oh, I agree that if everyone just used Firefox, life would be much better. : - ) I do browser compatibility work occasionally and trying to get IE, Firefox, Safari, and Opera to all work makes you just want to use plain text. I'd probably favor 88%, but if the IE folks are having issues, I suppose we could use 95%. Really, it makes little difference to me. I just don't want a large number of people squinting and complaining. Perhaps a post to VP/T would garner more attention to the issue? Or, perhaps we can have a few IE users change their personal skins and do some testing before changing the global settings. Cheers. --MZMcBride (talk) 19:11, 1 May 2008 (UTC)
- I'd thought we were using 92% as a standard value, per {{FootnotesSmall}}? The only mediawiki archive discussions I could find were MediaWiki talk:Common.css/Archive 3#.references-small -> 92% and MediaWiki talk:Common.css/Archive 2#Please revert "resizing of footnotes by CSS", but there are probably more, scattered in the other namespaces.
- I keep coming across instances of unreadably small text, and was trying to find a WP:FONT or WP:TYPOG page without luck, last week. Both WikiProject Accessibility and WikiProject Usability are pretty quiet, but perhaps they could come up with a set of recommendations? We seem to use a mix of ems, %, and px, and I'm not sure if the overall plan is explained anywhere, or if there even is one? -- Quiddity (talk) 17:56, 1 May 2008 (UTC)
- Having now tested, I strongly prefer 95% (in firefox, ubuntu). It seems preferable to not deprecate our sources by making them so small and hard to read (though I realize the
.references-smallclass is used for a lot of things). (See also Template talk:Reflist#Multiple columns deemed bad.) -- Quiddity (talk) 19:47, 1 May 2008 (UTC)
- Revert to 90% or 95% please. The vast majority use IE like myself and the new tiny font for refs is unacceptable. If people knew where to complain, I'm sure you'd be getting many more complaints (this is a pretty obscure talk page for the average Wikipedian, after all). JGHowes talk - 05:21, 2 May 2008 (UTC)
- Revert to 90% or 95% - I find the callousness exhibited by User:Edokter toward the sight-impaired highly insulting. Regardless of his feelings towards IE, it's not his responsibility to force users to change browsers so they can read without squinting and getting headaches. Also, as non-registered users don't have the option of modifying their monobook, that solution is very limited, and since WP encourages unregistered users, this should be fixed with the greater number of users in mind. - BillCJ (talk) 05:37, 2 May 2008 (UTC)
- PS - One way around this would be to hard code the {{reflist}} size to 90 or 95% for now, bypassing the "small" code. - BillCJ (talk) 05:37, 2 May 2008 (UTC)
- This change was reverted quite a few hours ago. If you're still seeing the smaller font, try WP:BYPASS. --MZMcBride (talk) 10:24, 2 May 2008 (UTC)
- Maybe I didn't make myself clear enough; I'm not trying to get anyone to change browsers. If you were already using another browser, you would not see any difference. The elements I changed were designed to show in smaller font then the rest of the article. Otherwise, would would even be the point in using {{reflist}} and .references-small? Don't play on the person like that. — Edokter • Talk • 12:06, 2 May 2008 (UTC)
Abrupt changes
I really want to say that these sudden, unannounced, and wide-sweeping css changes are very disconcerting, as in the case again today with the altered diff colors. As with the ill-advised change in ref font sizes, no consideration to readibility seems to be given. These frequent reversions also do not reflect well on the team - must we now add a Ctrl-F5 to our routine every few hours or so, to keep up with the latest version?
Where fundamental changes in Wikipedia's appearance affecting every single editor are contemplated, it should be s.o.p. to:
- Consider experimenting with a test group before going live
- Inform the entire Wikipedia community of the proposal
- Poll before implementation
- Announce the changes in advance
I respectfully disagree. Its very simple, people won't notice these kinds of things before we shove it in their face. We can discuss all we want, wherever we want, but without a watchlist notice (which esp. in this case would be way over the top), 99% of the active editors still won't know these kinds of things. Both changes had good discussions, with good and sensible argumentations in favour of the changes, both have no serious effect on our "less experienced" editors. The first needed to be reverted because people just don't like change (we set out to fix an inconsistency that we considered to be unreasonable). The 2nd change was reverted because it had adverse affects on visual impaired readers, it happens. I would like to point out that most CSS changes that were actually important/dangerous are taken very seriously. sup/sub was analyzed, discussed and tested to death for over a year. IPA, navbox, ambox are heavily and widely tested before being changed. On the other hand, screenreader enhancements (which are VERY important in my opinion) were flat out denied, simply because we could not reliably predict and assess wether the advantages weighed against the negatives.
- there is a testgroup. Almost all changes are tested on FF 2, FF 3, Safari 3, IE7, IE6 and Opera. That is already a huge effort. Are you seriously suggesting we run every change by a person with a visual impairment, that understands CSS ? Don't get me mistaken, I think Edok and others here would love that, but I don't see that realistically coming to fruition. Likely such an editor is no longer part of wikipedia before he even gets a chance to report his first problem report (current rate of visual impairment bugs this serious, about 1 in 2 YEARS ??)
- it was on VP/T
- the poll was on VP/T
- it was announced on VP/T
- --TheDJ (talk • contribs) 22:06, 2 May 2008 (UTC)
- P.S. this may read like i'm bitter or something, i'm not. Of course it would be better to prevent every single occurrence of such an issue. I'm just being realistic. This is a best effort of a few people who have tremendous knowledge of CSS and Javascript. These people are however also not perfect. Mistakes will be made, they are part of life (lets remember all the admins that in the past hit the delete button on the mainpage, forcing the devs to remove the entire function from the mainpage)
- P.P.S. I'm not a big fan of the exact colours that were implemented, but I do support the basic idea of this change and I very much hope we can find a set of colours that will be less problematic for users, because for me it makes diffs a whole lot more readable and understandable. MaxSem jumped the gun a bit, but I can understand with the general (s)low response these sorts of suggestions are usually treated to. --TheDJ (talk • contribs) 22:21, 2 May 2008 (UTC)
- Thanks, DJ, for your thoughtful response and the information about the test group, of which I was unaware. Yes, there's no doubt that everyone has the best of intentions and is giving generously of their knowledge to the project. I realize it's not reasonable to expect that every change, no matter how minor a tweak, could or should have such a community-wide process for implementation. But, at the other end of the spectrum, the diff page is one of our main vandalism identification tools and does utilize colorization to highlight changes/deletes, etc., so for a major change like that I'd urge notice of the change and wider discussion. At a minimum, for those who are interested like myself but don't normally look at VP, a note on this talk page alerting us to the discussion at VP would be a good thing. That way, we can just keep this page on our watchlist. JGHowes talk - 22:50, 2 May 2008 (UTC)
Messagebox suggestion
Per this diff, I am suggesting a minor change to the CSS, we add messagebox-info as a CSS-class, using the same classes as talk, so that templates like the one in the aforementioned diff can use the brick colour.
Anyone think this might work?? Ta, --1qx (talk) 11:59, 11 May 2008 (UTC)
Ambox, imbox and cmbox
Below are CSS code that I intend to add/change in MediaWiki:Common.css tomorrow. The code validates in the W3C CSS validation service and I have tested the code in my own user space.
The two new message box meta-templates {{imbox}} and {{cmbox}} for category and image message boxes have been made and deployed, currently with hardcoded styles. The CSS code will make them skinnable.
Those boxes are based on {{ambox}}. While we worked with them we discovered some improvements we could do to the ambox CSS code. By removing "border-collapse: collapse;" and adding -1 pixel top and bottom margin to the CSS code for ambox we can make it so when stacked it only gets one single line between the boxes in all web browsers. If you compare the examples in the doc for {{ambox}} and {{cmbox}} you will see that ambox gets double lines between the boxes in some browsers. (As long as the code below has not been added to Commons.css that is.)
In the code below, the first four ambox classes have changes. And all the imbox and cmbox classes are brand new.
The reason I do not add "@media print, display: none;" to imbox and cmbox is that such message boxes are only used on image and category pages. And I think that when such pages are printed people want to get all the information on those pages, like the license notices.
/* Article message box styles */
table.ambox { /* 10% = Will not overlap with other elements */
margin: -1px 10%; /* -1px = Single border between stacked boxes in all browsers */
border: 1px solid #aaa;
border-left: 10px solid #1e90ff; /* Default "notice" blue */
background: #fbfbfb;
}
th.ambox-text, td.ambox-text { /* The message body cell(s) */
border: none;
padding: 0.25em 0.5em; /* 0.5em left/right */
width: 100%; /* Make all templates the same width regardless of text length */
}
td.ambox-image { /* The left image cell */
border: none;
padding: 2px 0 2px 0.5em; /* 0.5em left, 0px right */
text-align: center;
}
td.ambox-imageright { /* The right image cell */
border: none;
padding: 2px 0.5em 2px 0; /* 0px left, 0.5em right */
text-align: center;
}
table.ambox-notice {
border-left: 10px solid #1e90ff; /* Blue */
}
table.ambox-speedy {
border-left: 10px solid #b22222; /* Red */
background: #fee; /* Pink */
}
table.ambox-delete,
table.ambox-serious {
border-left: 10px solid #b22222; /* Red */
}
table.ambox-content {
border-left: 10px solid #f28500; /* Orange */
}
table.ambox-style {
border-left: 10px solid #f4c430; /* Yellow */
}
table.ambox-move,
table.ambox-merge {
border-left: 10px solid #9932cc; /* Purple */
}
table.ambox-protection {
border-left: 10px solid #bba; /* Gray-gold */
}
table.ambox.ambox-mini { /* Small floating box variant */
float: right;
clear: right;
margin: 0 0 0 1em;
width: 25%;
}
@media print { /* Do not print article message boxes */
.ambox {
display: none;
}
}
/* Image message box styles */
table.imbox {
margin: 4px 10%;
border-collapse: collapse;
border: 3px solid #1e90ff; /* Default "notice" blue */
background: #fbfbfb;
}
th.imbox-text, td.imbox-text { /* The message body cell(s) */
border: none;
padding: 0.25em 0.5em; /* 0.5em left/right */
width: 100%;
}
td.imbox-image { /* The left image cell */
border: none;
padding: 2px 0 2px 0.5em; /* 0.5em left, 0px right */
text-align: center;
}
td.imbox-imageright { /* The right image cell */
border: none;
padding: 2px 0.8em 2px 0; /* 0px left, 0.8em right */
text-align: center;
}
table.imbox-notice {
border: 3px solid #1e90ff; /* Blue */
}
table.imbox-speedy {
border: 3px solid #b22222; /* Red */
background: #fee; /* Pink */
}
table.imbox-delete {
border: 3px solid #b22222; /* Red */
}
table.imbox-content {
border: 3px solid #f28500; /* Orange */
}
table.imbox-style {
border: 3px solid #f4c430; /* Yellow */
}
table.imbox-move {
border: 3px solid #9932cc; /* Purple */
}
table.imbox-protection {
border: 3px solid #bba; /* Gray-gold */
}
table.imbox-license {
border: 3px solid #88a; /* Dark gray */
background: #f7f8ff; /* Light gray */
}
table.imbox-featured {
border: 3px solid #cba135; /* Brown-gold */
}
/* Category message box styles */
table.cmbox {
margin: -1px 10%;
border: 1px solid #aaa;
background: #DFE8FF; /* Default "notice" blue */
}
th.cmbox-text, td.cmbox-text { /* The message body cell(s) */
border: none;
padding: 0.25em 0.5em; /* 0.5em left/right */
width: 100%;
}
td.cmbox-image { /* The left image cell */
border: none;
padding: 2px 0 2px 0.5em; /* 0.5em left, 0px right */
text-align: center;
}
td.cmbox-imageright { /* The right image cell */
border: none;
padding: 2px 0.8em 2px 0; /* 0px left, 0.8em right */
text-align: center;
}
table.cmbox-notice {
background: #DFE8FF; /* Blue */
}
table.cmbox-speedy {
margin-top: 1px;
margin-bottom: 1px;
border: 4px solid #b22222; /* Red */
background: #FFDBDB; /* Pink */
}
table.cmbox-delete {
background: #FFDBDB; /* Red */
}
table.cmbox-content {
background: #FFE7CE; /* Orange */
}
table.cmbox-style {
background: #FFF9DB; /* Yellow */
}
table.cmbox-move {
background: #F1D0FF; /* Purple */
}
table.cmbox-protection {
background: #EFEFE1; /* Gray-gold */
}
--David Göthberg (talk) 01:06, 12 May 2008 (UTC)
- Can somebody tell me why we can't just use the ambox class on all of them and then skin them dependent on the namespace class? — Dispenser 01:23, 12 May 2008 (UTC)
- Right, technically we could do that. But it has several human drawbacks.
- Most message boxes are only intended to be used in some specific namespace, like for instance article space. If they adapt their looks automatically it will not be possible to see from their looks on what namespace they are supposed to be used. (Although we now have other means to inform when a box is used in the wrong namespace.)
- Then all those message boxes would have their "other spaces skin" or "template space skin" when they are seen on their template pages. So anyone looking at them there or coding such a box would not see how for instance an article message box is going to look in an article. And there is no simple way to be able to demonstrate the different looks a box will have in different namespaces when shown in the green /doc box on the template page. (Well, I think I know one way, but it seems to be really nasty CSS coding. But I am working on it to see if I can improve it.)
- But for message boxes that are supposed to be used in several namespaces it would be very efficient. But there are not that many such message boxes. And we have other ways of handling them.
- Ouch, I went looking at my own demonstration of such CSS namespace detection here: Template talk:Main talk other#CSS namespace detection. It seems if we need to detect talk space then we cause much more CSS code than when we instead detect namespace by using parserfunctions like those used in {{main talk other}}. If we are not going to detect talk space but just treat it as "other spaces" then the amount of CSS is almost exactly the same as if we do not use CSS namespace detection. So CSS namespace detection do not save us any CSS code.
- --David Göthberg (talk) 01:47, 12 May 2008 (UTC)
- MZMcBride: Ah yes, that perhaps increases readability somewhat. Fixed. But didn't save any bytes since there were aligned comments on those code lines. And since I am such a geek: 0 °F != 0 °C. :))
- Dispenser: Thanks for bringing up CSS based namespace detection. It made me take a look at it again and I think I just "cracked" it. That is, I have devised a method to use it nicely with message boxes. I just tested it and it worked fine. But note that it doesn't save any CSS code and the code above will still be needed, but my method also doesn't cost much extra CSS code. But most message boxes should not use the method, only those that need to be used in several namespaces. I'll come back with a full example when I get the time.
- --David Göthberg (talk) 03:43, 12 May 2008 (UTC)
Done. I have now added the CSS code above to MediaWiki:Common.css. --David Göthberg (talk) 01:39, 13 May 2008 (UTC)
Metadata class in mboxes
- This discussion was copied from Template talk:Imbox. I (David) edited RockMFR's comment slightly so it works on this page.
I was the one who added the metadata class to Template:Ambox, which has subsequently been added to {{imbox}}. This is causing templates using Imbox to not be displayed when printing, due to .metadata being noprinted in MediaWiki:Monobook.css. This class should be removed the next time Imbox is updated, as we definitely want licensing tags to be printed. --- RockMFR 21:14, 26 May 2008 (UTC)
- Oh, right you are. Thanks for pointing that out. (With many eyeballs all bugs are shallow. :)) I fixed it in {{cmbox}} immediately since that template is "only" used on 14,000 pages and I will fix it in {{imbox}} in the next revision that will be done today or in some day.
- I checked around again how this works since I have forgotten and since we don't want {{ambox}} to print. And I found some oddities. You or others here might know the answers:
- Why does the .metadata class only have display:none in MediaWiki:Monobook.css? Shouldn't the .metadata display:none apply to all skins and thus be added to MediaWiki:Common.css instead?
- If we move the .metadata display:none to Common.css, then we don't need the .ambox display:none in Common.css anymore, right?
- Why don't we use the class ".noprint" instead? It would be clearer in the code and would have avoided the mistake I did with imbox and cmbox. Is it beacuse ".metadata" is to be possible to mark away separately for screen readers for blind people?
- --David Göthberg (talk) 02:34, 27 May 2008 (UTC)
- I can't really remember the exact reason I even put .metadata in Template:Ambox to begin with (my edit summary doesn't make much sense now). However, yes, I believe the .metadata display:none rule and others should indeed be in Common.css, not Monobook.css. As for using .noprint in Template:Ambox - yeah, that should probably be done. --- RockMFR 02:39, 27 May 2008 (UTC)
- I always thought the metadata class was just for tagging. And as such it wouldn't have any CSS as the data could be used for anything anything, like {{wrongtitle}}. We should deprecate the use to avoid confusion. — Dispenser 04:06, 27 May 2008 (UTC)
- Yes, that is how I remember the old use of ".metadata", just for tagging. As a service to people with small screens (handhelds) and blind people so they can choose to not see/hear the metadata.
- I checked around and tested. ".noprint" seems to work in all skins. So yes, I will add ".noprint" in ambox, but perhaps also leave the ".metadata" tag since article message boxes are metadata about the articles and some people might want to not see or hear them.
- Since ".metadata" currently prevents printing in some skins and the image page message boxes and the category message boxes aren't really metadata but part of the text on those pages I will not use the ".metadata" class in {{imbox}} and {{cmbox}}.
- Thanks guys. Seems the mbox cases now are settled.
- But I think this needs to be discussed further since it seems the ".metadata display:none" code needs to be removed from Monobook.css and not added anywhere else. But that probably needs a bot search to see what templates use the class so the cases that use it for noprinting can be changed to using ".noprint" instead.
- Just a brainstorming idea: Perhaps we should instead have a class named ".nohear". That would perhaps be clearer? I think it would be pretty clear that ".nohear" could be used also for handhelds who want to skip all less necessary info. I wonder if there is any standard for this? I mean, screen readers perhaps already per default are set to not read some classes, then we should use them instead.
- --David Göthberg (talk) 07:18, 27 May 2008 (UTC)
I have been thinking more about this. Consider this case: When an ambox or navbox is shown on an article page it should not be printed. But if a talk page is printed then any ambox or navbox discussed and shown there should be printed. This seems to be true for many other things. That is, articles should be printed cleanly, but all other types of pages should probably be printed with everything we see on them. Can anyone think of any case where not everything on a "Wikipedia:", "Talk:" or "Image:" page should be printed?
Thus I think we should add namespace detection to most of the "display:none" codes in MediaWiki:Common.css and MediaWiki:Monobook.css. That is add ".ns-0". For instance in Monobook.css change this:
@media print {
/* Do not print edit link in templates using Template:Ed
Do not print certain classes that shouldn't appear on paper */
.editlink, .noprint, .metadata, .dablink { display: none }
#content { background: #fff; } /* white background on print */
}
To this:
@media print {
/* When on article pages:
Do not print edit link in templates using Template:Ed.
Do not print certain classes that shouldn't appear on paper. */
.ns-0 .editlink, .ns-0 .noprint, .ns-0 .metadata, .ns-0 .dablink {
display: none
}
#content { background: #fff; } /* White background on print. */
}
I just thought of this and haven't ran any tests yet. I think this needs some consideration and discussion. But I throw it out here to get comments from all you CSS experts here. #:))
Note that common/commonPrint.css sets noprint to "display:none" so I don't know if we can override that in Common.css or Monobook.css. But at least it seems we can control "editlink", "metadata" and "dablink". And we can control the "display:none" for navbox and some others in Common.css.
And as stated above we need to discuss what the "metadata" class really is for.
--David Göthberg (talk) 14:31, 1 June 2008 (UTC)
- There's a fairly lengthy discussion at MediaWiki talk:Common.css/Archive 3#metadata about it. --- RockMFR 00:06, 11 June 2008 (UTC)
Anti-spam check problem with BlackBerrys
Hi, This may not be related to Common.css, if not please point me in the right direction. Since last week, an anti-spam check box (marked "Do not fill this in!") has been added to the edit function. The problem is that this results in completely garbled screen display/freeze on BlackBerrys, making them unusable now for Wikipedia edits/Talk page replies. JGHowes talk - 13:37, 1 June 2008 (UTC)
- I see no such check-box. Where exactly do you see it?
- --David Göthberg (talk) 17:34, 1 June 2008 (UTC)
- It's in the html source code, using this Talk page as an example:
- <form id="editform" name="editform" method="post" action="/w/index.php?title=MediaWiki_talk:Common.css&action=submit" enctype="multipart/form-data"><div id="antispam-containter" style="display: none;">
<label for="wpAntispam">Anti-spam check.
Do <b>NOT</b> fill this in!</label> <input type="text" name="wpAntispam" id="wpAntispam" value="" />
</div>
- <form id="editform" name="editform" method="post" action="/w/index.php?title=MediaWiki_talk:Common.css&action=submit" enctype="multipart/form-data"><div id="antispam-containter" style="display: none;">
<label for="wpAntispam">Anti-spam check.
Do <b>NOT</b> fill this in!</label> <input type="text" name="wpAntispam" id="wpAntispam" value="" />
</div>
- On the edit screen (when using the BlackBerry's browser), this produces just the anti-spam box and legend mentioned above, and the rest of the screen is gibberish.JGHowes talk - 18:17, 1 June 2008 (UTC)
- It's in the html source code, using this Talk page as an example:
- Ah, I see. Odd that the BlackBerrys freeze, that code looks very clean. (Nifty trick to tell human and bot apart. Humans should not see that field but some spam bots simply fill in all fields.) But anyway, this has nothing to do with Common.css. This is something the MediaWiki developers have to handle. Seems the BlackBerrys have a buggy web browser. So the right place (or at least the next place) to bring this up is at Wikipedia:Village pump (technical).
- --David Göthberg (talk) 18:39, 1 June 2008 (UTC)
Perhaps the blackberry doesn't understand div's in forms ? and especially not divs that have display:none set ? I say one more reason to switch to the iPhone :D --TheDJ (talk • contribs) 18:41, 1 June 2008 (UTC)
- According to the developers this anti spam measure was introduced on may 22nd. I guess the blackberry just doesn't understand proper HTML/CSS. Opera mini should work properly with this code. --TheDJ (talk • contribs) 18:48, 1 June 2008 (UTC)