Wikipedia

MediaWiki talk:Common.css/Archive 7

< MediaWiki talk:Common.css
Latest comment: 15 years ago by Gadget850 in topic Printing issues with IE7
Archive 1 ← Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10

Something's changed...

Latest comment: 15 years ago4 comments2 people in discussion

...and it's not good, but I can't pinpoint the source. Firstly, in IE6, scrolling has taken a really bad performance hit, and I see the header lines bleeding through the infoboxes. These two phenomena may be related, but again, I can't pinpoint it. — Edokter • Talk • 00:48, 7 November 2008 (UTC)

(edit) It happens on articles, talkpages and my watchlist, but not on history pages. — Edokter • Talk • 00:50, 7 November 2008 (UTC)
Well this changed, but if that makes IE6 performance drop, than it does not deserve to be fixed :D Then again, i see no reason not to add an if( isIE6 ) to that case to prevent such behavior. --TheDJ (talk • contribs) 02:48, 7 November 2008 (UTC)
That is the culprit! It triggers on any action like scrolling. Please add that ie6 check; i prefer a misplaced icon over pages that scroll like hell. — Edokter • Talk • 22:46, 7 November 2008 (UTC)

cmbox-move background

Latest comment: 15 years ago32 comments5 people in discussion

What's going on with this? We've had four different styles in the past few hours, all with no discussion. What's broken and why, and what should we do to fix it? Once we have the issues on the table, we can work out something that works for everyone before mucking around with the colours for the entire site. Happy‑melon 18:50, 3 December 2008 (UTC)

Don't know. Four times? I just noticed the change here, checked the result at {{Cmbox}} and saw it looked horrible and changed it to a color that matched the others in luminance. In any case, this deserves more discussion in Template talk:Cmbox. — Edokter • Talk • 19:01, 3 December 2008 (UTC)
How does my second attempt look to you? For reference:
—David Levy 19:07, 3 December 2008 (UTC)
In response to your question, I think that the shade proposed is too close to the blue of the "notice" type immediately above, at least on my monitor. Happy‑melon 19:35, 3 December 2008 (UTC)
Fine, then let's discuss the matter further. I only object to the idea of reverting without any evidence of dissatisfaction in the actual difference. —David Levy 20:01, 3 December 2008 (UTC)
I like #E1D8FF, David, even better then my attempt. It doesn't look too close to the blue box on my monitor (and the two are rarely, if ever, displayed together). — Edokter • Talk • 19:49, 3 December 2008 (UTC)
Thanks, Edokter. It honestly was an attempt to work forward in collaboration with you. —David Levy 20:01, 3 December 2008 (UTC)
Unless there are objections, shall we make the change then? — Edokter • Talk • 12:42, 4 December 2008 (UTC)
If you don't count my above as an objection :D. I would personally prefer #E6D8FF:
It's a subtle change, but makes a discernable difference on my monitor. Thoughts? Happy‑melon 14:30, 4 December 2008 (UTC)
The difference is subtle, but noticable. However the chrominance relative to the other box types is too high, and it does creep towards the pink David was trying to get rid off. If you really see that much difference, your monitor (or video card) is either set oversaturated and needs adjusting, or your monitor is dying. — Edokter • Talk • 14:54, 4 December 2008 (UTC)
I think (hope anyway) that it's still far enough away from the pink; as I said the E1 looks to me to be too far out the other side into blue. I'm not very familiar with technical colour descriptions, maybe you can explain what you mean vis chrominance etc. I think that some more opinions would be helpful here. Happy‑melon 16:54, 4 December 2008 (UTC)
(←) Chrominance is the level of color relative to gray, ie. where grey is zero, bright red is full chrominance, while pink-red sits somewhere in between. Your version adds too much red, increasing the overal "color-level" (chrominance) and turning it towards pink. What suprises me is that you think the blue and purple are to close. That means the yellow and orange (content and style) must be even closer for you. There is also a difference in overall brightness (which shouldn't be too far apart), so there is still a considerable difference. I still say #E1D8FF, as shown in David's example, fits the overall cmbox pallette best. — Edokter • Talk • 17:11, 4 December 2008 (UTC)
After some further testing, and comparing these with the current original color(s), I think #E6D8FF isn't so bad after all. The difference isn't that big anyway. I'll put it in. — Edokter • Talk • 17:44, 4 December 2008 (UTC)
It's an improvement over #F1D0FF, though I do prefer #E1D8FF.
Perhaps #E4D8FF (exactly midway between #E1D8FF and #E6D8FF) would be an acceptable compromise.
—David Levy 21:13, 4 December 2008 (UTC)
Since it hardly makes any difference, I wouldn't have a problem with it. Happy Melon however... :) — Edokter • Talk • 22:04, 4 December 2008 (UTC)
Yeah, let's see what Happy-melon thinks. We also could discuss adjusting the notice color to be slightly more blue. (It currently leans a bit toward grey.) Perhaps that would help to make it stand out more from the purple color on Happy-melon's display. —David Levy 22:12, 4 December 2008 (UTC)
It is slightly pale, isn't it. OK, how about this? — Edokter • Talk • 00:14, 5 December 2008 (UTC)
I like the #D8E8FF color very much, and I'd like to see it implemented regardless of which which "move" color we end up using. I've added #E1D8FF to the above comparison, as it's possible that the contrast between it and #D8E8FF is enough to alleviate Happy-melon's concern. —David Levy 00:39, 5 December 2008 (UTC)
Can't see how it wouldn't... Though I find myself prefering E4 over E1 now. Melon, are you Happy? — Edokter • Talk • 00:50, 5 December 2008 (UTC)
I prefer E1, as it leans slightly less toward pink.
In any case, I left a note on Happy-melon's talk page. —David Levy 01:02, 5 December 2008 (UTC)
That does indeed make a difference; the distinction is clearer now. It's amazing how much effect such a small change can have... it's a nicer shade of blue too :D. I could support either purple with the new blue; I think I fractionally prefer the E4, but there's very little in it. Nice work, consider me a Happy‑melon 08:53, 5 December 2008 (UTC)
(←)OK, I've gone ahead and changed to #D8E8FF and :#E4D8FF respectively, mainly as a compromise between E1 end E6, and because me and HM like it. Hope everyone's happy. — Edokter • Talk • 19:35, 5 December 2008 (UTC)
I am.  :-) —David Levy 21:49, 5 December 2008 (UTC)
1. To what "four different styles" are you referring?
2. The issue is that the color is supposed to be purple but appears as pink on many displays. As I don't recall the specific hexadecimal selection being discussed in the first place, I saw no reason to not simply attempt to fix the problem. Edokter was unhappy with my first attempt, and I realized that I could take a more straightforward approach that better duplicated the shade of purple that we've traditionally used for years.
This was a minor change that had no effect on any elements of the actual site interface (and no effect at all for users whose cache predated the edits), so I don't see why it should be regarded as a big deal, deemed a "test" and reverted on principle. —David Levy 19:07, 3 December 2008 (UTC)
You might not have noticed it, but at the top of this page, there is a note saying "Please discuss changes before implementing.". I think it might make sense to actually do that. —Ms2ger (talk) 19:14, 3 December 2008 (UTC)
That message is there to prevent sysops from breaking things. People frequently perform minor changes without advance discussion, and this one was about as minor as they come.
I have no problem with someone reverting because they dislike the change (or reporting said dislike, at which point I would have immediately reverted), but reverting simply because the precise background hue of some non-mainspace templates was slightly tweaked without prior authorization (and not because anyone has actually complained about the difference) strikes me as bureaucratic. —David Levy 19:24, 3 December 2008 (UTC)
Er, looks like four to me, unless I've lost the ability to count. To be clear: I have no problem whatsoever with the first change being made. You saw a problem, investigated the likely cause, I assume you tested it first and decided that it worked for you, and implemented what I fully agree is ultimately a rather trivial change. That change clearly caused some problems; it seems that Edokter's edit was well along the "dislike the change" mark you mention above. I agree it's rather hideous. That is the point at which it stops being a trivial change and becomes a lot more serious; making another individual decision on what colour you think works best and implementing that is most definitely not the way to go forward. Any reaction is a sign to step back and talk. How difficult is that? Happy‑melon 19:32, 3 December 2008 (UTC)
Had I reverted back to my original edit, I would completely agree with you. But that isn't what I did. I worked with Edokter's selection (leaving two of the three attributes unaltered and changing the third by one letter) in an attempt to further tweak the color. What you evidently perceive as edit-warring, I view as collaboration.
And I wouldn't have been doing any of this if it had resulted in a major change. CSS can be dangerous to modify, but this was tantamount to normal template editing. —David Levy 20:01, 3 December 2008 (UTC)
Not doubting your good intentions, I have to somewhat agree with HM; editing common.css isn't a big deal, but should be done sparingly if possible. That said, I should have discussed first as well. — Edokter • Talk • 20:11, 3 December 2008 (UTC)
Given the thirty-day cache, I don't see minor edits lacking prior discussion as a big deal (provided that standard wikiquette is applied). I would, however, always refrain from performing one (or self-revert) at the request of any user in good standing. —David Levy 20:22, 3 December 2008 (UTC)

When saying "editing common.css isn't a big deal" and "I don't see minor edits lacking prior discussion as a big deal", please remember, what you might consider a minor edit (as in, a small change) can be a big deal. And the 30 day cache makes it more so, not less. If you break something, then for some fraction of all people, those who happen to load the stylesheet at that moment, it may remain broken for them for up to 30 days. Please, it would be best to discuss all changes, no matter the size, even if adding a comment (comments between selectors for example, are bad juju), or you get wheel edits like this. And now you have up to 4 versions floating around for up to (in theory, in practice it is usually less) a month in various user caches! --Splarka (rant) 08:38, 4 December 2008 (UTC)

That all depends on what is being changed. That edit made a considerable change, our edit merely changed a color value. Yes, we should be cautious, but not paranoid. — Edokter • Talk • 12:38, 4 December 2008 (UTC)

Superscript fix for infoboxen in IE

Latest comment: 15 years ago2 comments2 people in discussion

{{editprotected}}

Oh the joys of Internet Explorer. IE likes allowing superscripts to adjust the height of table cells. This is causing problems for the newly-accessible {{infobox Football biography 2}}, as detailed in this thread. It also seems that this fix will be of benefit to other uses of {{infobox}} where cells contain superscripts. Addition needed: 

table.infobox sup { vertical-align: text-top; }/* Internet Explorer changes line height for cells containing sup tags; this misaligns cell baseline */
html>body table.infobox sup { vertical-align: super; } /* IE ignores this selector, so other browsers can use usual superscript styling */

Chris Cunningham (not at work) - talk 14:44, 5 December 2008 (UTC)

  Not done. Common.css is not meant to fix problems in a single template. The bug described in the linked discussion is caused by a hard-coded line-height of 9pt in the Clubs section. Remove that and it should be fixed. — Edokter • Talk • 19:21, 5 December 2008 (UTC)

apostrophe abuse in comment

Latest comment: 15 years ago2 comments2 people in discussion

{{editprotected}}

Minor fix for a rogue apostrophe in a comment. Change: 

/* Inline div's in ImageMaps (code borrowed from de.wiki) */
.imagemap-inline div {
    display: inline;
}

to: 

/* Inline divs in ImageMaps (code borrowed from de.wiki) */
.imagemap-inline div {
    display: inline;
}

Chris Cunningham (not at work) - talk 15:07, 5 December 2008 (UTC)

  Done The Helpful One 17:36, 5 December 2008 (UTC)

iPhone compatibility

Latest comment: 15 years ago4 comments4 people in discussion
Moved from WP:VPT Happy‑melon 20:09, 14 December 2008 (UTC)

I started a discussion at Talk:Main Page and was redirected here. I have a proposal to add a line of code to Wikipedia (and potentially the entirety of the Wikimedia Foundation) that better enable compatibility with the iPhone (and I guess anything else running Mobile Safari - though I'm not aware of any). Though Wikipedia on iPhones is a small market, the code doesn't hinder any accessibility with other platforms, so there's no harm done to anything else - only benefits for iPhone users. When viewing the Main Page (and some other articles) on an iPhone, the left column's text(TFA, DYK) is much larger than the right column's text(ITN, OTD); this causes massive whitespace under OTD that looks ugly. Also, the licensing information at the bottom of the page, the tabs across the top ("edit this page," "watch," etc.), and user links ("Username," "my watchlist," etc.) in the top right corner of the page are oversized. Apple proposes a fix for this by modifying the "-webkit-text-size-adjust" parameter in the body tag's CSS of the page, suggesting "-webkit-text-size-adjust:none". Well, this method works for the iPhone but prohibits zooming in and out on Safari (and Google Chrome, as well as any other webkit browsers). After experimentation on User:Dudemanfellabra/Sandbox2, I've found that changing "none" to "100%" ("-webkit-text-size-adjust:100%") fixes the problem. Zooming in and out in Safari/Chrome works, and the iPhone displays the page correctly. I've tested the code firsthand on Windows (Google Chrome, FF2/3, MSIE 6/7/8, Opera 8/9) and Mac OS X (Camino, FF2/3, Opera 9, Safari 3.2); the site appears the exact same on desktop browsers with the code added, and the zoom function still works, and the iPhone works better. Also, if it helps, through Browsershots.org, I've tested it on several Linux/BSD browsers just for safe measure. All other browsers seem to work fine with the code, so I propose adding "-webkit-text-size-adjust:100%" to Wikipedia's body CSS. --Dudemanfellabra (talk) 19:59, 14 December 2008 (UTC)

If you want this Wikimedia-wide, your best bet is to try to get it into the core software via Bugzilla request. Probably skins/monobook/main.css if it is mostly for Monobook (or skins/common/shared.css for all skins). However, this will cause it to fail validation. However2, the head Wikimedia/MediaWiki dev Brion VIBBER is a total iPhone fan boy, so he may go for it. Note that this'd be perfect for media="handheld", if the iPhone bothered to 'grok' it. --Splarka (rant) 08:37, 15 December 2008 (UTC)
This went to bugzilla:16654; in my testing, the change makes article pages much harder to read (illegibile in portrait mode), so probably isn't the way to go for now. --brion (talk) 19:00, 18 December 2008 (UTC)

multi-columns

Latest comment: 15 years ago3 comments3 people in discussion

.references-2column must surely be redundant to div.columns-2, no? I'm sure with a bit of co-ordination we can use these to consolidate both the somewhat messy contents of {{reflist}} and these two definitions here. Happy‑melon 23:28, 21 December 2008 (UTC)

AFAIK, references-2column is an old method of creating a 2-column reference list that is still in use in some articles; it could probably be replaced with reflist, but someone (probably working from a DB dump, or maybe the toolserver) would have to actually do it. All the classes in {{reflist}} are there to support user overriding of the behavior after many complaints at Template talk:reflist (some people just can't stand multiple columns for some reason), as far as I know they aren't actually defined in any of the global CSS files at this time. Anomie⚔ 03:04, 22 December 2008 (UTC)
Not really. .references-2column lets the browser balance the two columns, while .columns-2 requires that the user picks the breaking point—and that doesn't always work out right. —Ms2ger (talk) 15:24, 22 December 2008 (UTC)

captions are off-center

Latest comment: 15 years ago9 comments5 people in discussion

This style sheet currently contains; 

.infobox caption {
    font-size: larger;
    margin-left: inherit;
}
caption
header header header
data data data
caption
header header header
data data data

and I believe that the margin-left: inherit; should be removed. The value inherited is currently 1em, from a few lines above this rule. It may have once had some value, but it is currently only serving to push captions off-center to the right; see top example, at right. In the second example, I've included an explicit style="margin-left: auto;" for the caption element to undo the issue.

Am I missing something? This has wide effect and I suspect that it has discouraged the use of captions in favor of headings, which is unfortunate from a semantic perspective; tables should have captions.

There is a similar rule; 

.wikitable caption,
.prettytable caption {
    margin-left: inherit;
    margin-right: inherit;
    font-weight: bold;
}
caption
header header header
data data data
caption
header header header
data data data

and I believe the two margin inherits should also be removed here.

I've included an explicit style="margin-right: auto;" in the second table at right to undo the problem. In this example, the first caption is a bit off to the left. The correct fix is to remove these lines, not to use 'auto' (and '0' can really hose old Firefox).

Also, the other remaining bits are rather dubious as they are pretty much the default anyway. nevermind

There is also the issue that this code is extant on hundreds of wikis and if there is consensus to change it here, the change should be propagated all over the place.

fyi, I'm using Firefox 3.0.5 and see this issue in the other modern browsers, too.

Comments?

Cheers, Jack Merridew 08:34, 23 December 2008 (UTC)

These rules were added back in 2005 (infobox and wikitable), AFAICT without any discussion. I agree that they should be removed, but I think we should ask User:Ed g2s first. —Ms2ger (talk) 18:03, 23 December 2008 (UTC)
I agree, this does not seem like something that should be applied to ALL headers, but was targeted at some kind of specific case. I favor removal. With or without edg2s consent :D --TheDJ (talk • contribs) 18:25, 23 December 2008 (UTC)

The inherit margins seemed to fix the off-centre issue at the time. One should probably consult the CSS specification. Although it may not go into that much detail... ed g2s • talk 22:21, 23 December 2008 (UTC)

(to all) I am quite familiar with the CSS spec ;) I have encountered this issue elsewhere and in real-life. Removing these will fix a lot of captions out there. There may be local fixes in place on second or third tier templates to address the issue, but this removal will simply render those moot. If there are some cases way out in left field where this somehow affects something, the place to address the issue is out in whatever locality. I have no doubt that these rules were well-intentioned and that they may-well have been entirely appropriate at the time; times change — MediaWiki has changed, browsers are smarter (well, some of them are).

caption
header header header
data data data
caption
header header header
data data data

While getting the rendering 'pretty' is desirable, my core concern is semantics. If this issue has, in fact, deterred many folks from using proper captions, it amounts to a profound long-term setback for the projects. Having semantically correct captions on tables is core to proper accessibility of pages to things like screen readers and to correct analysis of page content by search engines. Fixing this issue is only a first step. A great many tables place what should be a caption-element in a top row-spanning cell that might not even be a th-element; it's made big and bold and blue and may have a background-color for extra meretriciousness. With proper css and template/table implementations, whatever desired rendering can be achieved with a true caption. Terima kasih. Cheers, Jack Merridew 04:59, 24 December 2008 (UTC)

nb: I've added a mock-up of how to fake a caption appearing 'inside' the table; it's not really, but the borders make it appear to. Cheers, Jack Merridew 15:34, 24 December 2008 (UTC)

  Done this seems to be the right way to proceed. Happy‑melon 15:52, 24 December 2008 (UTC)
Terima kasih (thank you). nb: I've just adjusted the examples I gave above to restore the incorrect behavior on the upper of the two pairs. Also, there was an issue with the final example that places the caption 'inside' the table when rendered by WebKit; TBD. Cheers, Jack Merridew 05:04, 25 December 2008 (UTC)
I've tweaked the 'inside' example and added another variant that gets WebKit working a bit better; will pick at this another day and build some working example elsewhere. Cheers, Jack Merridew 10:36, 27 December 2008 (UTC)

Can we add "textarea {font-family:inherit;}", please?

Latest comment: 15 years ago3 comments2 people in discussion

There's a discussion going on at Wikipedia:Village pump (technical)#Textarea_font_change where a bunch of us Safari users are annoyed that, as a result of bug 1941, text fields have been switched to use monospace fonts by default. This affects primarily Safari as Safari is slightly odd in that, by default at least, its textareas use multispace fonts. Bug 1941 aimed to specifically stamp out this inconsistency, and while a consensus on the English Wikipedia that this was a bad idea won't get the software changed for everyone everywhere, a consensus on the English Wikipedia can get our local Common.css file to countermand the default setting, by adding textarea {font-family:inherit;}. There are two questions which would be a primary barrier to adding this code:

  • Does adding this code cause problems for other browsers, or otherwise change their normal behaviour for the worse?
  • Is there any specific opposition to adding such code?

If this code works well enough, I'd like to add it. Would users who have other browsers, especially Internet Exploder, please test the rule using their monobook.css? {{Nihiltres|talk|log}} 18:53, 24 December 2008 (UTC)

Breaks Firefox 3 on Linux, the textarea inherits "sans-serif" from the body rule in main.css. Anomie⚔ 19:09, 24 December 2008 (UTC)
Gah. I'll look into making this a Gadget, then. Thanks for the input. {{Nihiltres|talk|log}} 20:25, 24 December 2008 (UTC)

This talk page exists for a reason

Latest comment: 15 years ago5 comments5 people in discussion

Guys, you really really should test your CSS and discuss it here first.

--Splarka (rant) 22:50, 10 January 2009 (UTC)

Agreed. I admit I have made un-discussed changes in the past, but after a few incidents, I've learned what Splarka says is true: even minor changes can break the site. And cache is a bitch. I've reverted Happy-melon's changes, which from the outside seems kinda dickish, but we really do need to be careful with the site-wide JS / CSS. --MZMcBride (talk) 22:57, 10 January 2009 (UTC)

I accept and fully support the premise that A) changes that have a visible effect or change functionality should be discussed, B) that changes that don't gain immediate unanimous support should be reverted and discussed (and readding reverted code is strictly taboo), and C) that we need to be extra extra careful with CSS and JS. However, I don't think I can agree with MZ's conclusion that any change, no matter how trivial, should be discussed. And I think we can agree that, as edits to Common.css go, this is pretty trivial :D. Of course that was not my only edit, and it was in response to me screwing up my first addition by using the wrong comment syntax (reverted within a few seconds). But that last edit was an attempt to learn from past mistakes in the true wiki fashion.

I think some balance is needed here, between maintaining code integrity and avoiding unnecessary bureaucracy. I think that saying "discuss every possible change before making it" falls on the wrong side of that line. My philosophy remains "discuss changes in functionality, test all changes rigorously, and revert&discuss all changes on the slightest request". So in line with that, now MZ has reverted: does anyone object to the changes I made here and to Common.js to skin and dynamically style the show/hide buttons? Happy‑melon 14:49, 11 January 2009 (UTC)

I disagree with the comment that these lines of code should be removed in two thousand eight, but apart from that, I'm fine with them. However, I think you should've put the real code on the talk page for a few days before adding it—multiple pairs of eyes see more than just one. —Ms2ger (talk) 15:29, 11 January 2009 (UTC)
No objection from me. I agree that trivial edits like bugfixes, comment edits and minor styling changes shouldn't go through red tape. Anything else should be posted fro review first. — Edokter • Talk • 15:32, 11 January 2009 (UTC)

Best practices for editing these pages?

Latest comment: 15 years ago1 comment1 person in discussion

I finally took the time to put words on a page vis how I see our Best Practices in editing system messages, particularly the skin files: WP:EI. I don't think we need anything as pretentious as a policy or guideline to control how we work on these files, but it would be nice to have something to point to to ensure we're all reading from the same song sheet. Comments and criticisms would be very welcome. Happy‑melon 23:06, 11 January 2009 (UTC)

WP1.0 quality assessment colours

Latest comment: 15 years ago3 comments2 people in discussion

I now know why the first attempt to add the WP1.0 assessment scheme colourings (as used by {{FA-Class}}, {{Category-Class}}, etc) didn't work: the CSS specificity of the wikitable declarations overwrote the puny ".assess-fa" declarations. Now I've fixed and tested the declarations with the ".mediawiki" qualifier; they should sit in the correct place in the hierarchy now. 

/* Skinnable CSS for assessment grades */
.mediawiki .assess-fa       { background: #6699FF; }
.mediawiki .assess-fl       { background: #6699FF; }
.mediawiki .assess-a        { background: #66FFFF; }
.mediawiki .assess-ga       { background: #66FF66; }
.mediawiki .assess-b        { background: #B2FF66; }
.mediawiki .assess-c        { background: #FFFF66; }
.mediawiki .assess-start    { background: #FFAA66; }
.mediawiki .assess-stub     { background: #FF6666; }
.mediawiki .assess-list     { background: #AA88FF; }
.mediawiki .assess-na       { background: #F5F5F5; }
.mediawiki .assess-         { background: transparent; }
 
.mediawiki .assess-category { background: #FFA500; }
.mediawiki .assess-disambig { background: #00FA9A; }
.mediawiki .assess-image    { background: #DDCCFF; }
.mediawiki .assess-portal   { background: #808080; }
.mediawiki .assess-project  { background: #C0C090; }
.mediawiki .assess-redirect { background: #C0C0C0; }
.mediawiki .assess-template { background: #FFCCFF; }
 
.mediawiki .import-top  { background: #FF00FF; }
.mediawiki .import-high { background: #FF88FF; }
.mediawiki .import-mid  { background: #FFCCFF; }
.mediawiki .import-low  { background: #FFEEFF; }
.mediawiki .import-na   { background: #F5F5F5; }
.mediawiki .import-     { background: transparent; }

As well as providing increased skinnability, this will allow us to get rid of Bad Things like {{FA-Class col}}, resolve problems like this and allow us to move towards a clean and low-overhead way of implementing these assessments without such a plethora of templates. Happy‑melon 10:28, 14 January 2009 (UTC)

It looks good to me, it would be nice to see all those *-class (tl|col|whatever) templates deprecated and (eventually) removed. AFAIK, they aren't properly documented anywhere, their usage is generally unclear, and it's not even clear how many of them there are. Adding these styles would allow us to eliminate all but one template for each assessment and importance grade, and that one remaining template would be a preformatted, prelinked cell for project banners to use. 「ダイノガイ千？！」(Dinoguy1000) 22:54, 14 January 2009 (UTC)
  Done. Plenty of time for more discussion while the decaching time runs. Happy‑melon 00:52, 18 January 2009 (UTC)

Request - thumb in Infobox

Latest comment: 15 years ago9 comments2 people in discussion

{{editprotected}} I sugest adding this: 

/* Remove left and right border from thumbs inside .infobox */
.infobox div.thumb {
    border-left-style: none;
    border-right-style: none;
}

Thumbnails have coded border to have some margin from the text they float in: 

div.tright {border-width:0.5em 0 0.8em 1.4em;}

But it does not look good in infoboxes (see Nikon D300).

Please forget my bad English. Multimotyl (talk) 01:17, 21 January 2009 (UTC)

Removing the border does not fix any alignment within an infobox. The standard practice is not to use thumbnailing in an infobox at all. This code fixes nothing in my opinion. — Edokter • Talk • 03:56, 21 January 2009 (UTC)
I tried it in my own early mediawiki project [1] and tested in major web browsers (MSIE, Firefox, Opera, Safari). Believe me, it works. The change i suggested is quite easy, safe and works well. Multimotyl (talk) 09:28, 21 January 2009 (UTC)
Your example still shows the border, but not the margin. Having tested your code here, the margin is not adjusted, and effectively shows no change. The margin is necessary to stay clear of text. Removing it here will cause surrounding text to stick to the thumbnail. While that may look better in an infobox, thumbnailing is intended to use in article text. Within a box, you should not use a thumbnail, but a seperate caption. So, I'm sorry, but this code will not be added. — Edokter • Talk • 15:31, 21 January 2009 (UTC)
Upon further review, removing the margin itself when embedded in an infobox may be a viable option, but that needs more discussion. I still feel thumbnails in an infobox is redundant. — Edokter • Talk • 15:36, 21 January 2009 (UTC)
It is border which is white so it looks like margin :-). Actualy I wasnt talking about margin property of CSS, but about border property which looks like margin. So maybe it seemed to you like I don't know, what I'm writing about. Thumbnail inside infobox may be redundant, but on the D300 example it seems useful to have a caption to describe the image. It shows not only the D300 itself, but also a lens. —Preceding unsigned comment added by Multimotyl (talk • contribs) 18:14, 21 January 2009 (UTC)
The border does not determine the space next to the thumbnail; you code does not do anything to remove that (it actually adds whitespace above and below the thumbnail). Really, the best thing to quickly fix it is to add a caption to the infobox. I'l add the code for you, so you can see the result. — Edokter • Talk • 19:39, 21 January 2009 (UTC)
Here's the result. — Edokter • Talk • 19:46, 21 January 2009 (UTC)
Hey, I was mistaken with something. I forgot, that there is also a MediaWiki:monobook.css Which removes the border (under /* Remove white border from thumbnails */ ) and puts a margin instead of them. It starts to get confusing :-). Thank you for your patience. I thought, that if there is border on my site so there is one on wipipedia too. And unfortunately I have Firebuged only my site. :-). —Preceding unsigned comment added by Multimotyl (talk • contribs) 20:32, 21 January 2009 (UTC)

Semi-protection edit notice

Latest comment: 15 years ago1 comment1 person in discussion

I'm not sure the notice showing the latest logged entry in the protection log when editing semi-protected pages is that useful. It's not that necessary to remind editors that a page is semi-protected whenever they edit it, or if it is, a simple note that the page is semi-protected and a link to the protection log may be better. Indeed, the latest logged entry is often an adjustment of the protection without specifics on why it is protected, or an addition of move-protection, or worst the logged entry due to a move. So when a semi-protected page is move-vandalized, whenever editing it, editors see a often highly offensive red link. Cenarium (Talk) 17:31, 24 January 2009 (UTC)

Proposal: shifting italics text slightly to the left

Latest comment: 15 years ago7 comments7 people in discussion

Mixing upright and roman text, as done in mathematical formulas, italicized titles at the end of parentheses, etc. looks ugly due to the shifting of italics text to the right, for example:

(g ∘ f)(0) = g(f(0))
... (meaning beef) ...

Some editors fix this by adding thin spaces or ad-hoc span-based formatting, but his could be fixed once for all and site-wide by adding a declaration such as i { margin-left: -0.1em; margin-right: 0.1em; }. The resulting output would look like:

(g ∘ f)(0) = g(f(0))
... (meaning beef) ...

What do you think? -- Army1987 – Deeds, not words. 20:46, 25 January 2009 (UTC)

What browser are you using? To me your psoposed change actually looks worse on FF3. Happy‑melon 21:23, 25 January 2009 (UTC)
Changing the behavior of <i> seems incredibly dangerous. --MZMcBride (talk) 21:53, 25 January 2009 (UTC)
The change is not noticable on small font sizes, and yes, messing with a browser's font handling is dangerous, possibly interfering with user's browser settings or Wikipedia's CSS. — Edokter • Talk • 23:34, 25 January 2009 (UTC)
I only see a difference in Opera if I enlarge everything by at least 200%. --Carnildo (talk) 03:09, 26 January 2009 (UTC)
On Ubuntu 8.04, it looks slightly better in Epiphany (2.22.2) and slightly worse in Firefox (3.2a1pre/20090124). Adding it (back) to your own monobook.css seems the best solution. —Ms2ger (talk) 16:12, 26 January 2009 (UTC)
I had to zoom +4 on FF3 to see the difference. If the real issue is with how formulas display, then a simple template would resolve the problem. Also see Help:Displaying a formula. --—— Gadget850 (Ed) talk - 19:18, 26 January 2009 (UTC)

The eternal hunt for deprecated classes continues

Latest comment: 15 years ago41 comments9 people in discussion

Spent a happy evening today going through looking for deprecated classes. Found quite a few that are either unused or close to it; comments appreciated on the possibility of removing each of these. Happy‑melon 23:13, 13 January 2009 (UTC)

.same-bg { background: none; }

Was implemented way back in 2006, but only ever managed to find its way into one article, and was redundant there. Its only other appearances are in people's monobooks (why people feel the need to copy the entirety of common.css into their personal skin files is something that I will never understand :D). Happy‑melon 23:13, 13 January 2009 (UTC)

I don't really see the point of this one. No objection to removal. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)
  Done Happy‑melon 21:41, 21 January 2009 (UTC)

.prettytable

There are only 500 uses of class="prettytable" remaining 'in the wild'. Should we make the final jump to replacing it throughout and removing the duplicate declarations? Happy‑melon 23:13, 13 January 2009 (UTC)

I think this is our oldest "deprecated" class. The time might be right to start removing it for good. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)
I realised, that in OpenOffice.org 3.0 export filter to mediaWiki syntax is .prettytable still used. I'm not sure what to do with that, but if it is deprectated, maybe someone shall tell them. (please forget my bad english :-)) Multimotyl (talk) 23:26, 20 January 2009 (UTC)
I support removing this. Even today it's not going to work outside Wikipedia, so if OpenOffice is using it in their MediaWiki exporter then that's a bug in OpenOffice. —Remember the dot (talk) 21:08, 21 January 2009 (UTC)
This is one where you would have to ensure it's not being used anywhere. I imagine it's still hardcoded into quite a few pages. --MZMcBride (talk) 21:54, 25 January 2009 (UTC)
There are 5,151 instances of prettytable in the October 2008 database dump. —Remember the dot (talk) 20:32, 27 January 2009 (UTC)
Is that only in articlespace ? --TheDJ (talk • contribs) 21:06, 27 January 2009 (UTC)
Yeah. Good point, there may be more instances in other namespaces. —Remember the dot (talk) 21:53, 27 January 2009 (UTC)
Maybe add this to AWB's autofixes? Can there ever be a valid reason to use the phrase "prettytable" on a page? Happy‑melon 22:25, 27 January 2009 (UTC)
Adding any of these cleanups to AWB seems to be a good idea. --—— Gadget850 (Ed) talk - 23:11, 27 January 2009 (UTC)

.infobox.standard-talk

I mean really, WTF? Added April 2008; I can see how it makes a certain amount of academic sense, but it's unused and thoroughly deprecated. Happy‑melon 23:13, 13 January 2009 (UTC)

Not so sure here. But likely won't hurt. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)
  Done Happy‑melon 21:41, 21 January 2009 (UTC)
This was not unused (as I would have explained if anyone had asked me), and I just came here upon noticing that Template:Main Page toolbox's namespace-dependent coloring was broken. Can someone kindly point me to the technique that this has been deprecated in favor of (so that I can repair the template)? Thanks. —David Levy 21:51, 25 January 2009 (UTC)
Of course, I don't know whether any other pages depend on this class, as the mechanism used to check evidently doesn't find instances in which the complete text ".infobox.standard-talk" is interrupted by conditional code. (In this case, the class is defined as "infobox {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|standard-talk}} bordered".) —David Levy 21:57/22:00, 25 January 2009 (UTC)
Restored. We are allowed to make honest mistakes, you know, and it's not exactly as if this change was rushed through. The "standard-talk" system is deprecated; there is no replacement because no one thought that infoboxes had any use outside the mainspace. I can't really see the connection myself: how is the main page toolbox semantically an infobox? Happy‑melon 22:08, 25 January 2009 (UTC)
Oh, of course people make honest mistakes (and I've made much worse ones myself). I'm sorry if I came across as rude, which certainly wasn't my intention.
I wasn't being sarcastic when I requested "the technique that this has been deprecated in favor of." I sincerely assumed that there was one (which is why I didn't restore the class myself).
This is not an area of expertise for me, so I have no idea why that template semantically should or shouldn't be an infobox; that's just what it was when I found it. If there's a better way to achieve the desired layout, I'm all for it. —David Levy 22:23, 25 January 2009 (UTC)
Me too :D. As I say, I never really thought that the classes would have any use; the search merely confirmed my belief. I can't really see why the toolbox template can't be a simple wikitable; you could add the coffeeroll colours manually if you wanted it to match the talk namespace styles. Certainly there isn't any real nead to use the infobox classes. Happy‑melon 22:52, 25 January 2009 (UTC)

div.videolist, div.multivideolist

Template:Video is gone, and it wasn't using these nasty unclickable background images anyway by the end. .listenlist will eventually go the same way now that {{listen}} has been updated, but there are still a lot of transclusions of {{multi-listen start}} to clean out first. Happy‑melon 23:13, 13 January 2009 (UTC)

.hiddenStructure

Iff T19009 is resolved favourably, we can polish this off in the same way as prettytable. Happy‑melon 23:13, 13 January 2009 (UTC)

Not 100% sure on this. Probably from a Talk page point of view, this class might still be useful for reading trough history and stuff. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

.Boxmerge

Added in December 2006, never made it further from de.wiki than here. Found a description of what it was supposed to do here; regardless of intent, it's completely unused here except in people's monobooks again. Happy‑melon 23:13, 13 January 2009 (UTC)

Let it be gone. :D --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)
  Done Happy‑melon 21:41, 21 January 2009 (UTC)

.references-2column

Deprecated since November 2006, doesn't appear to be used any more. —Remember the dot (talk) 21:14, 21 January 2009 (UTC)

It is still in use on some pages. You can't find them through the mediawiki search engine. You would probably need to search the database dumps. --- RockMFR 17:19, 26 January 2009 (UTC)
How do you know it's still in use then? How many pages are left that use it? —Remember the dot (talk) 17:54, 26 January 2009 (UTC)
RockMFR is right: you have to search through a dump. If it is still used, then it is probably time to update them to {{reflist}}. While we are looking at this, is ol.references still in use? This was added to make the references 90%, then changed to 100%. Then .references-small was added to use with reflist. The problem is that ol.references appears to override .references-small when using IE. --—— Gadget850 (Ed) talk - 19:23, 26 January 2009 (UTC)
Okay, how do I search through a dump? And yes, all instances of this class need to be converted to {{reflist|2}} - removing the class would definitely provide an incentive to clean up any remaining stragglers. I think we may be overestimating the impact of removing the class - at worst, non-IE users would occasionally see a reference list in a single column instead of two. IE users would continue seeing only a single column as before. —Remember the dot (talk) 19:30, 26 January 2009 (UTC)
See Wikipedia:Database download --—— Gadget850 (Ed) talk - 19:48, 26 January 2009 (UTC)
I was hoping there was some way to search it without downloading the whole thing...4.1 GB is just barely within the realm of feasibility. —Remember the dot (talk) 19:56, 26 January 2009 (UTC)
I believe that there are some users who will perform requested searches on their own downloaded copies of the db dumps; however, I don't know who any of them are. 「ダイノガイ千？！」(Dinoguy1000) 20:56, 26 January 2009 (UTC)
I'm downloading the current dump and will search it tomorrow. --—— Gadget850 (Ed) talk - 22:09, 26 January 2009 (UTC)
Thank you. I actually realized that I have a way to download the dump in less than 10 minutes, so I should be able to search it as well. —Remember the dot (talk) 02:55, 27 January 2009 (UTC)
I finished the search. As of October 2008, of our 2.7 million articles there were only 510 that still used references-2column. I'd say that's few enough that it's safe to remove the class. —Remember the dot (talk) 03:40, 27 January 2009 (UTC)
Great, although we should probably take the opportunity to clean them out. Does this mean we can now poke and prod you to check for any and all other database dump checks we want done? :D If so, put prettytable and the <cite> tag at the top of the list, please :D Happy‑melon 13:56, 27 January 2009 (UTC)
If you have a list of articles, I can run though them with AWB. Add them to User:Gadget850/Sandbox5. --—— Gadget850 (Ed) talk - 14:34, 27 January 2009 (UTC)

Aligning columns

Latest comment: 15 years ago14 comments6 people in discussion

{{editprotected}}

Following a discussion in the village pump, I'd like to submit the following for inclusion in common.css. Using thies css declarations a user can left align the first column and centre the rest by adding class="col1-left col2-center" to the table class definition. It's primarily intended to be used with wikitables, but I can't see a reason to limit to to them.

(to be added just below the wikitable declarations) 

/* a simple way of aligning table columsn */
.col1-left tbody td,
.col2-left tbody td+td,
.col3-left tbody td+td+td,
.col4-left tbody td+td+td+td,
.col5-left tbody td+td+td+td+td,
.col6-left tbody td+td+td+td+td+td,
.col7-left tbody td+td+td+td+td+td+td,
.col8-left tbody td+td+td+td+td+td+td+td,
.col9-left tbody td+td+td+td+td+td+td+td+td { text-align: left; }

.col1-center tbody td,
.col2-center tbody td+td,
.col3-center tbody td+td+td,
.col4-center tbody td+td+td+td,
.col5-center tbody td+td+td+td+td,
.col6-center tbody td+td+td+td+td+td,
.col7-center tbody td+td+td+td+td+td+td,
.col8-center tbody td+td+td+td+td+td+td+td,
.col9-center tbody td+td+td+td+td+td+td+td+td { text-align: center; }

.col1-right tbody td,
.col2-right tbody td+td,
.col3-right tbody td+td+td,
.col4-right tbody td+td+td+td,
.col5-right tbody td+td+td+td+td,
.col6-right tbody td+td+td+td+td+td,
.col7-right tbody td+td+td+td+td+td+td,
.col8-right tbody td+td+td+td+td+td+td+td,
.col9-right tbody td+td+td+td+td+td+td+td+td { text-align: right; }

It's not very elegant but don't knock it should work! — Blue-Haired Lawyer 12:21, 28 January 2009 (UTC)

I propose to use shorter names, like "left1", "center2", "right3", and to code like:
table.left1 tr td,
...
table.left9 tr td+td+td+td+td+td+td+td+td {text-align: left}

−Woodstone (talk) 14:12, 28 January 2009 (UTC)

Striked the editrequest. Enough admins follow this page, once we agree, it will be done.
Personally, I do see the appeal to this (my names would be col1-l col2-c col3-r btw. It's short and the meaning is quite clear). It looks like it could be useful and even though it is a lot of CSS, it does not seem too bad due to the high level of functionality it should bring. --TheDJ (talk • contribs) 15:05, 28 January 2009 (UTC)
My immediate reaction is "there's no way that's going to work on IE6" :D Can we have some browser-compatibility tests, please? Happy‑melon 19:34, 28 January 2009 (UTC)
You are right. Comparison of layout engines (Cascading Style Sheets) --TheDJ (talk • contribs) 20:47, 28 January 2009 (UTC)
I tested with success on Firefox, Safari and Google Chrome and failure on IE7. But I cannot see from the referred CSS comparison above why it should not work. −Woodstone (talk) 22:21, 28 January 2009 (UTC)
Because where they show the comparison for CSS selectors, it says "Trident 7.0 and up" (IE7) for the "Direct adjacent" selector (the +). --TheDJ (talk • contribs) 11:28, 29 January 2009 (UTC)
Yes, but I tested IE7 and that one did not work (same code is fine for the other 3 browsers). −Woodstone (talk) 18:23, 29 January 2009 (UTC)
It depends how you tested it. In certain situations, IE7 does not support CSS selectors. It's a very nice, completely undocumented bug. --- RockMFR 18:02, 30 January 2009 (UTC)
Clearly the use of "colspan" would create miscounts. −Woodstone (talk) 23:05, 28 January 2009 (UTC)
I'd still prefer .col1-left as I think it's more self explanatory and there's hardly a reason we need to economise on characters! I should have thought about ie7. I'll have a look at it and come back. — Blue-Haired Lawyer 23:27, 28 January 2009 (UTC)
Please test in all major versions of Opera. IIRC td+td can do Bad Things (tm) to some versions. Also this is very hacky and does't scale. Hate. --Splarka (rant) 08:17, 29 January 2009 (UTC)
found the relevant thingamabob. No idea what was going on there actually. Coulda been the white-space. --Splarka (rant) 08:36, 29 January 2009 (UTC)
Ah crap. I remember that one. Yes this would require a bit more extensive testing in this case. (BTW, i would not be surprised if ANY browser implementation that handles this would parse it rather slowly. It seems a prime candidate for inefficient implementation.) --TheDJ (talk • contribs) 11:26, 29 January 2009 (UTC)

Ugly fonts for transliteration templates

Latest comment: 15 years ago5 comments2 people in discussion

Hello, please see Template talk:IAST#Font size and Template talk:Transl#Font for translated words: there is something going on that looks ugly, e.g. using {{IAST|Pañcatantra}} gives Pañcatantra which is not the same font as simply typing Pañcatantra. Is this a browser bug? Can it be fixed with common.css? Can someone explain? Thanks, Shreevatsa (talk) 22:18, 31 January 2009 (UTC)

Using FF3's web developer kit, I can unload every CSS rule set by MediaWiki, and the text is still in a different font. So this is definitely a browser issue. Happy‑melon 22:25, 31 January 2009 (UTC)
More specifically, using <span lang="sa-Latn">Pañcatantra</span> gives the different font as before: Pañcatantra. I don't get this when I try the same HTML on non-Wikipedia (non-Mediawiki) pages. So it seems specific to the Mediawiki CSS, actually... and even if it's not, would it be possible to change the Mediawiki CSS to force the text to appear in the same font? Shreevatsa (talk) 22:31, 31 January 2009 (UTC)
I'm not sure I agree; WebDeveloper can also trace the source of any CSS styles applied to individual elements, and while it correctly identifies the MediaWiki stylesheets used to style the rest of the page, it politely informs me that no styles are being applied to that span by this site. On the other hand, even disabling all styling, including the browser defaults, still leaves the difference in place, so I really don't know what's going on. Happy‑melon 23:30, 31 January 2009 (UTC)
(I apologize for changing my comment repeatedly.)
I agree now that it seems to be a browser bug (this one).
Here are spans in a few languages: normal en-Latn sa-Latn ar-Latn el-Latn ru-Latn
Each of the last four appears in a different font from normal. However, if I disable http://en.wikipedia.org/skins-1.5/monobook/main.css?203xx (or disable all styles) it fixes the problem for me for sa-Latn and somewhat for ar-Latn (but not for the other two). (So although it ought to be fixed in the browser, there might still be scope to change the above-mentioned CSS file to improve the situation with sa-Latn, at least.) Shreevatsa (talk) 03:02, 1 February 2009 (UTC)

Cascadeprotectedwarning

Latest comment: 15 years ago4 comments3 people in discussion

I just noticed that the devs have now added a thing I waited for in the MediaWiki page rendering. I can now make the MediaWiki:Cascadeprotectedwarning work the same as our MediaWiki:Protectedpagewarning message. That is, I can now surround both the cascadeprotectedwarning message and the list of links below it with a single pink box, with a horizontal line between. Instead of as now that the list of links below ending up outside the pink box.

To fix this I intend to add one line of code to MediaWiki:Common.css. I will do this some day from now, when I am not as tired as now. (Don't edit system files when you are sleepy...)

If you want to know more or discuss this, see my longer message at Template talk:Fmbox#Cascadeprotectedwarning (and the sections before that too).

--David Göthberg (talk) 10:55, 6 February 2009 (UTC)

It's quite late here now (near 2:00 AM local time), so I'm sleepy (I got up ~20 hours ago), but looking quickly over what you've proposed, I don't see any problems. :) {{Nihiltres|talk|log}} 06:51, 7 February 2009 (UTC)
Sounds good to me. I trust you to make it look nice. :-) --MZMcBride (talk) 07:30, 7 February 2009 (UTC)
 Y Done - And it looks very nice, when one's browser has loaded the new version of MediaWiki:Common.css. Thanks Nihiltres for the double check, and thanks MZMcBride for trusting I will make it nice.
--David Göthberg (talk) 09:31, 8 February 2009 (UTC)

Pre-emptive strike

Latest comment: 15 years ago4 comments3 people in discussion
 
Yuck

Looks like RevisionDelete is coming soon to a wiki near you, and not a moment too soon. This means that all us admins will soon be graced by a new line of links on history and log pages, as modeled by test.wiki to the right. By default they're in a monospace font, and so by default they look hideous :D. Fortunately, no one's noticed yet. I propose we add the code below to MediaWiki:Sysop.css to keep it that way. 

span.mw-revdelundel-link,
stront.mw-revdelundel-link {
    font-family: inherit;
    font-size:   inherit;
}

I recognise that this is very much an ILIKEIT/DONTLIKEIT change, and if it is rejected here I'll just stick it in my own monobook and have the results anyway. But this is also a fairly unique situation in that we have the opportunity to choose the nicest appearance for a feature that doesn't yet exist, so we have no assumption in favour of the status quo, because there is no status quo! Happy‑melon 23:24, 30 January 2009 (UTC)

From the silence here I assume no one really cares that much :D.   Done Happy‑melon 00:10, 3 February 2009 (UTC)
Not really... But I urge to hold of on any pre-emptive action until we actually experience this new feature. It's not very Wikipedia-like. — Edokter • Talk • 00:36, 3 February 2009 (UTC)
In all honesty, that WAS ugly :) -- lucasbfr talk 13:37, 9 February 2009 (UTC)

Alternating colors for RecentChanges rows

Latest comment: 15 years ago4 comments4 people in discussion

Something to consider, assuming this change eventually goes live. Do we want alternating colored rows? If so, what colors? And do we add the code per skin or for all skins? --MZMcBride (talk) 18:33, 8 February 2009 (UTC)

Hard to know if one likes it before one has seen it. But my gut feeling is that it might be nice. And the choice of colours is simple: Use a light grey for every second row just like in the navboxes and in old school printing paper. And the other rows should simply be transparent, that is have the same background as the rest of the page.
Since the different skins have different backgrounds then that light grey needs to be different in each skin. That is, it needs to be a slightly darker version of the background colour in that skin.
But lets tinker with it and discuss exact nuance if/when that option is available.
--David Göthberg (talk) 01:06, 9 February 2009 (UTC)
I think it shouldn't be done globally, only on Special:Mypage/monobook.css on a per-user basis. -- lucasbfr talk 13:41, 9 February 2009 (UTC)
If it's not done globally, we can at least make it a Gadget. {{Nihiltres|talk|log}} 15:10, 9 February 2009 (UTC)

Steward Vote Notice Box

Latest comment: 15 years ago5 comments2 people in discussion

From WP:AN/I. --MZMcBride (talk) 04:26, 9 February 2009 (UTC)

I threw the idea of making the Steward Vote Notice Box a watchlist note on Meta and was told that "No, we can't do that. However enwiki admins can. The CentralNotice has an id they can display:none; in Common.css - then replace it with a watchlist notice." The notice box is throwing off some of the coding (for lack of a better term) on some pages and moving some objects, templates, etc. down behind other things. If an admin would like to be bold and move the template from the top of every page to the watchlist, I think Meta has given the OK. - NeutralHomer • Talk • February 9, 2009 @ 03:22

good idea. I'd wait a bit to see if no one objects though. Changing the CSS is not something that should be boldly done. It should also be done on the other skins as well if it breaks things (and remember to re-enable it once the campaign is over!!) -- lucasbfr talk 13:39, 9 February 2009 (UTC)
Okie Dokie....I will keep an eye on the discussion :) - NeutralHomer • Talk • February 10, 2009 @ 01:25
Anonymous users don't see the banner. And you're going to be fighting 30-day cache. So I'm not sure this is really practical. --MZMcBride (talk) 01:38, 10 February 2009 (UTC)
When it is throwing off things on different skins (including the default one) and it should have been a watchlist notice in the first place....yeah, I think it is practical. - NeutralHomer • Talk • February 10, 2009 @ 01:41
"Throwing off things"? I assume you're talking about the little icons in corner of pages? Are those breaking in any articles? (They're complete hacks, by the way. The entire system used to put icons next to the H1 header is complete trash.) --MZMcBride (talk) 01:50, 10 February 2009 (UTC)
Apprently it is moving some things into or behind text on pages. - NeutralHomer • Talk • February 10, 2009 @ 02:32
Apparently? Where? (And please bear in mind that I only particularly care about articles being affected.) --MZMcBride (talk) 03:10, 10 February 2009 (UTC)
lucasbfr said above that it was affecting some of the skins. Not sure what pages, cause I haven't checked, but I am taking him on his word. I know some of the userpages, talk pages, and article pages have problems with stuff sliding down the page. - NeutralHomer • Talk • February 10, 2009 @ 03:35

Template:Okina

Latest comment: 15 years ago2 comments1 person in discussion

This template is meant to correct MSIE display problems. Its font declaration shouldn't affect other browsers. Let's please add the following code to the style sheet. Thanks. —Michael Z. 2009-02-13 15:56 z 

/* support for template:Okina */

.okina {
    font-family: Lucida Sans Unicode, sans-serif;
    font-family /**/:inherit;
    }
Best fixed by using <span class="Unicode"> in the template itself. — Edokter • Talk • 00:09, 14 February 2009 (UTC)
There are 16 fonts in .Unicode before Lucida Sans Unicode. Unless you can tell me that they all include the okina, then this problem is not fixed by that method. —Michael Z. 2009-02-14 20:27 z
{{Unicode|ʻ}} = ʻ. The fonts in .Unicode were chosen because they were most likely to contain any unicode character. So yes, using this method is most likey to fix any character. — Edokter • Talk • 23:23, 14 February 2009 (UTC)

Help:Printable

Latest comment: 15 years ago3 comments2 people in discussion

Help:Printable seems to be wildly out of date. Any of you gurus want to take a stab at helping to update this? --—— Gadget850 (Ed) talk - 22:04, 19 February 2009 (UTC)

For the record, it's a copy of the Meta version which hasn't been copied over since 2005(!). 「ダイノガイ千？！」(Dinoguy1000) 18:23, 20 February 2009 (UTC)
There has been quite a bit of discussion about that, as none of those types of help pages have been updated in years. Wikipedia now uses stylesheets not documented on the Meta page. See Help talk:Printable#Update. A lot of this involves CSS, which is why I am soliciting help here. --—— Gadget850 (Ed) talk - 18:50, 20 February 2009 (UTC)

Addition to Print.css

Latest comment: 15 years ago4 comments3 people in discussion

Per Template talk:Nihongo#Hiding question mark, I would like to request that the following be added to Print.css: 

.t_nihongo_help
{
 display: none;
}

The {{Nihongo}} template is integral to Japanese-related topics here on Wikipedia. It adds a question mark for users to click on for relevant assistance. This is useless in print, and the added question mark makes the text read as if it is uncertain. This is more of an issue now that the Books feature is active. If any followup is needed, please be sure to contact editors at WP:MOS-JA or WP:JA. Regards, Bendono (talk) 07:27, 1 March 2009 (UTC)

Please change class="t_nihongo_help" into class="t_nihongo_help noprint" within the template itself to achieve the same functionality. --TheDJ (talk • contribs) 11:31, 1 March 2009 (UTC)
Agree, no need whatsoever for a bespoke rule. Happy‑melon 18:06, 2 March 2009 (UTC)
This issue is now solved btw. --TheDJ (talk • contribs) 19:11, 2 March 2009 (UTC)

Proposing a fix for Wikipedia:Featured article tools by changing the CSS

Latest comment: 15 years ago14 comments4 people in discussion

The Wikipedia:Featured article tools template, along with Wikipedia:Featured list tools, has a problem in Internet Explorer 7 (and perhaps other versions too). Take a look at this screenshot. The problem lies with #mw-prefixindex-list-table adding width: 98% to the &lt;table&gt; that surrounds the archived candidates. The CSS code for that is in the shared.css file, which I assume is not accessible via MediaWiki. The ultimate fix to this problem is to change the width to either auto (preferable) or 100%. To do this, the easiest way would be to add a custom class in MediaWiki:Common.css for these templates specifically, or another option would be to change the width in the class itself, which is less desirable. We could add #tools #mw-prefixindex-list-table { width: auto !important;} to the CSS, and then wrap the tools in &lt;div id="tools"&gt; so that we have better control over them. Thoughts? Gary King (talk) 20:41, 4 March 2009 (UTC)

I'm wondering why that table uses 98% to begin with. Anyone got a clue on why that would be needed ? --TheDJ (talk • contribs) 21:02, 4 March 2009 (UTC)
I'm assuming it looks nicer to have some padding around the box. Gary King (talk) 21:14, 4 March 2009 (UTC)
Likely, but don't we have padding attributes for that ? --TheDJ (talk • contribs) 21:26, 4 March 2009 (UTC)
No idea; the CSS was written by one of the MediaWiki developers since it's not in a wiki page, wasn't it? I assume that the code was written and not thoroughly tested, since that's how a lot of CSS is written. Not really a huge problem, as if necessary, we can just overwrite it here to auto or 100%. Also, these are bulleted items, so padding isn't even necessary as bulleted items have some built-in padding already. Gary King (talk) 21:51, 4 March 2009 (UTC)
I took a look, this is messy stuff so I am not entirely sure I am right, but here goes:
I think the problem is not with #mw-prefixindex-list-table. Instead I think the problems are that inside {{Wikipedia:Featured article tools}} and {{Wikipedia:Featured list tools}} you use <ul class="listify">, and that you try to right float a UL list, and that you try to put table code inside a UL list ({{Special:Prefixindex}} produces a table). All three of which are known causes of BIG problems, at least when used on Wikipedia. Just for starters check out the comment on the ".listify" class in MediaWiki:Common.css: "Compatible in Firefox; incompatible in IE6." That such a deadly combination works in any browser is amazing. (It works in my Firefox 2.0. :))
So instead I think you should change to sane code in those two templates. Simply give those {{Special:Prefixindex}} lists the full page width to work on. That's anyway much better for us who use lower screen resolutions. That is, simply remove the surrounding <div style="float:right; align:right;"><ul class="listify"> </ul></div>. I did some preliminary testing of this in my very old Internet Explorer 5.5, and it worked fine.
--David Göthberg (talk) 02:42, 5 March 2009 (UTC)
Okay, well feel free to make the edit to the templates. I cannot do them myself; I am not an admin. Gary King (talk) 03:49, 5 March 2009 (UTC)
It also needs to be done at Wikipedia:Featured list tools. I suggested merging both templates together at Wikipedia_talk:Featured_article_tools#Merging_this_template_with_the_other.3F. Gary King (talk) 04:56, 5 March 2009 (UTC)
 Y Done - I have now applied the fix to both templates. It took some time between them since I did some tests after I updated the first template. It seems to work fine in all my browsers, including my very old Internet Explorer 5.5. We now get an extra empty line above the toolbox, but I think we will have to live with that. Does it now look okay in your Internet Explorer?
Merging the templates? I tested to paste the code from one of them into the other and then clicking "Show changes". That showed there are several differences in the text used in them, so I can not merge them by simply redirecting one to the other. You need to check the code for them and decide/code what it is you want to have first.
--David Göthberg (talk) 05:13, 5 March 2009 (UTC)
Oh wow, the change needs to be undone, immediately. It shifts the listed items to the left instead of floating it to the right (in Firefox 3); I thought the change was meant to not change how it looks. And there must be a way to get rid of the extra line. Also, about merging the templates, I meant making a "core" template and then using that core for both templates, not just redirecting it. I'll look into both a bit more and offer my own solutions tomorrow when I'm more energetic. Gary King (talk) 05:30, 5 March 2009 (UTC)
Undo the fix? Hang on a moment. Yes, it kind of "shifts the items to the left" since as I said above it "gives the {{Special:Prefixindex}} lists the full page width to work on. That's anyway much better for us who use lower screen resolutions.". That is, {{Special:Prefixindex}} produces multicolumn output when it has two or more items to list, and the items in this case are rather long page addresses. Squeezing that to the right side of the page as you did before becomes too narrow in screen resolutions of 1024x768 and down, even in the non broken browsers. I assume you use some huge screen resolution since you thought that was okay?
And well, the empty line was there already before since it is produced by the {{Special:Prefixindex}} lists. That is, they produce an extra empty line no matter if they return a list or an empty list. Actually, that extra line was part of the old problem: The extra line when right floating above the toolbox caused the page text to flow around and above the toolbox, even in the non broken browsers.
That is why I didn't apply the fix immediately, I wanted you or your friends over there to test my suggested fix in a sandbox before we applied it. But really, what is so terrible with that the lists use the full page width and that there is an empty line below the lists (even when the lists are empty)? Are you sure you really want to revert to code that breaks in several browsers, and breaks for all who don't use huge screen resolutions, and causes bad text flow when empty lists even for you who use huge screen resolutions?
Actually, there is a slightly ugly template coding hack that can remove the empty line. And that hack works in all browsers. (I have just tested the hack.) But I am hesitant to apply that hack. Since it causes twice the amount of code in those templates, and will be very confusing and error prone for anyone else that tries to update those templates in the future. I don't think it is worth it just to remove an empty line from the top of some administrative discussion pages in project space.
--David Göthberg (talk) 12:31, 5 March 2009 (UTC)
The problem was never brought up until about a week ago, and the code has been like this for almost exactly one year. I guess I'll play around it some more. Gary King (talk) 15:41, 5 March 2009 (UTC)
It looks pretty bad right now. At here, the two items in the list appear as if they are just floating in the middle of nowhere, as they aren't in a list or anything. Gary King (talk) 23:27, 5 March 2009 (UTC)
Why not pack them in a box like is done for AfDs? 「ダイノガイ千？！」(Dinoguy1000) 17:59, 6 March 2009 (UTC)

Right margin too near to tables in some math articles

Latest comment: 15 years ago3 comments3 people in discussion
  Resolved
 – Not a CSS problem

With Firefox 3.0.7 on Ubuntu, when I look at Gamma distribution, I see that the right margin of the left text column is too near to the right column where the picture and the table are. There should be some more margin between the two columns. --Pot (talk) 08:46, 11 March 2009 (UTC)

This is not a CSS issue; see Talk:Gamma distribution#Right margin too near to tables in some math articles. --—— Gadget850 (Ed) talk - 10:41, 11 March 2009 (UTC)
I already fixed the template. --TheDJ (talk • contribs) 10:43, 11 March 2009 (UTC)

Printing issues with IE7

Latest comment: 15 years ago10 comments3 people in discussion

There have been several reports of blank pages when printing article with IE7. With some help, the problem has been tracked down to two CSS entries:


From MediaWiki:Common.css: 

sup, sub {
    line-height: 1em;
}


From commonPrint.css" 

p, .documentDescription {
    margin: 1em 0 ! important;
    line-height: 1.2em;
}

This can be resolved with a change to personal CSS: 

@media print {
sup, sub, p, .documentDescription { line-height: normal; }
}

This obviously does not work for casual users without an account, and IE is still the major browser. I have done some testing with FireFox and IE with this CSS and have not seen any issues. I don't know why these CSS rules have been adopted.

See Wikipedia:Village pump (technical)#Print issues for more details.

Thoughts? --—— Gadget850 (Ed) talk - 16:26, 25 February 2009 (UTC)

And two more complaints on this issue over at the help desk from IPs. --—— Gadget850 (Ed) talk - 20:08, 27 February 2009 (UTC)
Hi Gadget850. I just want to explain why I think you won't get much comments on and work done with this. Since I know it can be very frustrating to not get any response:
Most of us who have the knowledge and skills to handle this (and also the rights to edit these CSS pages, admins that is) are way too busy with more urgent things. For instance, I have a list of problems in these CSS pages that make it so articles doesn't render right in several major browsers, already when viewing the articles. Some of those problems have already been discussed here, but so far no one have had the time to investigate them enough and fix them.
So print problems have a much lower priority, sorry. Also, testing for print problems is much harder than testing for viewing problems.
--David Göthberg (talk) 08:44, 28 February 2009 (UTC)
And most of all. Almost all the people that understand stuff like this don't use IE, and IE is a pain to debug. --TheDJ (talk • contribs) 16:01, 28 February 2009 (UTC)

I've been reading up on this a bit. Both line-height and floating elements can cause issues like this on ALL versions of IE (at the very least all < 8). The print issue is indeed a known "unpredictable" line-height issue. The only way to "solve" this is simply don't use it in IE. The float version of this bug is the more often occurring version of this bug, because it also shows up on screen sometimes. These bugs (and more) are sometimes also referred to as the "peekaboo"-bugs. Because they engage web developers in a nice game of hide and seek with the content they want to present to IE users. I guess we could add a media print "!important" override rule to our local CSS. It would solve a problem a lot of people are experiencing I guess. It will only work if people have JS active of course, because all our local IE css is loaded trough Javascript. Any objections? and who is gonna volunteer to do it? --TheDJ (talk • contribs) 19:34, 2 March 2009 (UTC)

  • "local IE css is loaded through Javascript": Why do we do this?
    • Because CSS does not have a magic "browser detection" routine. The only IE specific CSS that is loaded is from either the Mediawiki wide CSS (which uses HTML comments that only IE will process), or trough Javascript. --TheDJ (talk • contribs)
  • Now that I have this hint, I did more testing: if JavaScript is disabled in IE, then the blank pages issue does not occur.
    • This is interesting. But we have gigantic amounts of JS of course. We will have to further reduce if it is JS specific to IE routines, or something more general. --TheDJ (talk • contribs)
  • Why do we have these two CSS rules to begin with?
    • Because they improve readability (for p), and because they force even line heights when we have inline refs etc. (for sub/sup). At least the latter was added after much discussion to find the "best approach". --TheDJ (talk • contribs)
  • To answer previous criticisms of IE, I agree. I use FireFox at home and work; it has issues, but stays more up to date. We have to deal with the reality that IE is the most used browser and we need to support it.
--—— Gadget850 (Ed) talk - 20:25, 2 March 2009 (UTC)
If we can target CSS rules specifically for IE, then we could apply this there. Where and how would this be done? --—— Gadget850 (Ed) talk - 13:31, 3 March 2009 (UTC)
We have MediaWiki:Common.js and MediaWiki:Common.js/IE60Fixes.js, which can target the IE platform. If this is added, it is probably best if the already present CSS in MediaWiki:Common.js and this new CSS are moved to a new file MediaWiki:Common.css/IEFixes.css and that we load that new page from MediaWiki:Common.js using a importStyleSheet(); This would also be easier for the CSS maintainers, because they don't have to bother the JS people :D --TheDJ (talk • contribs) 14:00, 3 March 2009 (UTC)

So folks, what are we gonna do here ? I'm no admin, so i cannot make any changes, nor do I feel confident enough yet about why this is occurring in the first place. I do however think we should try to work around this, even if we don't figure out why exactly this happens. --TheDJ (talk • contribs) 17:20, 16 March 2009 (UTC)

Yes. I really would like more feedback on this. I am an admin and a printer support engineer, but I'm not a CSS guru. --—— Gadget850 (Ed) talk - 17:43, 16 March 2009 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.css/Archive_7&oldid=1108579042"