This is an archive of past discussions about MediaWiki:Common.css. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Maybe its time whoever is responsible for adding the banners provides some possibilities befor ehand and then make a decision based on a consensus. There are much better ways to ask for donations then a juvenlie banner in capital letters.Himalayan22:18, 11 November 2009 (UTC)
Consensus won't do it, but consultation will. The ham-fisted strategy here convinces me there is a room of people somewhere who are not talking to anyone outside the room and hence depriving themselves of feedback that would have improved their efforts and saved themselves a lot of embarrassment. Casual Wikipedia users who are friends of mine and have seen the banner are either confused or amused by it (and only one of them realised you could click on it, or that it was a call for donations). Orderinchaos01:16, 12 November 2009 (UTC)
I'd love to know what consultation process, and what user testing, produced this strategy / those banners... Perhaps it really was just people in a room. Rd232talk01:29, 12 November 2009 (UTC)
We can force the Foundation to allow for the consensus process to take place if we elect Board members who respect community input. —Finn Casey***19:16, 12 November 2009 (UTC)
Or if every member of the community just blatantly reverts the foundations decisions. The consensus and effort of several hundred users can easily overwhelm that of a select handful of foundation users. What's the foundation going to do? Ban all of its editors
Wikipedia is public property now, and has been for some time, regardless of what the foundation "thinks". That's why they have donation banners up. - ʄɭoʏɗiaɲτ¢20:53, 22 November 2009 (UTC)
In order to fix this problem, Ms2ger wrote "I think this would be better solved by adding i i { font-style: normal; } to MediaWiki:Common.css." I don't know what this means (I don't understand Common.css), but can someone who understands this suggestion please implement it here? Thanks. Eubulides (talk) 05:19, 14 November 2009 (UTC)
The issue is that the parser converts the testcase into
The book's title is <i><a href=...>Fould Anchors: The <i>Constellation</i> Question Answered</a></i>
While the example of correct behaviour are rendered as
The book's title is <a href=...><i>Fouled Anchors: The</i> Constellation <i>Question Answered</i></a>
The former includes nested <i> tags, while the latter avoids such. The CSS that Ms2ger is proposing tells the users' browsers to "treat an <i> tag within another <i> tag as normal text". Sounds like a reasonable suggestion. Happy‑melon12:05, 14 November 2009 (UTC)
Running that wikimarkup through a clean install with no Tidy produces the HTML I gave in my second example (the 'correct' version); so the fragment renders correctly even without CSS modification. Tidy is somehow managing to mangle totally correct HTML into the mess we now see. How untidy... Happy‑melon13:45, 14 November 2009 (UTC)
Tidy is funny because it works remarkably well in some areas and still has plenty of "wtf" behavior. It certainly can't be disabled, that breaks the site remarkably. (Anecdotally, it was disabled at the Foundation wiki and we're still finding the various ways it breaks everything.) In an ideal world, HTML Tidy would be fully merged into MediaWiki core properly and then customized to remove some of the bad behaviors. At least that's my understanding of the situation. --MZMcBride (talk) 14:08, 14 November 2009 (UTC)
That, or the MediaWiki parser should be replaced by one that directly emits proper HTML without any need to try to patch it in a second pass. Heh. Amalthea01:44, 16 November 2009 (UTC)
You can use
''[http://www.dt.navy.mil/cnsm/docs/fouled_anchors.pdf Fouled Anchors: The <span style="font-style:normal">Constellation</span> Question Answered]''.
I believe this is perhaps a good time for a face palm. Look at what he quoted. "border-top-style" is set twice in a row, thus negating the first set. He is uncertain of the intent, so he is asking which of the two should be deleted. --Cogniac (talk) 23:34, 19 December 2009 (UTC)
Indeed. IE8 and below seem not to recognize "hidden," so IE will catch just the "none" and drop out while all other browsers catch the "none" and then overwrite it with the "hidden." --Cogniac (talk) 15:08, 21 December 2009 (UTC)
MediaWiki messages
We need a single place to announce discussions about MediaWiki messages, since the "MediaWiki talk:" pages are not watched much. If you are interested in this, see Wikipedia talk:MediaWiki#MediaWiki messages.
Oh, and please don't start a discussion here, instead follow that link.
We now have the new central discussion page for MediaWiki interface messages (other than the CSS and JavaScript pages): Wikipedia:MediaWiki messages. So gentlemen, if MediaWiki interface messages interest you, consider adding that page to your watchlist.
As a result of the discussions linked above I made it so .css and .js pages in MediaWiki space now show their editnotice (if there is one) already when just viewing the script pages. See MediaWiki talk:Clearyourcache#Show editnotice for more on that.
In the DE-Wikipedia there is a template arabic script, and in the DE-common.css there is an entry that belongs to the class spanAr defined in this template. I can't find a counterpart in the EN-Wikipedia. Is there one? It's for choosing an appropriate font for the arabic script, either commonly, or overwritten in the user specific CSS-files in case of need. The fonts listed in the DE-common.css are 'Arial Unicode MS','Scheherazade','Code2000','DejaVu Sans'. 'Lateef' (the "brother"-font of 'Scheherazade') is useful, too. -- Sinnierer (talk) 15:14, 20 December 2009 (UTC)
The template used in english wikipedia is {{Script/Nastaliq}}. It has no rules defined in common.css but it defines its own stylke rules template-inside and those are: 'Jameel Noori Nastaleeq','IranNastaliq', 'Nafees Nastaleeq', 'Nafees Nastaleeq v1.01', 'Pak Nastaleeq', 'PDMS_Jauhar'. Locosepraix ~ Beastepraix16:38, 20 December 2009 (UTC)
OK, it's another solution in de EN-WP. Relating to the fonts, {{Script/Nastaliq}} is more specialized. Seeing more templates like Template:Script/...', I think I'll create a new template Template:Script/Arabic. -- Sinnierer (talk) 19:54, 20 December 2009 (UTC)
@ The CSS-experts: I've defined: class="arabic-international" in {{Script/Arabic-international}}. Overriding that in my user-CSS-page doesn't work. What's wrong with the template-code? It should work like the class IPA for users. Is the best solution an entry in the Common.css? -- Sinnierer (talk) 13:23, 21 December 2009 (UTC)
I'm withdrawing my question what's wrong. Now it's OK. There was a delay because of the server cache. Clearing the browser cache was not enough. -- Sinnierer (talk) 14:43, 21 December 2009 (UTC)
Reflist font size
Mozilla makes {{reflist}} footnotes look smaller than IE does. In fact, it's painfully small. (I've 20/20 in one eye, a hopeless blur in the other).
I've tested and found that 93% font size in Mozilla results in a slightly larger size, and in IE 93% results in the same-as-current size (90%). Also, 93% looks the same size in Mozilla as in IE (and smaller than 100%). Example:
100% The quick brown fox jumped over the lazy dog.
93% The quick brown fox jumped over the lazy dog.
90% The quick brown fox jumped over the lazy dog.
I suggest that the reflist template use 93% font size instead of 90% font size, or somewhere from 91% to 95% if 93% doesn't help in other browsers. I've found that 91%, 92%, 94%, & 95% look the same size as 93% in Mozilla & IE. So if you have other browsers, you can check here:
100% The quick brown fox jumped over the lazy dog.
95% The quick brown fox jumped over the lazy dog.
94% The quick brown fox jumped over the lazy dog.
93% The quick brown fox jumped over the lazy dog.
92% The quick brown fox jumped over the lazy dog.
91% The quick brown fox jumped over the lazy dog.
90% The quick brown fox jumped over the lazy dog.
Then some justification was offered of the current settings as being in order to keep the font sizes the same across browsers though, at 90%, they clearly are not the same across browsers, as the screenshots showed and as anybody with the two most common browsers Firefox & IE can see. 94% would be more readable and it will be pretty much the same amount smaller than 100% as shown on most browswers.
Then the discussion simply petered out without any explanation of why reflist uses a font size so difficult for many people to read.
I've gone through the archived discussions of font size at Template talk:Reflist and they are unhelpful. Various people say that the font size is too small. Some think that with more than 88% the columns look "too crowded" but that's pretty subjective and what does it matter when many average readers have trouble reading it at all in Mozilla which is, what, like 40% of broswers now? And nowadays people increasingly use lap tops with small high-resolution screens. The tiny font is a nuisance. Looking at the numbers above, I suggest that the font size should be set to 94%. 94% will be more readable and, again, it will be pretty much the same amount smaller than 100% as shown on most browswers. The Tetrast (talk) 23:46, 2 December 2009 (UTC).
I know many who have problems reading web pages because font sizes are to small. The goal of Wikipedias is to make knowledge available to everyone, so shouldn't it be our primary goal to make the articles as accessible as possible? As far as I know there is no reason for having smaller font size in the reference section in the first place. —Apis (talk) 00:12, 3 December 2009 (UTC)
I agree. Also, the majority of people probably never fiddle or even learn to fiddle with their browsers' default font size at all, or bother to use the zoom option. The Tetrast (talk) 00:17, 3 December 2009 (UTC).
And even if they did, wouldn't it make more sense for those who prefer the small font to change their settings? that way no one gets excluded "by default". —Apis (talk) 00:21, 3 December 2009 (UTC)
There doesn't seem to be consensus just yet. Note the class is called references-small, and increasing the fontsize would contradict that class' name. You can however set the fontsize on your own monobook.css. — Edokter • Talk • 10:49, 6 December 2009 (UTC)
I (and as I perceive it, The Tetrast) doesn't want to change it because of what we like, but because it makes the text difficult to read. It's not just bickering about aesthetic preferences, it's about making wikipedia accessible to everyone. Doesn't that matter?
The class name could be changed and you can set a small fontsize in your own monobook.css as well. For what reason is it small? —Apis (talk) 04:37, 7 December 2009 (UTC)
I agree with Apis. Nobody has even tried to counter either the arguments that Apis & I have made or my review of the archived pro-tiny-font arguments which were flatly mistaken. Now somebody claims that "it's small for a reason" but fails to articulate the reason and I'm not surprised. Well, there's not much that Apis or I can do, but you in the future who read this, note that you will need to do more than muster winning arguments in order to get an unsolipsistic and user-friendly policy into place. The Tetrast (talk) 00:45, 16 December 2009 (UTC).
The reason is to reduce the space the refs occupy on a page. And that is significant. I'm all for accessibility. (Hell i fixed alt for images in the mediawiki core), but accessibility does not trump usability in my opinion. We also have < 1.0 text in many infoboxes, at the bottom of the skins, as warnings in the edit interface and I don't know where else. We should trust that people made conscious decisions there. The opposite of that would then be that if we bring 0.9 text to 1.0 that we should also bring 1.0 text to 1.1 or more. That is of course unusable. How about we create an accessibility gadget that lets loose all kinds of accessibility improvements that not necessarily everyone of our readers would enjoy ? —TheDJ (talk • contribs) 10:59, 16 December 2009 (UTC)
Thank you all for the responses, and thank you, TheDJ, for your work on accessibility and other things. But it is incorrect to say that we're talking about bringing "0.9 text to 1.0 text." We are not talking about that. Reflist footnote fontsize in browsers other than Internet Explorer is around 0.85 in terms of typically resultant line length (see table below), and we're talking increasing reflist footnote fontsize, in effect, from 0.85 to 0.93 in terms of typically resultant line length, which is that which Internet Explorer already produces with the "90%" reflist fontsize setting and where IE would stay with a "94%" fontsize setting since IE fontsize settings from "90%" to "97%" all produce the same result. The effective 0.93 result still increases the savings in space which double columns of footnotes tend to bring even at 1.0 of font size. Even in IE, which fails to produce reflist's double columns, the effective 0.93 result saves space. Essentially we're talking about increasing reflist footnote font size for most browsers —from 8pt (typically 85% in terms of line length) —to 9pt (typically 93% in terms of line length) (see table below), where, for IE, it is now and would stay. Main text size is 10pt and there will be no reason to bump it higher if reflist footnote font size is increased, in effect, to 9pt. (94% works best for 0.93 across most browsers, see comparisons above in this talk page section). As said, splitting into columns already often saves space even at 1.0 of font-size. It saves consistently more space at 0.93. It saves consistently still more space at 0.85 but at a significant cost of legibility, a cost which increases amid masses of footnote text. A footnote section is typically denser than an infobox, which contains tidy snippets. I don't seek the same for infoboxes. The effective 0.85 is more bearable in infoboxes and an effective 0.93 implementation would lead to problems. The effective 0.85 is more bearable in infoboxes, which—unlike footnotes—typically have isolated and short single or double lines of text, separated by large padding or spacing of cells. Still, an effective 0.93 would be better in infoboxes, but implementation of it could cause problems when so many infoboxes have been designed for an effective 0.85—in IE & other browsers alike—for most of their text. So, to sum up, an increase of reflist fontsize setting to 94% would: —still save space, —result in greater consistency across browsers in terms of each browser's 100% size (see comparisons above in this talk page section), and —preserve footnote legibility for the general reader, who increasingly often uses a laptop and increasingly often uses Firefox or other non-IE browser. See above in this talk page section for comparisons of browser font size settings. See table below for comparisons of point-size settings to percentage-size settings and for comparisons of fontsize-dependent line widths. The Tetrast (talk) 20:39, 28 December 2009 (UTC). Corrected typo. The Tetrast (talk) 20:40, 28 December 2009 (UTC). Slight revision. The Tetrast (talk) 21:07, 28 December 2009 (UTC). Re: "accessibility does not trump usability in my opinion": That can't be meant in the absolute sense that accessibility issues never trump usability issues, and so is likely meant in the sense that an accessibility issue sometimes doesn't trump a usability issue. E.g., the idea that it's good to increase the likelihood that a whole footnotes section will fill no more than one screen, and the idea that it's good to decrease the number of sheets that might be printed out from an article. I'm not sure what other usability issues there are. Anyway, we're talking about trade-offs. You already get increased usability with 94%-fontsize, 9pt, footnotes, especially with double columns. Font size effectively 0.85, 8pt, is overdoing it on size reduction - the trade-off tips too far against accessibility. Note that Answers.com, where they weigh accessibility vs. usability with a profit-sharpened eye, has stripped out the tiny font size from the footnotes in their versions of Wikipedia articles http://www.answers.com/topic/scientific-method#Notes_and_references. I'm not saying that Wikipedia should look like Answers.com all the time or act as though its motive were profit, and I generally prefer Wikipedia's look. But 8pt is seriously small for footnotes that are sometimes dense and are actually meant to be read. 8pt is for little standard notices such that one wants to keep them from distracting the reader from anything else. The Tetrast (talk) 21:42, 28 December 2009 (UTC).
font size 2
The quick brown fox jumped over the lazy dog.
font size 1
The quick brown fox jumped over the lazy dog.
10pt
The quick brown fox jumped over the lazy dog.
9pt
The quick brown fox jumped over the lazy dog.
8pt
The quick brown fox jumped over the lazy dog.
100%
The quick brown fox jumped over the lazy dog.
94%
The quick brown fox jumped over the lazy dog.
91%
The quick brown fox jumped over the lazy dog.
90%
The quick brown fox jumped over the lazy dog.
In Firefox, 90%=85%. In IE, 90%=94%=97%
88%
The quick brown fox jumped over the lazy dog.
85%
The quick brown fox jumped over the lazy dog.
10pt =* 9pt =* 8pt =*
The quick brown fox jumped over the lazy dog.
Width: 21.06em. Range: 21.02–21.09
The quick brown fox jumped over the lazy dog.
Width: 19.64em. Range: 19.6–19.67
The quick brown fox jumped over the lazy dog.
Width: 17.91em. Range: 17.87–17.94
Box widths are sensitive to variations in same or previous column.
*= in Firefox 3.0.16, Windows 2003 XP, my HP laptop pc. In IE8.0.6001.18702 (Windows 2003 XP, my HP laptop pc), the width-defined boxes are 2–3 screen pixels wider than the text-dependent boxes.
Promised discussion of height times width. Note, using del & ins tags, I've made a few corrections to my comments above. Now in the table below I go to a bunch of trouble to figure out what the height numbers could be in calculating resultant size reductions, just in case they turn out to be surprising. They turn out not to be so surprising.
Make sure that browser window is wide enough to avoid div-height changes (subtle or obvious) in table. Gray boxes are div backgrounds, not the container cells' backgrounds. Not the cells but only the contained divs have individual styles (font size, line height). Reason for keeping font size constant in later columns is that line-height in em varies with font size but what we seek here are em-size ratios (as info collateral to the line heights expressed in px) between line-heights, but ratios independent of font size variation.
Row settings
Uses row settings
Uses row font-size
Min line height em w/ 10pt font
Max line height w/ 10pt font
Row font-size: 10pt Row line-height: 1.5em Row of resultant equal div heights*
The quick brown fox jumped over the lazy dog.
Div line-height is 19px
Div font-size is 10pt & line-height = 1.42em
Div font-size is 10pt & line-height = 1.43em
Row font-size: 9pt Row line-height: 1.5em Row of resultant equal div heights*
*In Firefox 3.0.16, Windows XP, my HP laptop pc. Looks the same in IE8.0.6001.18702 (Windows XP, my HP laptop pc).
Whew. Okay. So: 94.7% & 94.4%. Versus 84.2% & 83.9%. So let's say, 94.5% versus 84%. For typical effective 9pt size, it's 93%*94.5%= approx. 87.9%. For typical effective 8pt size, it's 84%*84.5%= approx. 71%. Since there will be some variation across other browsers, might as well round 87.9% up to 88%. So I'm advocating, for the sake of legibility (accessibility), acceptance of space reduction to 88% instead of space reduction to 71%. You already have reduction to 88% in IE, around half of all people's browsers, and 71% only elsewhere. That doesn't take into account space reduction which tends to be achieved through double columns, but which you don't achieve with IE, which doesn't do the columns. So, again to sum up, an increase of reflist fontsize setting to "94%" would: —still save space; —result in much greater consistency across browsers in terms of each browser's 100% size (see comparisons above in this talk page section), instead of the current typical effective 9pt in IE and 8pt elsewhere; and —preserve legibility of footnotes—which are often neither bare citations nor, as in infoboxes, tidy snippets, half of them bolded—for the general reader, who increasingly often uses a laptop and increasingly often uses Firefox or other non-IE browser. You do, at some point, take legibility (accessibility) into account; otherwise you could shrink reflist font size to, say, 50%, and achieve total space reduction (HxW) to around 25%. 71% seems attractive, but it tips the balance too far against legibility, accessibility. —You could also reduce the line-height by another tenth of an em, and make up for some of the reduction lost by 94% versus smaller font sizes. —Moreover, you could simply make an option: "small" ("94%" setting) and "smaller" (with a setting of "88%" or "89%" — not "90%" since IE renders that the same as up to "97%" and larger than other browsers do). Right now you have a package deal. If an editor wants foonote columns at least in non-IE, s/he has to settle for 8pt font size in non-IE. Please at least give editors a choice. The Tetrast (talk) 22:42, 1 January 2010 (UTC).
Added note, a reminder. The current reflist font-size setting, which in non-IE results in typical effective 8pt or 0.85 of font size, is not "85%" but instead "90%". That's why I'm talking about setting the "smaller" size to "88%" or "89%" - it still means, in effect, typically 8pt or 0.85 of font size across various browsers, but also in IE (instead of the current typical resultant 9pt or 0.93). Likewise "94%" is chosen to achieve typical effective 9pt or 0.93 of font size across various browsers including IE but also others such as Konqueror 3.5 Ubuntu 6.06. See comparisons way up earlier in this talk section. The Tetrast (talk) 23:15, 1 January 2010 (UTC).
In the previous discussion (linked above), it was mentioned that ".references-small is being used in more places." Where else specifically is it being used? -- Quiddity (talk) 20:24, 15 December 2009 (UTC)
Secure links padlock
Currently https links such as links to the secure server use a yellow padlock , but when there are many secure links on a page the yellow padlock becomes too overwhelming. So I would like to change to a blue padlock instead, which matches the external and secure link colour and the colour of the other external link icons .
/* Blue instead of yellow padlock for secure links. */#bodyContenta.external[href^="https://"],.link-https{background:url("http://upload.wikimedia.org/wikipedia/en/0/00/Lock_icon_blue.gif")centerrightno-repeat;}
Seems like a fine idea to me. I will note that url() usually seems to use quotes of some kind (or at least most of the examples I've seen do), but I don't think it makes a difference. Even the examples at w3.org seem to be mixed.... --MZMcBride (talk) 14:49, 23 December 2009 (UTC)
r60320. Not sure if it'll stick, but if it does, it's a much easier way of implementing this. Although the code above would still be useful until the next scap. Great idea, DG. Happy‑melon15:33, 23 December 2009 (UTC)
Thanks guys.
Oops, I partly screwed up. Adding this code to MediaWiki:Common.css broke it for some skins, since those skins don't use a padlock and thus don't have the padding needed for the padlock. So I moved the code to MediaWiki:Monobook.css and MediaWiki:Vector.css. I'll investigate the other skins later. I just did a run at browsershots.org and this seems to work fine in all browsers. (Which is good, since I am reusing the MediaWiki code for loading the padlock.)
MZMcBride and Edokter: Ah right, using quotes seems more correct.
Happy-melon: Oh! Yeah, updating the image in MediaWiki itself seems the best approach in the long run. Here's a link to the padlock used in MediaWiki, when that version of the padlock has become blue, then we can remove my code from MediaWiki:Monobook.css and MediaWiki:Vector.css etc.
DG, it looks like the icon used in Vector is different, it's in .png format ([1]). It looks like the png version is preferred. Could you possibly do a .png version of the blue padlock? Happy‑melon16:36, 23 December 2009 (UTC)
Happy-melon: Yeah, I too just noticed that the Vector skin uses another padlock. I guess the usability project people will be annoyed that we changed their padlock, but I think that padlock doesn't look as good and it is even hard to see that it is a padlock. But the old gif padlock is a bit rough, I'll see if I can make a better version and I'll present that one to you guys here. Anyone else can of course make and suggest a better version too. I think it should match the other external link icons .
I agree we can make a transparent png version of File:Lock icon blue.gif. But I don't have any image editor that can handle transparent PNGs on my OS, so one of you guys will have to make and upload that one. But since all web browsers still handle gifs I think we can wait with that. (At least wait until I have made a better version in gif format.)
I Do not oppose either one. If you update the original though, we may need to change all the CSS URLs to point to the new cached version (on all projects). — Edokter • Talk • 19:18, 23 December 2009 (UTC)
FWIW, here's the vector padlock shifted to blue File:Lock icon blue.pngFile:Lock icon blue.png. It's not particularly pretty though, and oddly enough it only used hard transparency with the soft white edge built in, which makes it rather useless on dark backgrounds anyway. What's the license of the vector padlock, by the way? If anyone knows, could you fix the license on the file page? Amalthea20:38, 23 December 2009 (UTC)
Edokter: I assume you mean the original yellow padlock? The MediaWiki system CSS files like http://wiki.riteme.site/skins-1.5/monobook/main.css loads the padlock by using this code: "url(lock_icon.gif)". And if/when Happy-melon's update to the MediaWiki default padlock is deployed, then the new padlock will be on the same address. So the CSS files on the other projects won't need to be updated. But right, the server admins might have to do some operation to drop the old version from the caches.
I have updated File:Lock icon blue.gif to somewhat softer colours, more like the old yellow padlock. That makes it less dominant next to the links. So this is now the version I prefer. The shiny version File:Lock icon blue shiny.gif doesn't look enough much like a padlock to me, sometimes when I look at it it kind of looks like a handbag or a person instead. So unless any one else has any more points of view, then I feel finished.
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.
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.
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?
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.
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)
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)
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.
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‑melon17:25, 25 October 2009 (UTC)
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.
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?
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)
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
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)
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.
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.
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.
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.
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)
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">). — Dispenser05:07, 27 October 2009 (UTC)
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)
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)
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.
into my User:DavidBiesack/monochrome.css, and with Chrome 4.0.249.25 on Windows XP SP2 (32 bit) I still see pre text as much smaller than surrounding text on Wikipedia, whereas <tt> and <code> appear at a normal size. (Would it help to upload a screenshot?) --19:54, 16 December 2009 (UTC)
Biesack: It should be /monobook.css, not /monochrome.css. I moved the page for you to fix it, I hope you don't mind? Now all you have to do is to bypass your browser cache and you should see the fix.
And thanks for your report here. Your report confirmed that our fix works in your browser, since you see that we have fixed it for the <tt> and <code> tags.
Ah, silly me. With this correctly in my /monobook.css the <pre> text on this page displays with the correct font size. However, the text on /monobook.css is still quite small; see screen shot at right. (this was after clearing my cache/refreshing/?action=purge] Does that use a different CSS style? --DavidBiesack (talk) 15:14, 21 December 2009 (UTC)
Ouch! You are right. Thanks for pointing out that I missed this case.
Yesterday I added the fix for the <pre> and <source> tags in the global .css files. I was just going to say that "the code you see on your .css page isn't <pre> tagged, but <source> tagged text". But taking a closer look I see that MediaWiki doesn't exactly use <source> tags for the code in .css pages, but yet another notation. I will figure out how to code the fix for the .css pages. Thankfully I too see the bug when I use my Firefox 2.0 and the Vector skin, so I can do the testing myself. The bug is visible in .css pages both in User and MediaWiki space.
Biesack: I changed the code in MediaWiki:Geshi.css so the fix now also covers .css and .js files shown in User and MediaWiki space. So bypass your browser cache and your /monobook.css page will have normal text size.
This can happen even if the user has correct settings in his browser. I just noticed that when I use the vector skin, then the <code> and <pre> tagged text becomes really tiny. And that's in spite that I have the correct text settings in my browser (and looking fine in the other skins), and even though there is nothing in any of the vector CSS files that should cause this. So this is indeed a browser bug, it is not the users' fault. I see the problem in my Firefox 2.0, but not my Opera 9.02, so it is not a fault in the vector CSS.
The <tt> tagged text looks fine in the vector skin, so our fix is working. (And I have just tested, our fix will also work for the <code> and <pre> tags in the vector skin.)
We have now had the fix deployed for the <tt> tag for one month, and it seems to be working well. So I would like to now deploy the fix for the <code> tag and later on for the <pre> tag and the <source> tag.
I added this fix for the <code> tags on 26 November. And today I added the fix for the <pre> tags. I will fix the <source> tags when I have investigated them further, they have much more complex classes.
The <source> tags were easier to figure out than I thought. Here's the code to fix them:
/* Fix so <syntaxhighlight lang=""> tags get normal text size also in some versions of Firefox, Safari, Konqueror, Chrome etc. */div.mw-geshidiv{font-family:monospace,sans-serif!important;}#contentdiv.mw-geshipre{font-family:monospace,sans-serif;}
The above code should work for all the different languages that the <source> tags can render (I have tested for a bunch of the languages). And the code uses as low CSS specificity as possible. Unfortunately I had to use the "!important" keyword for one of the lines, there's no way around that. The code should work in all skins except "modern", since that skin doesn't wrap the content area in "<div id="content">". We could add extra code to work around that, but I think we shouldn't bother.
YDone - I have now added the fix to MediaWiki:Geshi.css, thus this is entirely fixed for the English Wikipedia. If this works without problems then some month from now we should ask the devs to apply this for all Wikimedia projects.
Will not happen (as far as my opinion counts as a dev) without a clear understanding of whether and why this occurs when users' browser preferences don't specify it. We do not check in CSS hacks that seem to fix some problem but we don't really know why. —Simetrical (talk • contribs) 20:05, 20 December 2009 (UTC)
Hidden items
I have added the new "sysop-show" class in MediaWiki:Sysop.css. That's the CSS loaded only for admins.
The reason is that we are currently updating the editnotice system. We need to have some links that are normally hidden, but admins and accountcreators should see them. See discussion at Wikipedia talk:Editnotice#Navbar. But while I was at it, I made it so this hiding system can be reused in other places.
Here's how these new classes work:
1: Hidden div, only visible for admins:
<div class="sysop-show" style="display: none;">
:Text only visible to admins.
</div>
2: Hidden div, only visible for accountcreators:
<div class="accountcreator-show" style="display: none;">
:Text only visible to accountcreators.
</div>
3: Hidden div, only visible for admins ''and'' accountcreators:
<div class="sysop-show accountcreator-show" style="display: none;">
:Text only visible to admins ''and'' accountcreators.
</div>
Which renders this:
1: Hidden div, only visible for admins:
Text only visible to admins.
2: Hidden div, only visible for accountcreators:
Text only visible to accountcreators.
3: Hidden div, only visible for admins and accountcreators:
Text only visible to admins and accountcreators.
I made it so the "sysop-show" and "accountcreator-show" classes work in <div>, <span> and <table> tags. That should cover most usage cases. But if there is a need to hide other kinds of items, then we can easily add that too.
Note that the hiding is not secure, any user can add the declarations for those classes in their personal /monobook.css and will then see the hidden items. So these classes should only be used for convenience, to save normal users from seeing things that they anyway can't use.
What's the point, though? I can still see them if I want to. If this is required, I'd say it should be implemented in MediaWiki. —Ms2ger (talk) 20:39, 6 January 2010 (UTC)
If we don't hide them then the links to create group and page editnotices would show up above the edit window for all users on almost all pages. Those links are slightly ugly, and they take up some page height. But only admins and accountcreators can use those links since editnotices are automatically protected, other users get an error message when they try to use those links. So they are useless and confusing for all other users.
Those links will not be added by MediaWiki, but instead by code in {{editnotice load}}. But sure, it would be nice if MediaWiki supplied some classes to hide things based on what kind of user is seeing the page. I can think of uses for "user-show" (to only show things for logged in users) and "autoconfirmed-show". And perhaps for some other user groups too. By the way, all those are easy for us to add by using Common.js and some CSS. We even could have a use for "own-userspace-show" that only would show in userspace, for the user who's userspace it is. I can code that one too, but it is a bit trickier.
The good thing with adding these classes using javascript and CSS is that it doesn't affect the cache servers, so even if implemented in MediaWiki it should probably be done in a similar way. And as I usually say: Let's first test and develop it here locally, and then when our usage has settled we can ask the devs to add it to MediaWiki so this feature gets automatically available to all Wikimeda projects.
The whole account creation deal isn't part of MediaWiki, so this can't really be added to MediaWiki. It would be nice if someone tried to add the account creation software to MediaWiki, though! It really doesn't seem like it should be a toolserver tool. That way the links could just not be provided if the user doesn't have permission, like delete links and so on. I doubt usergroup-specific hiding classes are useful enough to be worth adding to MediaWiki. —Simetrical (talk • contribs) 20:35, 7 January 2010 (UTC)
The reason I want to show the editnotice links not only to admins, but also to accountcreators is that accountcreators happen to be able to create and edit the editnotices. Apparently that is a side effect of how the editnotices are auto-protected. And since accountcreators can edit them, some admins have stated they will hand out the accountcreator right to any user they trust and that has a legitimate need to handle editnotices.
And since I anyway needed to show the links for us admins, it was so easy to reuse the same code to make it work also for the accountcreators.
Not much. Though we shouldn't forget that hiddenstructure was primarily used to hide optional parameters of infoboxes before we had parserfunctions. That said, we are a LOT further with CSS support these days (hiddenstructure was phased out 5 years ago). Also hiddenstructure was used to HIDE elements, where this is technically used to SHOW hidden elements. A small difference. Though some of the arguments of the hiddenstructure debate would certainly apply. —TheDJ (talk • contribs) 01:50, 9 January 2010 (UTC)
Right, we have learnt many lessons from the old hiddenStructure. I use hardcoded style="display: none;" to hide the items, instead of CSS code in Common.css, thus hiding these items even when a browser doesn't load Common.css. Although most text based browsers don't understand even hard coded styles, so these links do show up in for instance the Dillo browser (I have tested that). But if I understand it right Dillo is now probably the most popular text based browser, still it is only used by 1 out of 10,000 users. (But I haven't checked these stats, I just read them in passing somewhere.) And most modern screen readers don't use text based browsers, but instead use one of the main graphical browsers that do understand styles.
But more importantly: We should only use this hiding and showing method to hide very short things. In this case I am hiding two links named "Group notice" and "Page notice". And they only exist when editing a page, people reading the page will never have them in the page code.
If anyone thinks two short links on the edit page is to much for the screen readers, then consider all the other stuff that is shown above and below the edit window. I use an old slow computer so I have had to manually add CSS to my /monobook.css so my browser doesn't render all that stuff, to get decent edit page rendering times.
That I only load that CSS page when the users are editing makes it harder for them to abuse the show/hide function on their user pages, since the items would be hidden also to themselves when just viewing the page. I have made it so admins see the hidden items already when just viewing the user's page.
I have deleted "MediaWiki:Ownuserspace.css", since not needed anymore. Amalthea pointed out a better way to detect when a user is editing his own user page. See Wikipedia talk:Editnotice#User page links.
But we still have to use the CSS based unhiding of items for sysops and accountcreators (as described further up this section).
Per an idea of bugzilla:22060 We can consider setting overflow:auto for the <pre> element.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris ultricies semper enim, ac porta purus condimentum a. Fusce rhoncus suscipit lacus eu lacinia. Aliquam hendrerit cursus placerat. Etiam pulvinar lacinia malesuada. Sed a nunc sapien. Quisque rutrum nunc sed sem porttitor ac ullamcorper lectus tristique. Sed ac libero est, non.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris ultricies semper enim, ac porta purus condimentum a. Fusce rhoncus suscipit lacus eu lacinia. Aliquam hendrerit cursus placerat. Etiam pulvinar lacinia malesuada. Sed a nunc sapien. Quisque rutrum nunc sed sem porttitor ac ullamcorper lectus tristique. Sed ac libero est, non.
Using style="overflow:auto;" breaks badly in many browsers. So it is better to not use it and instead manually line wrap the examples we put in <pre> tags to avoid making them to wide.
I've been wondering, but i don't think that any of the browsers that actually support overflow:auto have a serious bug. In my memory the issues were all with setting visible or scroll (and http://css-tricks.com/the-css-overflow-property/ seems to say something like that). The only big problem here I think, is that IE will draw the scrollbar inside the pre element, where most other browsers draw them outside the contentbox. However judging from the amount of margin and lineheight on pre elements, I don't think it will be a real issue. /me wonders where Edokter is... —TheDJ (talk • contribs) 23:25, 12 January 2010 (UTC)
I believe that's what i created the overflowbugx class for btw. Adding an example of that here.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris ultricies semper enim, ac porta purus condimentum a. Fusce rhoncus suscipit lacus eu lacinia. Aliquam hendrerit cursus placerat. Etiam pulvinar lacinia malesuada. Sed a nunc sapien. Quisque rutrum nunc sed sem porttitor ac ullamcorper lectus tristique. Sed ac libero est, non.
Would using overflow-x:auto instead of just overflow: help? It's more modern than the normal overflow, so older browsers might just ignore it rather than choking horribly? Happy‑melon23:39, 12 January 2010 (UTC)
What I meant with "breaks badly in many browsers" is that Internet Explorer 6 and down, and some other browsers don't understand "overflow:auto;" at all. So it doesn't help what fixes you guys apply to it, those browsers will still display the full width of that <pre> tag. And even worse, some of them then make the whole content area that wide, thus making every paragraph on the page that wide. Thus forcing the user to scroll back and forth like crazy to read each paragraph on the page. Making the pages pretty much unreadable. (I know from personal experience.)
So again, manually line wrapping the text in the <pre> tags is much better. If we make the <pre> tags automatically overflow, then most of our editors won't bother to manually line wrap, and thus users with some browsers can no longer read many of the articles with <pre> tags in.
Even in IE8, the overflow:auto and class="overflowbugx" examples are both unreadable (rendered identically in fact), because the horizontal scrollbar rendering inside the box reduces the height of the remaining text area to less than the height of the line of text, which in turn causes a squashed vertical scrollbar to appear. Evidently the margins and lineheights are not sufficient to stop this from being "a real issue"! — Richardguk (talk) 02:08, 13 January 2010 (UTC)
IE6 ignores "overflow:auto", and seems to ignore "overflow:scroll" as well... at least for pre tags. If this 'fixes' the display for other browsers, I don't see a problem with it. But above all, text in pre tags should be hand-wrapped. — Edokter • Talk • 13:43, 14 January 2010 (UTC)
The problem I was getting at with netbooks, is the screen is not tall enough to display the horizontal scroll bar and the top of the content. This results in the user scroll down a screen or more to scroll the text, now off screen, to the left. It is further compounded by lack of horizontal scrolling on most touch-pads. A solution to this would be to have a floating scroll bar on shorter screens. — Dispenser17:26, 14 January 2010 (UTC)
Classes tright a tleft not working in Vector
The CSS classes tright and tleft are specified in Monobook.css, so that some left/right floated elements (e.g. {{Bar box}}) have proper margin. It is also present in commonPrint.css, this time also with the float: left/right and it specifies border there, not margin.
The issue I'm having is that Vector for screen doesn't specify this class at all (if I haven't overlooked something). What I'm proposing is to either move the class to Common.css from Monobook.css, so that it works in all skins, or, if that would cause any problems, at least copy it to Vector.css. Svick (talk) 14:30, 15 January 2010 (UTC)
Vector does have these classes (they are in main-ltr.css), without them thumbed images would not work. But tright/tleft set white borders (as margins), and if you overwrite those borders like done in Bar box, then the relevant margins disappear. —TheDJ (talk • contribs) 14:59, 15 January 2010 (UTC)
/* Makes the background of a framed image white instead of gray. *//* Only visible with transparent images. */div.thumbdivaimg{background-color:#fff;}/* Remove white border from thumbnails */div.thumb{border:none;}div.tright{border:none;margin:0.5em00.8em1.4em;}div.tleft{border:none;margin:0.5em1.4em0.8em0;}
Proposed code for Common.css
/* Remove white border from thumbnails */div.thumb{border:none;}div.tright{border:none;margin:0.5em00.8em1.4em;}div.tleft{border:none;margin:0.5em1.4em0.8em0;}
Note I left out the setting for the thumbimage background. First of all that statement should long ago have been changed to img.thumbimage instead of "div.thumb div a img". But secondly, I'm not really sure why we are displaying a white background for transparent images in a gray box.... Doesn't that kind of defeat the point of transparent parts of images ? —TheDJ (talk • contribs) 23:41, 15 January 2010 (UTC)
Since I wrote some of the CSS we use to handle the image backgrounds here at the English Wikipedia:
In some namespaces we use chequered background to make it visible what images are transparent. But in article and user space we use white background since that looks better. Using a white background still shows the image's size, its own "padding", and height to width ratio. If we use a grey background (same as the surrounding area) then we can't tell where the image ends and where the surrounding area begins. And that is very confusing, I have tested that. And the transparency in most images are made with white background in mind, since our articles and most of our message boxes etc use white background. Grey background for instance makes the shadows that some icons use hard to see.
So using the white background is much better than using a grey background.
The images don't need their transparency when they are displayed as thumbs or in a gallery. They only need the transparency when used in message boxes and directly on the pages etc.
(I currently have no comments on the border code above, sorry.)
In {{navbox}}, the lists have set class nowraplinks, so that links in navboxes don't wrap. This doesn't work when a navbox is in an article listed there, because it isn't a link anymore. Instead, the text has class selflink. My suggestion is to change
I ran some tests, and I agree. But there should be a space in ".nowraplinks .selflink", since the nowraplinks class is in the {{navbox}} table or {{nowraplinks}} span that surrounds the "<strong class="selflink">". So here's the correct code:
YDone - Svick: Thanks a bunch for finding this bug! :)) Ms2ger: Right, I almost feel silly since I was the one who created the nowraplinks stuff and we have used it for 2.5 years now. But I think this is the kind of thing that is "oh, of course, that's obvious" once you see the solution, but until then is hard to discover. Or as we say in my language: "It is the 'simple' things that are hard to discover." Line wrapped self links are not that common, I for one have probably never seen a line wrap in a self link. And I guess most people who noticed line wraps in self links didn't know we could easily fix it, so they didn't report it as a problem. While Svick both had the luck to see a line wrapped self link, and the expertise how to fix it.
, but when there are many secure links on a page the yellow padlock becomes too overwhelming. So I would like to change to a blue padlock 
instead, which matches the external and secure link colour and the colour of the other external link icons 
.
.
. Compare that to the old blue version File:Lock icon blue.gif
. And the original yellow padlock File:Lock icon.gif
. And a link to the yellow padlock in the Vector skin. (Their vertical alignment is a bit low here due to that they are not inserted with CSS but as regular images.)
Done - I have now added the fix to MediaWiki:Geshi.css, thus this is entirely fixed for the English Wikipedia. If this works without problems then some month from now we should ask the devs to apply this for all Wikimedia projects.
![[1]](https://wiki.riteme.site/skins-1.5/vector/images/lock-icon.png){kind=link}
