Archives

This page has archives. Sections older than 40 days may be automatically archived by Lowercase sigmabot III when more than 7 sections are present.

Why is the #ca-delete rule marked as !important? This is not necessary, as far as I can see. --- RockMFR 23:22, 13 August 2009 (UTC)[reply]

If I print out an article from its history, the pink banner which is visible on screen ("This is an old version of the page, as edited by xxx on xxx etc etc") does not print out (I've tried several pages). I'm sure it used to. Is this a deliberate change? If so, why? I found the printed banner just as useful as the one on screen.

Thanks for any info and help

89.48.77.8 (talk) 05:53, 19 August 2009 (UTC)[reply]

Shows up on "Printable Version" for me, and I don't see any recent edits to MediaWiki:Revision-info, MediaWiki:Revision-info-current, or MediaWiki:Print.css that would cause it. Odd. --Splarka (rant) 07:38, 19 August 2009 (UTC)[reply]

Oops, it is hidden. It is because of #contentSub ... {display: none;} on MediaWiki:Print.css added here. --Splarka (rant) 07:49, 19 August 2009 (UTC)[reply]

It is pertinent to have the date printed, back, I mean printed on the bottom of the printable version. This serves a minimum of "priority date" (publication date) e.g. for legal purposes where users like offical organisations save a printed or PDF-printed version in their repositories as prior art. Please can the persons in charge of this restore the #contentSub value for print.css so that the date is printed ? --Wikinaut (talk) 09:14, 20 August 2009 (UTC)[reply]

I have presented a solution at your original post on the Village Pump. ---— Gadget850 (Ed) ^talk 09:57, 20 August 2009 (UTC)[reply]

I've removed the relevant code from Print.css until we get a better solution. It's better to show stuff that we want hidden rather than to hide stuff that we do want shown (in my opinion). — RockMFR 21:09, 23 August 2009 (UTC)[reply]

Adobe icon is not free, AFAIK, and to use it make people feel that only Adobe proprietary software can be used to open PDF files, and that's fra from truth: see PDFreaders FSFE initiative. Maybe we could use this graphics (e.g. the last one), instead. --Nemo 17:41, 28 August 2009 (UTC)[reply]

We could, but I don't think we should. The icon is supposed to ADD information, a green unfamiliar icon will just confuse people. I vote we remove the pdf icon and replace it with a generic document icon. —TheDJ (talk • contribs) 18:01, 28 August 2009 (UTC)[reply]

I guess TheDJ is right, a new icon will only confuse readers. I agree with his proposal. --Locos epraix ~ Beastepraix 18:21, 28 August 2009 (UTC)[reply]

bugzilla:20428 —TheDJ (talk • contribs) 18:22, 28 August 2009 (UTC)[reply]

The icon does add information, since there's a clear "PDF" writing and a link to a place where you can download a free pdf reader (current icon doesn't do so). Or, we could use another icon (e.g. the one suggested by tpascal), and still link to that website. --Nemo 18:51, 28 August 2009 (UTC)[reply]

At 14px, the PDF is illegible. like on the current icon, but at least that is an icon that everyone recognizes. And we can't use the image to link anywhere, because it is pure CSS. —TheDJ (talk • contribs) 19:30, 28 August 2009 (UTC)[reply]

Why do we need a bugzilla case on this? The PDF icon is on Commons at File:Icons-mini-file acrobat.gif and is sourced from FamFamFam. If the image is really not free, then we upload a free image over top of the old. ---— Gadget850 (Ed) ^talk 20:51, 28 August 2009 (UTC)[reply]

Yes, that is the image. However, the image automatically applied to PDF links by mediawiki is hard coded into the software and changes to a file on commons won't affect it. Ale_Jrb^talk 21:04, 28 August 2009 (UTC)[reply]

Also note that it doesn't matter who made that actual icon, it contains the Adobe reader logo, which obviously has (many) rights reserved . Ale_Jrb^talk 21:08, 28 August 2009 (UTC)[reply]

I guess I'm missing something, as it appears to me the image is linked in the CSS as "http://upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif". If the image is non-free, then it should not be on Commons. If I am right about the location, then the simplest solution is to find a free image an upload over the non-free version, thus updating every use. ---— Gadget850 (Ed) ^talk 22:03, 28 August 2009 (UTC)[reply]

I've nominated the image for deletion. If the image is deleted, we could possibly use File:Icon pdf.gif. — RockMFR 23:09, 28 August 2009 (UTC)[reply]

Many tables on Wikipedia contain repetitive, scalar kinds of information. Some people made templates for this task such as {{yes}} which usually transclude a cell background color and a default text. These are widely used as far as I can see. I’d like to pose the question whether the colors and sets shouldn’t be standardized more and then moved to MediaWiki:Common.css as much as possible. Please see the collective Talk page. — Christoph Päper 13:07, 15 September 2009 (UTC)[reply]

Please remove the following per rev:53289, now live in shared.css. — AlexSm 04:17, 18 September 2009 (UTC)[reply]

/* Coloured watchlist numbers */
.mw-plusminus-pos { color: #006400; } /* dark green */
.mw-plusminus-neg { color: #8B0000; } /* dark red */

Done by RockMFR. Locos epraix ~ Beastepraix 15:43, 19 September 2009 (UTC)[reply]

Could you please add .example { font-family: 'Georgia', serif; color: #006F00; }? The class example is used by {{xt}} which uses it for examples of styles, like this. (It is widely used on WP:MOS and some of its sub-pages.) Now the styling is specified in the template itself, but moving it here would save a few bytes each time the template is used, and would allow users to customize its style. (There is also {{!xt}} using the class bad_example and the style font-family: Georgia, serif; color: #B20000; like this, but it is an experimental template which isn't used yet.) --___A. di M. 21:15, 12 October 2009 (UTC)[reply]

See Wikipedia talk:Manual of Style#Green text. ___A. di M. 21:17, 12 October 2009 (UTC)[reply]

No need for sitewide CSS. Add the class to the template, and users can customise it using the !important keyword. Yes, it would save a few bytes on WP:MOS, but by adding the same bytes to the other 60,732,127 pages. Happy‑melon 21:49, 12 October 2009 (UTC)[reply]

Here are the detailed instructions how to use the !important keyword: Wikipedia:Catalogue of CSS classes#CSS caching is !important

--David Göthberg (talk) 13:11, 23 October 2009 (UTC)[reply]

For an image showing the problem see File:TT, PRE and CODE bug.png. To test how it looks in your browser, see User:Davidgothberg/Test59.

User Rd232 brought to my attention that teletype wikimarkup looks bad in Google Chrome. After some testing we deviced a solution that will make teletype look the same in Chrome as in all other browsers. Thus I intend to add this code to MediaWiki:Common.css:

/* Fix so <tt></tt> tags look the same in Google Chrome. */
tt {
    font-family: monospace, sans-serif;
}

The code is also parsed by all other browsers, but they already render teletype exactly like that, so it causes no visible change in them.

For the discussion and for our test examples that led to this solution, see Template talk:Nicecode. (We intend to delete that template once this fix has been added to MediaWiki:Common.css, thus that link will soon become red.) If no one sees a problem with this fix I will deploy it some day from now.

--David Göthberg (talk) 18:16, 23 October 2009 (UTC)[reply]

Just a note that this also affects code text,

pre text, and

/* source text */

There's a bug report on it somewhere IIRC. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:21, 23 October 2009 (UTC)[reply]

What exactly is the problem? Are you sure it will look exactly the same on all other browsers? Does this warrant a bug report for Chromium? —Simetrical (talk • contribs) 21:24, 23 October 2009 (UTC)[reply]

Simetrical: As I kind of stated above: See Template talk:Nicecode for the details. I didn't want to fill this page with a copy of that discussion.

And yes, it looks exactly the same on all browsers we have tested it on so far, except for in Google Chrome where it fixes the problem. And that CSS code is clear and simple. And for instance the CSS 4 standard has an informative section showing that the default look for the tt tag is "font-family: monospace". What we added is "sans-serif" which is the standard way to specify non-serif font, so should not cause any problems in any browser.

Dinoguy1000: I think I can fix it just as easily for <code>...</code> and <pre>...</pre>. I tested it in the three browsers I have: Firefox 2.0, Opera 9.02 and IE 5.5, and it didn't change their styles there. But I can't run Chrome on my OS so I can not see if it fixes the problem there. If you have Chrome, try adding the code below to your personal /monobook.css, then wait one minute for the servers to update, then bypass your browser cache.

/* Fix so <pre>, <code> and <tt> tags get normal text size 
   also in Safari, Konqueror and Chrome. */
pre, code, tt {
    font-family: monospace, sans-serif;
    t_font-family: times;
}

Note: I added the "t_" in front of the second line to remark it away. That's a quick and dirty way to remark away lines that I use in testing. Unremark the second line to test if your browser loads the code. (The second line will make it look ugly on purpose.)

So, does this fix the pre and code tags in Chrome?

I took a look, and it seems we can fix it for the <source>...</source> tags too, but that is much trickier.

--David Göthberg (talk) 02:26, 24 October 2009 (UTC)[reply]

Oh dear. I just checked how tt, pre, code and source tags look in lots of browsers, by using the nifty browsershots.org. The problem also affects Safari and Konqueror. Not surprising since they too use the KHTML/WebKit rendering engine. And just as Rd232 told me, the problem is that those tags cause extremely tiny text in those browsers. It looks really bad.

I didn't test in browsershots.org if our fix works, since I can't make browsershots load special CSS code. But I verified that those styles hardcoded into a span tag looked right in those browsers, so I am pretty confident. And I trust Rd232's word that it works, and I know it doesn't damage the looks in the browsers I have.

Could any Safari and/or Konqueror users confirm that the fix works. please?

--David Göthberg (talk) 03:07, 24 October 2009 (UTC)[reply]

I found the Bugzilla bug; it's 20706. Haven't tested your extended style yet, though. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:21, 24 October 2009 (UTC)[reply]

Just tested your code above on Google Chrome 3, works like a charm! Now, to get <source>...</source> to play ball, as well... 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:28, 24 October 2009 (UTC)[reply]

Dinoguy1000: Ah, thanks for the Bugzilla link and your testing.

As I understand that Bugzilla report this problem also perhaps affects Firefox 3.x users. In my Firefox 2.0 I don't see the problem. I should probably run a new test on browsershots.org and study the results closer.

The code I suggest above is very unlikely to cause any problems. But I will wait for some more confirmation that the code above works, especially from some Safari and/or Konqueror user. And to give due credit: It was Rd232 who noticed the problem and figured out what styles to use. He put them in the {{nicecode}} template. I just recognised that it would be better to use them here in Common.css to modify the <tt>...</tt> tag itself.

I intend to deploy the fix in steps, to minimize the impact if it screws up things in some browsers: First I will just add the fix for <tt>...</tt>, then wait some day to see if we get any complaints. Then add the fix for <code>...</code>, wait another day and then add it for <pre>...</pre>. Fixing <source>...</source> seems more complex, so I might try that some later time.

--David Göthberg (talk) 18:56, 24 October 2009 (UTC)[reply]

I think this should be fixed in the software instead of a local fix here. Locos epraix ~ Beastepraix 20:14, 24 October 2009 (UTC)[reply]

Well, yes, that's what the bug report is for. However, there is currently no proposed workable solution there, and even after one is suggested (probably David's/Rd232's code), it's hard to say how long it'll be before it's actually fixed. --Dinoguy1000 (talk · contribs) as 67.58.229.153 (talk) 03:55, 25 October 2009 (UTC)[reply]

The solution seems to work, but the displayed font (courier) is not a sans-serif font. So how stable can this solution be? −Woodstone (talk) 09:37, 25 October 2009 (UTC)[reply]

Woodstone: Yes, some browsers then chooses to use courier. But that is much better than having very small hard-to-read text.

In my browsers (Firefox 2.0, Opera 9.02 and IE 5.5, on Win ME) the solution does not display courier. I explicitly compare with courier in the test examples I use (see Template talk:Nicecode, so I see that the code above does not cause courier for me. For me the fix causes no change, which is correct as none of my browsers have the problem.

I ran a new test on browsershots and I studied the result closely (see the result here). The test used 51 different browsers. As far as I can see our fix will cause 16 of those browsers to change appearance for the tt, code, pre and source tags. It seems the problem with extra small text for those tags affects a whole bunch of browsers, but only for some of their versions and on some OSs. For instance, Firefox 2 on Ubuntu has the problem, but Konqueror 3.5 on Debian does not have the problem. It seems pretty random. Anyway, it seems our solution might solve it in all those browsers, since my hardcoded test code gives correct font in all of them. And my hardcoded test code doesn't seem to change the appearance at all in most of the browsers that does not have the problem. It does slightly change appearance for some of the browsers that does not need the fix, but that slight change is not a problem.

It seems very promising.

So, for starters I have now applied the fix for the tt tag alone. Let's see what happens.

--David Göthberg (talk) 13:55, 25 October 2009 (UTC)[reply]

This problem is essentially that some browsers have a dodgy default CSS for the <tt>, <code>, etc, elements? And that what you're doing here is to explicitly envoke the CSS that's the default for most browsers, as the site default for all browsers? If that's the case, and the changes work, I'll add the rule to shared.css if no one complains here. Happy‑melon 17:25, 25 October 2009 (UTC)[reply]

Happy-melon: Yes, that is more or less what we are doing here. But to be exact, the officially recommended CSS for tt tags is just "font-family: monospace;". And if I understand it correctly, some browsers then react badly to that. (I haven't tested if it literally is "font-family: monospace;" that makes those browsers choke. I should perhaps run a test just for fun.) But most browsers choose a sans-serif font for that, so we can code it as "font-family: monospace, sans-serif;" in most browsers, since it means no change for them. But fortunately for some reason it makes the buggy browsers choose a better font.

Or perhaps it is as you say, the buggy browsers use another default CSS than "font-family: monospace;" for tt tags. But in our early testing it seemed that just using "font-family: monospace;" didn't fix it. But I should perhaps test again, since I know more now.

--David Göthberg (talk) 17:54, 25 October 2009 (UTC)[reply]

Okay, I'm concerned that the problem isn't understood very clearly here. Could someone create a minimal test-case (like a few lines of HTML) that illustrates the problem? For instance, if you copy this into your URL bar, does it show a significant size difference?

data:text/html;,<!doctype html><p>Foo <code>barim</code> <code style="font-family:monospace,sans-serif">bazim</code>

On Ubuntu, in Chrome 4 and Opera 10, that displays at a consistent size, and there's no visual difference between "barim" and "bazim". In Firefox 3.0 and 3.5, "barim" is much smaller and "bazim" is the correct size, but "bazim" isn't displayed monospaced. I included the trailing "im" so it's easy to tell. Note that I've changed my font preferences in at least some of these browsers, so your results may vary.

In any event, I don't see the fix helping anything – where it makes any difference, it de-monospaces fonts, which is bad. The problem seems to be just that some browsers use bad default monospace fonts. I can't think of any conceivable way that this style rule could change anything for the better, except by removing monospacing. Can someone confirm that this actually gives them proper-size code that's monospaced? —Simetrical (talk • contribs) 18:46, 25 October 2009 (UTC)[reply]

I can confirm that with this change added to Common.css, <tt> is no longer monospace for me in Firefox. —Simetrical (talk • contribs) 18:48, 25 October 2009 (UTC)[reply]

It's monospaced for me in FF3.5. Happy‑melon 20:50, 25 October 2009 (UTC)[reply]

I have the new test results. It works perfectly. I let 48 different browsers load my Wikipedia test page User:Davidgothberg/Test59, by using browsershots.org plus my own browsers. All 48 browsers showed proper monospaced fonts, both for the <tt> tags and the <code> tags. Note that the <tt> tags now have our fix, while the <code> tags don't have the fix yet. 18 of the browsers had more or less "shrunk" <code>, <pre> and <source> tags. But all of those 18 now had proper sized <tt> tags! This means that the fix works for them, and that they all have loaded the updated Common.css. None of the 48 browsers show any problems with our fix. So I say our solution works perfectly. Well, I should admit there is one little quirk: Some of the browsers now get slightly too good looking <tt> tags, they don't have that rough old-school "teletypy" look anymore.

My testing also showed that using "font-family: monospace, sans-serif;" works, but only using "font-family: monospace;" does not fix it.

Simetrical: I can't tell if a text is monospaced by just looking at the word "bazim", so I think you are mistaken. Try using using this code instead to check:

data:text/html;,<!doctype html><p><code>iiiii<br>mmmmm</code> normal<br> <code style="font-family:monospace,sans-serif">iiiii<br>mmmmm</code> normal

--David Göthberg (talk) 03:19, 26 October 2009 (UTC)[reply]

Yes, that data URL shows up with the third and fourth lines not monospace. They look the same as the text "regular". This is Firefox 3.0 on RHEL 5. I see the same at User:Davidgothberg/Test59; tt is not monospaced, code is. This implies that on at least some browsers, your fix is broken, as I said. I strongly suggest that the change be reverted unless you can at least figure out why it actually works in some browsers – voodoo magic has a habit of blowing up unexpectedly. In theory, the change should do nothing AFAICT, since every browser should have a monospace font, and so should never have to fall back to sans-serif. If it does anything, you're relying on browser bugs, and you should make sure you understand precisely what those bugs are before doing that. —Simetrical (talk • contribs) 18:10, 26 October 2009 (UTC)[reply]

Simetrical: Well, as I mention above, I have tested this fix on 48 browsers on multiple operating systems, without problems. And some other users have tested it too. See details above. And you mention yourself that you have tinkered with the fonts in your browser. You demand that we know the exact inner workings of this bug, which amounts to that you ask us to study the source code of all the different browsers...

And at least for the <tt> and <code> tags I don't see the pressing need for them to be monospace on 100% of the browsers. It is more important that they get a font size that is actually readable on 100% of the browsers. And the <code> tags use a different background colour, so they would work almost as well even if they get the same text style as the surrounding normal text. Actually, I can't remember ever seeing any usage cases here at Wikipedia where those two tags needed to be monospace, they just need to look different from the surrounding normal text.

Of course, for the <pre> tags it will be more annoying if they get proportional text. Still, if the choice is between having monospace but in a size too small to read, or proportional in a size we can read, then I know which I prefer. And note, so far only your browser will have proportional font with the fix, while a whole bunch of the browsers we tested have too small font without the fix.

--David Göthberg (talk) 23:39, 26 October 2009 (UTC)[reply]

Just wanted to quickly add a link to my test page.

--Subfader (talk) 06:21, 26 October 2009 (UTC)[reply]

Subfader: Ah thanks! Your images nicely show how it looks without the fix. But your images doesn't show the <tt> tagged text. Had your test page been here on the English Wikipedia (instead of mediawiki.org) then I bet that the <tt> text would have proper size in your browsers now, since we have now deployed the fix for the <tt> tags.

But what is the really interesting part in Subfader's images is that they show that the tags look different in different skins, ouch. I hope our fix fixes it in all the skins.

--David Göthberg (talk) 11:06, 26 October 2009 (UTC)[reply]

I'll grant that it's probably something to do with my Firefox profile. With a fresh profile on my home machine it works as you say; I didn't test on my school machine. But I wasn't using the fresh profile. There are many thousands of browser version + settings + OS + random confluence of stars combinations out there – a lot more than 48. That's why we have standards, so you don't have to test a tiny number of configurations and hope that they happen by good fortune to be representative of the computers of everyone in the world.

I still think it's really not a good idea to deploy something like this without knowing how or why it works. The reason the fix works should be established before it's deployed.

And I don't see a background on <tt>, actually. —Simetrical (talk • contribs) 02:21, 27 October 2009 (UTC)[reply]

You don't seem to grasp that we can't establish the reason the fix works without reading the source code of all those faulty browsers. And we would also have to study why they fail on some OSs but not on other OSs, so we might have to read the code in the OSs that provide the fonts too. That would be a ridiculously big undertaking. And some of those OSs are closed source...

But I can tell you what I know, and what I can guess:

The officially recommended default browser CSS for <tt> and <code> tags is "font-family: monospace;". In this case we instead use the code "font-family: monospace, sans-serif;". And according to the official CSS standards, the browsers should then first try to use monospace font, and if they don't have a monospace font they should use a sans-serif font. And all browsers have (or at least should have) a monospace font. So not surprisingly all of the tested browsers did show a monospace font (except your browser). So we are following the standards, it is your browser which are not following the standards.

Now, why doesn't it work when we just use "font-family: monospace;"? Well, if you look closely at the default style some browsers use for <tt> and <code> then it isn't just a monospace font. Instead they use a slightly more rough looking and slightly smaller font, probably on purpose to make it look more "teletypy", more like old typewriter text. Note that many fonts aren't freely scalable, they aren't vector graphics, instead they come in fixed size steps. So my guess is that for some combinations of browser and OS, then the next smaller step (from normal text size) for that font is the too small size we are seeing. So it is simply an unlucky combination. Now, if we tell the browser to use "font-family: monospace;" then why doesn't it choose the normal monospace font instead of that special teletypy looking font? Well, the default CSS for those tags officially already is "font-family: monospace;", so that is probably the attribute registered to those tags in the DOM, since there is no CSS attribute called "teletypy-looking-font". So to the DOM handler it looks like we are telling it to set the style that those tags already have, so it does nothing. Thus not changing font.

But when we tell it "font-family: monospace, sans-serif;" it sees it is different from what already is registered to the object, thus it runs the font handling routine for that object. Which then causes the monospace font to be loaded.

This means that even if the teletype font was of a decent size it gets exchanged to the regular monospace font. And that is exactly what we see happen in many browsers: Our fix unfortunately makes the <tt> tags look a little too good in some browsers, they loose their rough teletypy look.

So there, that was my guess why our fix works.

--David Göthberg (talk) 04:08, 27 October 2009 (UTC)[reply]

No, it would not be a huge undertaking to figure out what causes the bug. You'd just have to fiddle around to see what triggers it, and possibly (especially in the case of open-source browsers) talk to some of the developers about it. It's a pretty routine thing. But never mind. I don't personally have the time right now to look into it very deeply. Whatever the case may be, <tt> is now almost indistinguishable from regular text in the browser I use at school, if that counts for anything. —Simetrical (talk • contribs) 01:24, 28 October 2009 (UTC)[reply]

The browser has an extra feature to allow the user to specify font scaling of monospace fonts; in webkit this is buggy as it selects the system based on the last font in the list. The internal font scaling seems to be size * (default monospace point size)/(default proportional point size). This can actually cause some humorous effect where your decreasing the proportional size, but the renderer wont go below 9px (see /skins-1.5/monobook/main.css comment) and the monospace font will actually increase in size (as does <span style="font-family:sans-serif,monospace">). — Dispenser 05:07, 27 October 2009 (UTC)[reply]

Where is this preference controlled? I don't recall ever seeing it. If it's only a WebKit problem, why is it showing up for Firefox too in some cases? And why would Firefox sometimes render sans-serif but usually not, when given font-family: monospace, sans-serif? —Simetrical (talk • contribs) 01:24, 28 October 2009 (UTC)[reply]

Okay, I found it in Firefox: Content → Fonts & Colors → Advanced... The existence of this feature actually does seem to violate CSS, because changing the font family shouldn't change the font size as well, or at least CSS doesn't explicitly permit that. One obvious thing to try would be tt { font-size: 1em }, but that doesn't work. Maybe there's some other way to game it, if we really want to.

Relevant link: Mozilla bug 175415, open since 2002. Ian Hickson apparently shares my attitude that this feature is broken and contrary to the CSS spec, but nothing ever got done about it. The reason it uses the rightmost font instead of the one actually used is because it's too expensive to figure out which is actually used all the time, apparently. The discussion there points to font-size-adjust, which might be worth looking at. It doesn't seem directly useful to us, unfortunately. I didn't find anything in WebKit's bug tracker.

Anyway, the fact that monospace text is smaller in some browsers appears to be a deliberate decision by browser vendors, based on the metrics of commonly-used default monospace fonts. If users want larger monospaced text, they can change it in their browser preferences. With my current font, the smaller-size text actually seems to look better, if anything. Wikipedia shouldn't mess with users' browser preferences. —Simetrical (talk • contribs) 01:53, 28 October 2009 (UTC)[reply]

Dispenser and Simetrical: Gah! I just wrote a looong message with more test results and analysis, and then suddenly I understood more of what you guys are talking about. And you are right, this is a result of the setting for the monospace font size in the browsers. I can now repeat the problem in my own Firefox 2.0 by using that setting. And the current fix we use then works on my browser too.

Unfortunately in some browsers the <tt> and <code> text become slightly hard to differentiate from normal text when we use our fix. So I think I now somewhat agree with Simetrical, Wikipedia perhaps shouldn't mess with users' browser preferences. If they use bad settings, then we perhaps shouldn't use voodoo to fix it for them. But I'll have to think more about this.

Anyway, since I have already written it and it doesn't contradict the above conclusion, here is my long message:

I have done more tests. Both of "font-family: monospace, sans-serif;" and "font-family: monospace, serif;" give the same results on all the 45 tested browsers, it makes <tt> and <code> text that are too small become larger. Using "font-family: monospace, monospace;" also gives that result, except for one browser. I'll explain below. (While as I have mentioned before, "font-family: monospace;" doesn't help.)

Dispenser: I assume you by "the list" mean the list of font families in for instance "font-family: monospace, sans-serif;", right? Then provided I understand you correctly: In my test run there were a Safari 4.0 and a Chrome 3.0 with too small <tt> and <code> text. What you are describing fits very well with my results for that Safari, but doesn't fit for that Chrome. But both are WebKit based. And it doesn't fit for Firefox related browsers.

In that Safari, when using "font-family: monospace, monospace;" the <tt> and <code> text remained too small. And using "font-family: sans-serif, monospace;" caused tiny sans-serif proportional font.

However, the Chrome 3.0 instead behaved just like the Firefox related browsers: Using "font-family: monospace, monospace;" the <tt> and <code> text became close to normal sized. And using "font-family: sans-serif, monospace;" gave normal sized sans-serif proportional font.

Dispenser: So your model only fits for some of the WebKit browsers. For the other browsers there is something other going on, perhaps something like what I described above. Note that your model says that using "font-family: monospace, sans-serif;" or "font-family: monospace, serif;" should work on all browsers that fits your model. (Work as in giving us decently sized monospaced text.)

So basically, using "font-family: monospace, sans-serif;" still seems to be a decent option. (But we can just as well user the shorter "font-family: monospace, serif;".) However, Simetrical is right in that there are several concerns too. So I don't know if we should use the fix or not.

--David Göthberg (talk) 05:46, 28 October 2009 (UTC)[reply]

This is duplicated:

div.NavFrame + div.NavFrame {
    border-top-style: none;
    border-top-style: hidden;
}

But I have no idea how it should be fixed. Any idea? Locos epraix ~ Beastepraix 01:30, 27 October 2009 (UTC)[reply]

There is a strong consensus on the Village Pump to remove the donation banners until they are "fixed." The CSS addition to remove the banners is:

div.notice-all {display:none !important;}

Thoughts? Brandon (talk) 08:04, 11 November 2009 (UTC)[reply]

• Strong Support, the banner is just embarrassing, the sooner someone takes the plunge and gets rid of it the better. Lankiveil ^{(speak to me)} 08:25, 11 November 2009 (UTC).[reply]
• Strong support for removing the banner. Wikipedia is childish in many respects, but this banner even more so. Wikipedia doesn't deserve this. Hans Adler 08:28, 11 November 2009 (UTC)[reply]
• I've never seen such a strong consensus anywhere on Wikipedia. As it appears that the concerns are not even being taken in consideration, this proposal has my tentative support. — Martin (MSGJ · talk) 08:30, 11 November 2009 (UTC)[reply]
• Support. Too big, too childish, not clear enough in meaning (sounds like a slogan/motto, not an invitation to donate). Just awful. Hide until it is changed to something acceptable. Rd232 ^talk 08:47, 11 November 2009 (UTC)[reply]
• Support Vivé la revolución! </tongue in="cheek"> --Cybercobra (talk) 08:55, 11 November 2009 (UTC)[reply]
• Support This banner has been a bad idea from the start. Remove move it now before its too late. Seddon ^talk|^WikimediaUK 09:19, 11 November 2009 (UTC)[reply]
• Support Incredibly obnoxious and looks like a /b/ attack. -Jeremy ^{(v^_^v Stop... at a WHAMMY!!)} 09:22, 11 November 2009 (UTC)[reply]
• Support, because, damn.—S Marshall ^Talk/_Cont 09:43, 11 November 2009 (UTC)[reply]
• Exterminate. MER-C 09:57, 11 November 2009 (UTC)[reply]
• Let it burn!. 189.105.13.116 (talk) 10:16, 11 November 2009 (UTC)[reply]

Given the volume of opposition here (including VPR) and Meta ([9]), I suggest taking stock at 12.00 UTC and hiding it then if no substantial opposition to hiding emerges. Then there'll be the question of "what happens next". Rd232 ^talk 09:32, 11 November 2009 (UTC)[reply]

Hiding it would arguably go beyond our remit, and so I would suggest a last-ditch attempt to discuss the issue with the WMF before we take such a drastic step. They need to raise money, that is clear. However the editors here are just as important to the success of Wikipedia and they can not and must not use advertising techniques which we find so amateur and inappropriate. We need dialogue, but this proposal remains viable as a last resort. — Martin (MSGJ · talk) 09:57, 11 November 2009 (UTC)[reply]

Discuss how? What would be the contact route? And who's going to do that? Rd232 ^talk 10:12, 11 November 2009 (UTC)[reply]

Cary Bass would be that person. Seddon ^talk|^WikimediaUK 10:25, 11 November 2009 (UTC)[reply]

On the other hand, this is supposed to be a ten-week-long campaign (cf. m:Fundraising 2009/Timeline). I'm not sure delaying a week in order for better banners to be made is an unreasonable thing to do. --MZMcBride (talk) 10:00, 11 November 2009 (UTC)[reply]

Absolutely. This is an annual fundraising drive, a delay of a week to improve it when it's this wrong is entirely justifiable. Rd232 ^talk 10:10, 11 November 2009 (UTC)[reply]

Heck, they can extend it for a week at the end to make up for a lost week now, its no trouble at all. These banners need to go, theyre tarnishing Wikipedias reputation. 189.105.13.116 (talk) 10:16, 11 November 2009 (UTC)[reply]

Hello all,

our decisions which banners to run are primarily based on performance. So far, "Wikipedia Forever" appears to be performing on about the same level as other banners which we ran last year, but we'll run the full metrics soon. In any event, donor response is almost always completely separate from community response; community members hating a banner tells us very little about how well it works or how the general public perceives it. (That doesn't mean that anything which performs well is acceptable from our point of view, of course.)

We'll observe community feedback, as well as feedback from the general public and our donor community. This isn't the only banner we'll run this year - most importantly, we'll run another personal appeal from Jimmy, which performed at about 10 times as well as any other banner last year. As always, removal of the site-wide fundraising messages by community members isn't OK; please be patient and click the "hide" link or remove the banner through your personal user style if you really despise it.--Eloquence* 10:30, 11 November 2009 (UTC)[reply]

By the way, if you want to help us create mock-ups for alternative banners, as every year, you're more than welcome; I've created m:Fundraising 2009/Alternative banners as a central space for doing so.--Eloquence* 10:30, 11 November 2009 (UTC)[reply]

Ignoring the hundreds of complaints isnt ok either, I will fully support any administrator who removes it on any project. I donated last year but I'm not doanting again untill this thing is gone. If its performing on about the same level as the other banners then why not use the other ones? We're paying a PR firm to developed something that has not increased performance over previous years and is making Wikipedia look very very bad. Tha banner gives a completely wrong idea about who we are and what we are doing, it needs to go.! Acer (talk) 10:36, 11 November 2009 (UTC)[reply]

As I said, we'll have detailed comparison metrics soon, and will make our decisions based on that. Please be patient. Can you clarify how the current banner gives a "completely wrong idea about who we are and what we are doing"? Do you feel that is true for the donation landing page as well, or only for the banner?--Eloquence* 10:40, 11 November 2009 (UTC)[reply]

Erik, quite simply, you're missing the entire point. No graph or metric in the world is going to make these banners acceptable to the community. It's not the banner performance that's the issue here, it's the fact that people's hard (volunteer) work is being placed under such a banner. You really would do well to read the comments here: Wikipedia:Village pump (proposals)#Abolish the silly headers. If you read the community's comments and still can't figure out what the issue is, then there's really no further need for you to post here. --MZMcBride (talk) 10:44, 11 November 2009 (UTC)[reply]

You're an admin, Erik - you can respect the community's views on this and turn off the message until it can be replaced with something that performs equally well but isn't ludicrous. Or if you have other messages ready to go, just ditch it now, replacing with another. Rd232 ^talk 10:49, 11 November 2009 (UTC)[reply]

As I said, please be patient so we actually have the full data relative to last year. If you click Special:Preferences and "Gadgets", there's a little option "Suppress fundraising banner" that you can use if you find it too annoying to wait.

I'm watching Twitter comments as well. I see a lot of comments from Wikipedians hating the banner, but I also see the first comments from donors and the public, including positive ones: [10] [11] [12] [13]. It's important to recognize that the Wikipedia community has a default sensitivity against anything intruding into the everyday experience of Wikipedia. Every single fundraising banner we've ever run has provoked varying levels of outrage, including threats to disable the banner for everyone, demands to go back to the drawing board, etc.

So we have to operate on the assumption that any banner that works is going to offend people inside the community, because that's held true for every banner we've ever run. That makes it difficult to distinguish "normal" unhappiness with fundraising messages from extraordinary unhappiness. It's also true that the kick-off of the fundraiser is always the loudest time, and we've decided to kick things off with an unquestionably loud/bold banner. So I'm not surprised that there's a particularly strong reaction, and can only reiterate my call for patience. More specific feedback also helps: there's clearly a strong aesthetic component (I'm not particularly fond of all-caps myself and have asked to ensure we try regular case banners as well), but also a messaging component. The messaging this year is focused on preserving and protecting Wikipedia for future generations: do you feel that message conflicts with your view of Wikipedia, and if so, why?--Eloquence* 11:04, 11 November 2009 (UTC)[reply]

  THAT   NICE   ELOQUENCE   SO   GOOD   YOU   NO   VERB   NON   STANDARD   ENGLISH   US   SPECIFIC   ENGLISH   BREAK   CSS   WIKIPEDIA   LOGO   OTHER   PROJECTS   OVER   SPACE   MOST   CAMPAIGN   DEMEANING   ARROGANT   SLOGAN   CLEARLY   MONOCULTURAL   SLOGAN   FOREVER   FIFELFOO   FOREVER   TALK   FOREVER   10:53, 11 November 2009 (UTC) ( INCORRECT:   FOREVER )[reply]

(outdented reply )I'm ok with the donation page, Wales coud've said something abit more inspiring but thats besides the point... Now the banner, well, I've always thougt we should work to make Wikipedia a credible and at least generally trustworthy and usefull source of information, and I beleive thats the light in which we should try to cast ourselfs and the project. The current banner does not reflect this, its makes us look amateurish... Its something i'd expect from a a highschooll cheering squad. Can you imagine Britannica ever splashing "BRITANNICA FOREVER!" in a huge font all over their website? Acer (talk) 10:56, 11 November 2009 (UTC)[reply]

I've actually seen Britannica do much worse, including displaying an ad for extermination services next to their article about Auschwitz, but that's beside the point. I think switching from all-caps to regular case should address a major aesthetic concern at least, no?--Eloquence* 11:04, 11 November 2009 (UTC)[reply]