MediaWiki talk:Common.css

Meta | Wikibooks | Wikiquote | Wikisource | Wiktionary | Deutsch | Français | Nederlands

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

Table background

Is there any reason not to change the background of tables to be transparent instead of white? The slight mismatch between the white and the monobook background have been bothering me for some time, and I have added it to my monobook.css file. I don't think it would cause any problem with other skins, since they all pretty much use a white background. Prodego ^talk 01:29, 15 January 2007 (UTC)

Yes. The reason is that, when the background is transparent, the horizontal line below headings is visible behind some tables, which is uglier than a slight colour mismatch. --cesarb 16:11, 3 February 2007 (UTC)

Rules based on the namespace-based CSS classes such as ".ns-0" could be added to sync the table background colors across the various namespaces. I'm not sure if those classes are available in any skin except Monobook, so it would possibly be better to add them to MediaWiki:Monobook.css. On second thought, it is definitely better to add them there since the background colors are skin-specific. FYI, I just checked the CologneBlue skin and it also supports the .ns-# classes. Mike Dillon 16:18, 3 February 2007 (UTC)

Well, how about setting the default background to #F8FCFF for monobook only, (and the other classes each with their own). That way the backgrounds will match. This could be added to Mediawiki:Monobook.css. Prodego ^talk 23:21, 6 February 2007 (UTC)

Note that all skins support the namespace classes. —Simetrical (talk • contribs) 01:11, 9 March 2007 (UTC)

You mean like this?

#content table {
    background-color: #f8fcff;
}

.ns-0 * #content table {
    background-color: white;
}

This matches the rules used to override the background color in Mediawiki:Monobook.css, with the addition of "table" at the end. Mike Dillon 04:08, 7 February 2007 (UTC)

Yes, I think so. I know only a very little CSS, so you will need to bear with me here. I have one question, what does the "#content" before table do? I understand .ns-0 specifying for the main namespace's white background, but I do not understand the "content" part. But yes, that is what I mean. Prodego ^talk 04:37, 7 February 2007 (UTC)

It makes it apply to tables that are children of an element with id="content". I put it there because the rule that does the background for the content tab includes #content. Mike Dillon 05:46, 7 February 2007 (UTC)

I see, you need that because it is part of the way the mainspace background is changed. It looks good. Now, can we do the same thing to diff backgrounds on non-mainspace pages? Currently they don't match either. Prodego ^talk 20:42, 7 February 2007 (UTC)

This rule actually has some issues. I have it in my personal monobook and it is changing the background of the tables that use .standard-talk blue on talk pages. I think the issue is that the #content selector increases the weight of this rule above the weight of the rule for the .standard-talk background. It might be possible to fix this by removing #content from the ancestor chain and adding "!important" to the .standard-talk rule. Mike Dillon 02:59, 8 February 2007 (UTC)

I removed the #content and "*" selectors from the rules and it fixed the talk page issues. I still think this stuff needs to be thoroughly tested in somebody's personal monobook before going live. The main namespace table rule makes it so that a rule that only has one class selector will not work without "!important". This is because the ".ns-0 table" rule has a specificity of 11 and a single class rule like ".infobox" has a specificity of 10. A rule like "table.infobox" has a specificity of 11 and it then becomes an issue of ordering which one applies. We don't want to have to have ".ns-0" versions of all the CSS rules to make sure they work and scattering !important everywhere kind of sucks. Mike Dillon 03:12, 8 February 2007 (UTC)

Hmm, that is a problem. There has got to be a way to do this though... Prodego ^talk 20:33, 8 February 2007 (UTC)

About to remove checkerboard background

If I don't hear any good justification, I will remove the checkerboard background style for transparent images (as visible here). I understand the usefulness for editors. The style is already the default on Commons, and most transparent images are user-uploaded ones which belong there. Here on Wikipedia, we should be more concerned about the readers, for whom these checkerboard patterns are nothing but a distraction when viewing images.--Eloquence* 02:20, 17 February 2007 (UTC)

Sounds good. —Centrx→talk • 02:23, 17 February 2007 (UTC)

Wouldn't adding a history tab to the image namespace moving the file history to the history tab be more beneficial to readers? (As well as moving most metadata to the talk page, leaving only the image and a description which is relevant to readers on the image page?) —Ruud 13:58, 17 February 2007 (UTC)

If you could do this with CSS, I'd be very impressed ;) Mike Dillon 02:11, 18 February 2007 (UTC)

It's back and now in article space as well :/ —Ruud 01:30, 7 March 2007 (UTC)

To further improve the description page's appearance for readers, I tried to change the images' background color from white to the pale shade of blue used for non-article pages. I did so by creating a 1px GIF image and attempting to tile it via the same code formerly used for the checkerboard background. This had no apparent effect, so I tried a 16x16 version. That didn't work either, so I tried a 1px PNG (a larger file than the GIF version, which is why I didn't use it in the first place). No luck.
If anyone can identify the problem (or knows of a better way to do this), please jump in. —David Levy 07:52, 14 March 2007 (UTC)

It's because of a related change to MediaWiki:Monobook.css. So you'd need to change it there. —Dispenser 08:35, 14 March 2007 (UTC)

That change to Monobook.css appears to pertain the "gallerybox" class (used for image galleries), so I'm confused as to how it affects the description pages. (Please bear with me.) Also, shouldn't that be set to #F9F9F9 (the shade of grey used for the galleries) instead of white? I assume that the similar code (in lieu of an image link) could be used here. —David Levy 08:52, 14 March 2007 (UTC)

The comma separates different sets of selectors, so both gallerybox class image and the file page image will have the same CSS applied to them (for the selected element). The spaces represent child selector, so it only applies to <IMG> within an element using thumb and gallerybox classes. So you have to options: separate the first selector and give it the background: #F9F9F9 or remove it which will make it transparent. You probably should test your stuff with Web Developer Extension before implementing it. Lastly this change should not be implemented in commons.css as it affects all skins. —Dispenser 06:57, 15 March 2007 (UTC)

Thanks again for your help! I implemented the background coloring in Monobook.css. Some of this may be moot, however, as Ed g2s has restored the checkerboard background. —David Levy 17:05/17:07/17:11, 15 March 2007 (UTC)

Hang on, since when did the chequered background become such a bad thing? There is no other way to convey transparency information (changing the background colour doesn't really help) and it's subtle enough not to distract from the content of the image. I think it is considerably more useful than it is distracting. The difference between white and transparent can convey information in a diagram. ed g2s • talk 16:48, 15 March 2007 (UTC)

Could you please cite an example in which this effect helps to "convey information in a diagram"? I can't imagine why an image author would rely on such a feature (unavailable in articles and to users of incompatible browsers), and I'm afraid that I agree with Erik. The checkerboard is useful to editors (who can implement it in their personal CSS), but it distracts readers. —David Levy 17:20, 15 March 2007 (UTC)

Any diagram which contains a white filled object - while one may be able to infer it from it's filled from context one can only see that when the background is changed. Can you give an example of where it distracts readers, it's only a very pale grey. ed g2s • talk 18:08, 15 March 2007 (UTC)

I would argue that the checkerboard background serves as a distraction whenever a reader simply wishes to view the image's subject (here, for example). —David Levy 19:18, 15 March 2007 (UTC)

A quick example (probably not the best) is Image:Warsztat.svg. With the transparency is possible to tell that the two large enclosed rectangles are empty, and the system is not mounted on a white wall. Also the small circle at the intersection of the sticks labelled 16 is made apparent to be a pin, and not a hole because it is filled white, the same with the joints labelled 8. As I mentioned, it is often possible to guess the difference between white and transparent, but it is not always the case, and this certainly makes it clearer. ed g2s • talk 18:14, 15 March 2007 (UTC)

I see what you mean, but this advantage is nonexistent when viewing the image in an article (against a white background) or via an incompatible browser (such as IE6). Therefore, diagram creators should be discouraged from relying on this convention to convey information. It would make more sense to simply use a solid background and fill specific elements with different colors. —David Levy 19:18, 15 March 2007 (UTC)

Transparency is not just about conveying information - it also makes images more reusable - i.e. compositing diagrams, overlaying onto new backgrounds etc. This benefits everyone, regardless of which browser they use. As long as we agree that transparency used correctly is a Good Thing, then we should be displaying it when we have it, and highlighting the images which use it incorrectly / don't use it at all. ed g2s • talk 14:40, 28 March 2007 (UTC)

It also makes it clear when an image is broken (lacking transparency or using transparency when it should be filling white), something that all Wikipedians should be concerned about, not just Commoners. ed g2s • talk 18:19, 15 March 2007 (UTC)

Actually, this is something that concerns editors (who can deliberately select compatible browsers and add the necessary code to their personal CSS). Other Wikipedia readers simply want to view the images. —David Levy 19:18, 15 March 2007 (UTC)

Wikipedians = editors. Most editors/Wikipedians won't bother/know how to set their stylesheet, and the problems will go unnoticed. ed g2s • talk 14:40, 28 March 2007 (UTC)

Consistent padding for "div.NavFrame" and "table.navbox"

UPDATE: The padding issue was resolved in this edit to MediaWiki:Common.css, therefore the examples below do not accurately show the differences that existed prior to 18 March 2007. -- Zyxw 03:54, 28 March 2007 (UTC)

Common.css currently has different padding values assigned to the two navigation box classes: div.NavFrame uses 2px and table.navbox uses 5px. This causes navbox templates to effectively have 5px more padding (3px from the CSS settings plus 2px from the use of tables). The difference in appearance can be seen at the bottom of pages such as Guadeloupe, Mayotte, Toronto and too many others to list here. I have included examples below which compare the navbox-based {{Navbox generic}} and NavFrame-based {{Navigation}} templates. Users of Internet Explorer 6 for Windows will see no differences in these examples, as CSS padding for tables seems to be ignored.

• The first example shows navbox with the default padding:5px. This creates a large amount of padding between the border and the body of the table.

• The second example shows navbox with padding:2px. Although this is also the default for NavFrame, the padding in navbox appears larger due to the table adding an additional 2px of "cellspacing" (HTML) or "border-spacing" (CSS).

• The final example has navbox set to padding:0 which gives the navbox and NavFrame templates a similar appearance.

Based on the above results, I suggest making one of the following changes:

1. Leave div.NavFrame at padding:2px and change table.navbox to padding:0
2. Change div.NavFrame to padding:3px and change table.navbox to padding:1px
3. Change div.NavFrame to padding:4px and change table.navbox to padding:2px

– Zyxw 23:26, 16 March 2007 (UTC)

Homogenizing the looks of the various navigational boxes is a good move. I'd personally prefer option 3 (or perhaps even a totally different look.) Some other tweaks would be to use the same font size and amount of padding between two boxes. I'll have a stab at rewriting the Javascript behind NavFrame to fix some minor bugs and integrate it better with my collapsible table code (so both the NavFrame and navbox boxes collapse when the total number is over some threshold.) —Ruud 00:22, 17 March 2007 (UTC)

references-small again

I know it has been discussed before. But it seems that nothing has changed. It is still 90% now. I personally prefer 85%, which will make references small in both IE and FF. My second choice is 92%+, which also render similarly in both browsers. But with 90%, it's inconsistent across the two major browsers. --ChoChoPK (球球PK) (talk | contrib) 11:45, 21 March 2007 (UTC)

I agree to some extent – though I should point out that small references are not the only thing that renders at a different size in IE and Firefox. So does the sidebar, the user links in the top-right corner, and the tabs ("edit this page" etc.) at the top of the page. All of these are specified at (I think) 90%, or at least some size that shows up differently in the two browsers (and differently again in Opera). So if this is going to be changed for that reason, so should everything else – Qxz 00:38, 24 March 2007 (UTC)

Wikitable changes

I don't think the child selector was supported in Internet Explorer until version 7 (cf. Comparison of layout engines (CSS)#Selectors, which lists support for child selectors in the Trident rendering engine as a version 7.0 feature). Thus, I'm afraid that the recent change to use this rule will not work:

table.wikitable > tbody > tr > th, table.wikitable> tbody > tr > td,
table.prettytable > tbody > tr > th, table.prettytable > tbody > tr > td

Can anyone confirm that this works in IE6? If not, it should probably be removed since a bad selector will cause the rule to be ignored. Also, I'm not sure that tbody is present in the DOM in all browsers. Mike Dillon 02:33, 24 March 2007 (UTC)

Re: tbody, this page seems to confirm that it is there in IE. I know that Gecko-based browsers have it as well. I guess that part isn't an issue, but I think the child selector thing is. Mike Dillon 02:35, 24 March 2007 (UTC)

IIRC, tbody is implicitly added only when using HTML, not when using XHTML. Since using XHTML is needed for using MathML, it would be a bad idea to depend on something that would not work on XHTML. --cesarb 16:25, 24 March 2007 (UTC)

This seems to have affected at least one user so far. It probably needs to be reverted. Mike Dillon 05:51, 24 March 2007 (UTC)

Reverted. —Ruud 12:08, 24 March 2007 (UTC)

Much better, thank you. --After Midnight ⁰⁰⁰¹ 14:15, 24 March 2007 (UTC)

I really thought that all browsers, which supported css2 supported child selectors. it's a rather common type. _→AzaToth 14:19, 24 March 2007 (UTC)

I'm not sure there are any mainstream browsers that fully support CSS2. Even Firefox and other Gecko-based browsers, which are generally touted for their compliance, have a few areas that aren't supported. An example is @font-face, although it is possible that will be removed from CSS3. There is a table in the "General overview" section of the Comparison of layout engines (CSS) article that only shows full cross-browser support for CSS1. Mike Dillon 15:26, 24 March 2007 (UTC)

True, but the child selector is so common I though all major browsers supported it. _→AzaToth 15:30, 24 March 2007 (UTC)

Never trust anything to just work in IE ;) —Ruud 19:54, 24 March 2007 (UTC)

Unicode/IPA class doesn't work with IE7

I currently use both IE6 and IE7, and so discovered that all the special characters using Unicode or IPA classes are displayed correctly only on IE6.

Then I found out the comment "The inherit declaration resets the font for all browsers except MSIE6. The empty comment must remain." just before the class in Common.css (some info about the empty comments [1], with a test page for your browsers). I don't really understand why we should "reset" the font for all these browsers. For myself I created a customized stylesheet without the inherit line, and it works fine.

The problem is not new, as I found out in Template talk:IPA#Explorer 7. If someone can explain this, or suggest a solution to the problem with IE7, it would be very nice. Thanks. —Yoshigev 14:11, 29 March 2007 (UTC)

Forcing the use a a certain font is very evil, so we only want to do it on browsers that would otherwise mess up. The font declarations should probably be moves to the Internet Explorer bug-fix stylesheet or see if we can use IE's conditional comments so we can avoid exploiting a bug that only exists in IE6. —Ruud 18:07, 29 March 2007 (UTC)

Since I don't have other browsers except IE, I can't tell how they react to Unicode symbols. Does they really show all the characters correctly (try IPA chart for English)? I know that some of the symbols need special fonts such as Doulos SIL, so how would a browser know to use that font without the CSS? —Yoshigev 21:35, 29 March 2007 (UTC)

Firefox, Opera and Safari (unlike IE) just try each font on your system if the character isn't available in the default font. —Ruud 00:16, 30 March 2007 (UTC)

I thought of another option: Embedded OpenType font. EOT fonts only work for IE, and they are downloaded automatically. I created a file for "Doulos SIL", and it weighted only 394 KB. In the CSS the lines should read something like:

@font-face {
       font-family: DoulosSIL_wiki;
       src: url("file:///c:/DoulosSILR_wiki_en.eot");
     }

.IPA {
       font-family: DoulosSIL_wiki
     }

I wanted to upload the file, to see if it works well from other computers, but it's type was not recognized. As I see it, the problems might be:

• That the client wouldn't cache the font, and download it again and again.
• How other browsers might react to that.
• What font will be used before the file completes downloading, or if it fails to download.

Please tell me if there is an option to upload the file. Thanks again. —Yoshigev 08:31, 30 March 2007 (UTC)

I tried this a few months ago, but unfortunately for a significant portion of the users it causes a messagebox to appear on each page view asking them if they wish to download the font. —Ruud 08:35, 30 March 2007 (UTC)

OK, nevermind. So it looks like there's no elegant solution. Do you think we should put an explanation somewhere (so it will be noticable) how to fix the problem with personal monobook.css? —Yoshigev 11:17, 30 March 2007 (UTC)

Help:Multilingual support would be a great place. —Ruud 12:16, 30 March 2007 (UTC)

Thanks. I'll try to add a section to there. —Yoshigev 13:34, 30 March 2007 (UTC)

CSS for horizontal lists

{{editprotected}}

Rather than repeating myself, please see MediaWiki_talk:Monobook.css#Horizontal_lists and discussion at Wikipedia:Village pump (technical)#Horizontal lists Thank you. Andy Mabbett 22:17, 29 March 2007 (UTC)

See the discussion for more details. I propose the following addition, which will be useful for semantic reasons:

ul.horizontal {
  padding: 0;
  margin-top: 0;
  margin-left: -1.5em;
  margin-bottom: 0.5em;
  margin-right: 0;
}

ul.horizontal li { 
  display: inline;
  font-size: 90%;
  line-height: 1.5;
  border-left: 0.1ex solid;
  padding-left: 0.5em;
  padding-right: 0.5em;
}

ul.horizontal li:first-child {
  border-left: none;
  padding-left: 0;
}

I didn't look into the code itself in excessive detail, but this will enable

<ul class=horizontal>
*Item uno
*Item dos
*Item tres
</ul>

for horizontal lists with semantic meaning. Gracenotes^T § 13:47, 30 March 2007 (UTC)

I'm not sure how that's different, in effect, from what I proposed. Incidentally, further experimentation shows that it's better with the solid border on the right, excluding last-child (as opposed to being on the left and excluding first-child). This looks better when the list wraps over two or more lines. Andy Mabbett 13:53, 30 March 2007 (UTC)

Wait, it doesn't work on IE6. I'm testing now. --ais523 13:55, 30 March 2007 (UTC)

I no longer have IE6 here, but, from memory, it doesn't "fail" so much as "fall back", which is what CSS is designed to do. Can you describe (or screen-cap) what you're seeing, please? What page are you testing it on? Andy Mabbett 14:07, 30 March 2007 (UTC)

The selector given is wrong; instead of ul.horizontal, .horizontal ul is what's needed, or it makes no visible change to the page at all. (I think the selector given is wrong for all browsers.) With that corrected, the borders are placed asymmetrically between the words, looking ugly (in both the first-child and last-child versions). Also, the :first-child selector is ignored, meaning an extra vertical bar at the start. (The CSS fallback would cause the horizontal list to become vertical in non-CSS browsers, which is also probably a bad idea.) I'm testing on User:ais523/Sandbox. --ais523 14:11, 30 March 2007 (UTC)

I refer the hon. gent. to the code I gave in my original comment (linked above). As to the placing of borders is that a browser issue, or a quantitative-values issue for the CSS? As for first/ last child selector being ignored, if you will use a broken, superseded browser... (but switching to last-child should help remedy that). I fail to see why correct non-CSS fall-back is a bad idea; the alternative would seem to be to misappropriate HTML markup to achieve presentational effects - like using blockquote for indentation or tables for layout. Andy Mabbett 14:17, 30 March 2007 (UTC)

My point was that for long horizontal lists (which don't take up much space), the fallback is a long vertical list (which could be several pages long in some cases), rather than an unformatted list of words stretching horizontally. Another way to put it might be: the <li> tag was originally intended for block-level markup (to me it carries a connotation of 'list' as in each list item is on a separate line, and whether they're bulleted or numbered or whatever is less important), and the fictitious 'horizontal list' tag would be inline. I'm not sure to what extent this acts against the 'li means list, and a horizontal list is a list' argument, which seems reasonable. --ais523 16:29, 30 March 2007 (UTC)

(outdent) Try

.horizontal li 
	{ 
	padding-left: 0.4em;
	padding-right: 0.6em;

(Other values unchanged). Andy Mabbett 14:24, 30 March 2007 (UTC)

The problem with the fallback for really old browsers would be the huge page-heightening that a long horizontal list could achieve. And I don't have much choice in browser; the only browsers installed on this computer are IE6 and an ancient version of Mozilla that can't even cope with the Monobook skin (it falls back to a Myskin variant), and I don't have admin rights on this computer so I can't install any others. If I remember correctly, IE6 is one of the browsers that Wikipedia still attempts to display correctly on (although I'm well aware quite how difficult this can be...) --ais523 14:46, 30 March 2007 (UTC)

(By the way, I appreciate the reasoning behind wanting to use logical markup when possible; but this rule is broken a lot (for instance, we're both using <dd>, which is what the : character produces, for indentation in this thread).) --ais523 14:48, 30 March 2007 (UTC)

I think people who use "really old" browsers will be used to things looking less than beautiful, anyway. I take your point about ie6 (it;'s still widely used) but there have to be some compromises when dealing with something so broken, and the fine- positioning of a separator probably comes under than heading. Your piont about abused HTML is also well made, but no reason not to try to do better. Andy Mabbett 14:57, 30 March 2007 (UTC)

Note: I haven't worked with CSS style sheets in some time, mostly inline stuff. I just wanted to get the ball rolling with a request edit :) Gracenotes^T § 14:33, 30 March 2007 (UTC)

Your comments and intervention (and those of ais523) have been helpful, and much appreciated - thank you both. Andy Mabbett 14:57, 30 March 2007 (UTC)

If I remember correctly, display: inline works for list items in IE6, and maybe even IE5. Can anyone confirm/disconfirm that? It should also be pointed out that the semantic information of list-ness is actually used in nonstandard browsers; browsers with limited simultaneous output, such as screen readers and small-screen browsers, may "compress" lists by default and allow the user an option to expand them if he really wants to see all 57 counties of Finland or whatever instead of wanting to scroll to the navigation stuff at the bottom. I know Opera Mobile (or Mini or whatever), at least, does this, and inline lists are conspicuously long. So this isn't some academic "purity" issue. —Simetrical (talk • contribs) 22:45, 30 March 2007 (UTC)

display: inline definitely works in IE6. --ais523 14:41, 31 March 2007 (UTC)

What is the current consensus on making this change? CMummert · talk 14:50, 31 March 2007 (UTC)

Good question! I have seen absolutely no dissent, here or on any of the other pages where I raised the matter; only discussion of minor tweaking for aesthetic reasons (note that some of the CSS in my example code (line height, font-size) was for such purposes on my site, and might not be needed here). Can we perhaps get something uploaded, even if only on a trial basis? Note also an additional use-case; templates such as Template:West Midlands railway stations. Also, "flat" may be better name than "horizontal", not least for ease of typing by users implemetning such lists. Andy Mabbett 15:23, 31 March 2007 (UTC)

This seems reasonable, as long as the code with .horizontal ul li (which works on IE6) also works on standards-compliant browsers. I won't make the change myself, partly because I don't know whether the IE6 selector is the same as the 'correct' one, and partly because I'm too involved in this discussion. --ais523 15:27, 31 March 2007 (UTC)

So what now - do we have to sacrifice a chicken, or something? Andy Mabbett 20:44, 31 March 2007 (UTC)

No shrubbery is necessary. I am willing to make the change, but I want to make sure that there is consensus, and that all the possible issues have been addressed. Since this CSS file affects every user on the site, it is particularly important to be careful in vetting proposed changes.

Has someone tested this with a modern browser, as ais523 suggests just above here? CMummert · talk 02:08, 1 April 2007 (UTC)

I use FF2, ie7 and Opera 9.1. It works fine in all three (in Opera, there are no "separator" borders, but its still perfect readable and wraps and enlarges without problems). It's fine on Opera's "narrow" mobile device emulator. It degrades gracefully in all three, with CSS disabled, and in 'OffByOne' a basic browser with no CSS capability. Andy Mabbett 05:52, 1 April 2007 (UTC)

basic browsers with no CSS. It's messy, but readable, in Netscape 4. Andy Mabbett 05:52, 1 April 2007 (UTC)

OK. Final request: please confirm that the following is exactly the code that should be added. CMummert · talk 14:22, 1 April 2007 (UTC)

<!-- Style for horizontal UL lists -->
ul.horizontal {
  padding: 0;
  margin-top: 0;
  margin-left: -1.5em;
  margin-bottom: 0.5em;
  margin-right: 0;
}

.horizontal li { 
  padding-left: 0.4em;
  padding-right: 0.6em;
  display: inline;
  font-size: 90%;
  line-height: 1.5;
  border-left: 0.1ex solid;
}

ul.horizontal li:first-child {
  border-left: none;
  padding-left: 0;
}

The font-size shouldn't be tied to the horizontalness. —Ruud 14:29, 1 April 2007 (UTC)

The selector there is incorrect in IE6 (IE6's selector should be .horizontal ul on the first block, and so on). --ais523 16:16, 1 April 2007 (UTC)

{outdent)

• remove "font-size: 90%;"
• remove "line-height: 1.5;"
• change "border-left: 0.1ex solid;" to "border-right: 0.1ex solid;"
• change "ul.horizontal" to "horizontal"
• change "ul.horizontal li:first-child" to "horizontal li:last-child"

(last three per my original suggestion; does this satisfy ie6?) Thank you. Andy Mabbett 17:34, 1 April 2007 (UTC)

Thanks. I changed the other occurance of border-left to border-right as well. That makes the following. Would someone double-check that this works? Also, can I change the bare 0 to 0em in four places? CMummert · talk 21:49, 1 April 2007 (UTC)

<!-- Style for horizontal UL lists -->
horizontal {
  padding: 0;
  margin-top: 0;
  margin-left: -1.5em;
  margin-bottom: 0.5em;
  margin-right: 0;
}

.horizontal li { 
  padding-left: 0.4em;
  padding-right: 0.6em;
  display: inline;
  border-right: 0.1ex solid;
}

.horizontal li:last-child {
  border-right: none;
  padding-left: 0;
}

Looks good; validates; in use at http://www.westmidlandbirdclub.com/test/wikitest.htm Andy Mabbett 22:17, 1 April 2007 (UTC)

I added it to the CSS file. It validates under CSS 3. CMummert · talk 00:38, 2 April 2007 (UTC)

(outdent) Thank you. I've used it in a few places:

• A34
• Birmingham
• Black Country
• BBRC
• Tamworth
• Warwickshire

Andy Mabbett 01:01, 2 April 2007 (UTC)

Checkered background

I very much disagree with Ed2gs; the checkered background on transparent images is highly distracting for readers and makes some of our most aesthetic works look ugly and unappealing. Whenever a complex diagram (like in eye) is in an article, people will want to zoom in to see and understand details. Overlaying a checkered background that the original artist of the image never intended to be there is distracting and greatly affects the aesthetic quality of these images.

Ed has been the only person so far who has actually argued for keeping this for readers. I have removed it again; but if you feel this is an issue that needs a resolution, then we can have a poll on it. I strongly feel that this is something that should be on the level of editorial preferences, not a default we serve to all readers.--Eloquence* 22:29, 31 March 2007 (UTC)

If an image isn't meant to have an transparent background, then the image shouldn't have a transparent background, I believe the checkered background brings more positive things than negative things, as you then quickly can see if an image by some freak accident has transparency even if they shouldn't. The eye image is fully incorrect where the whole image has a transparent channel. So let's bring the checkered background back! _→AzaToth 23:13, 31 March 2007 (UTC)

Why should the artist create a background, when their expectation is that the image will be used in the context of a wiki, which may have particular stylistic needs? They only want to create an image, not worry about the particular context in which it is used. Default transparency strikes me as a perfectly reasonable choice, and I see no compelling argument to bother our finest artists with unnecessary requests, or to distract our readers with unaesthetic patterns.--Eloquence* 23:31, 31 March 2007 (UTC)

The only way I would consider this to be workable in the default skin is as an optional overlay which users can activate via JavaScript on image description pages, i.e. a "Show transparency" link.--Eloquence* 23:33, 31 March 2007 (UTC)

If the original artist has chosen transparency for a reason, I can't believe their reason was to show it against a white background, thus show it as it doesn't have a transparency. _→AzaToth 23:53, 31 March 2007 (UTC)

Inkscape, which is probably the most commonly used vector graphics application around here, will treat all background as transparent by default. There is no conscious choice. Moreover, any such choice probably does not equate to "an ugly and distracting chessboard pattern".--Eloquence* 01:23, 1 April 2007 (UTC)

Using transparency is a good thing: the image can be displayed on various coloured of textured backgrounds. However the fact hat we can does not imply we should. The checkered background is only of use to a small portion of the editors, which are only a small fraction of our users. Those who care about the transparency likely have the technical skills to add this to their personal stylesheet. —Ruud 13:19, 1 April 2007 (UTC)

What do you think of at least change the background color of the image? Like this for example:

_→AzaToth 13:33, 1 April 2007 (UTC)

The majority of users would prefer a white background and it doesn't clearly indicate the presence of transparency to the rest. —Ruud 13:43, 1 April 2007 (UTC)

The checkered background is used because it is the standard way of showing transparency, using a solid color will result in any image that uses that color being subjected to low or no contrast to the background. ^High_InBC^{(Need help? Ask me)} 15:37, 1 April 2007 (UTC)

It is the standard way of showing transparency in image editing applications. The display of the checkered background is akin to viewing an image in "edit mode". As you say, it allows the illustrator to preview what effect an image might have when put in front of a background, without using any specific background color that might result in low contrast to the colors used in the image.

This, however, has nothing to do with what is best from a reader's perspective. For the viewer, the benefit of a tool that emphasizes background is completely lost. They are not interested in the background, or how useful the image might be in front of another one. They are interested in the content. Most illustrators on Wikipedia will design with white as the background color in mind. If we use white as the default, and allow editors to make transparency visible when they need it, we serve both groups. If we make the "edit mode" the default view, we risk to lose the audience for whom we created the images in the first place, and force illustrators to add artificial and arbitrary background images where none are needed.

If you disagree, can you show me a single scientific or educational publication, anywhere, that shows images with a checkered background? If there is none, then why should Wikipedia be the first?--Eloquence* 01:00, 2 April 2007 (UTC)

"Why should the artist create a background, when their expectation is that the image will be used in the context of a wiki" - our content is not just for use in a wiki - it is supposed to be reusable. The use in the wiki (as in articles) does provide a white background. I have also yet to see an image where the extremely pale background has made it difficult to view. ed g2s • talk 01:29, 2 April 2007 (UTC)

Could you guys stop wheel warring and figure this out before making any more changes? It would probably make sense to discuss this somewhere other than this talk page (e.g. WP:VPR). People keep claiming things like "best for readers", "best for editors", or "majority of users", but this is a very limited discussion and I've seen no references to discussions taking place with a broader audience. Mike Dillon 01:57, 2 April 2007 (UTC)

That seems like a good idea. I did object to a feature which has been around for (what seems like) a long time, being removed after very little discussion. ed g2s • talk 02:04, 2 April 2007 (UTC)

Poll on transparency issue

Should a checkerboard pattern be used to indicate image transparency on all image description pages?

There has been some back and forth on whether image description pages should show a checkered background image (repeated over the dimensions of the picture) by default to indicate transparency (the alpha channel of the image). A poll will begin here on April 10, 2007 or later, once there is consensus on the arguments and options. The arguments are as follows:

Arguments in favor

• It helps to indicate the presence of transparency and therefore makes it easy to see on which backgrounds the image can be used.

Arguments against

• Wikipedia targets readers before editors. Readers and viewers will be distracted by an unexpected chessboard pattern showing up when they zoom into illustrations. The repeating, alternating pattern is unaesthetic and almost certainly not intended by the illustrator to show up in any published version of the image.
• Editors who need this pattern can add it to Special:Mypage/Common.css with relative ease. It may also be possible to implement a JavaScript which activates the overlay with a click, though this does not currently exist.
• No professional print publication would publish its highest quality illustrations on a chessboard pattern. If the argument is that artists should make a choice to use a particular background color, it is a very weak one, as common vector drawing applications use transparency in the background by default; there is no compelling reason why we should annoy our artists with unnecessary requests to add background imagery just to avoid the implicit activation of an undocumented "feature" that will distort their work once it is uploaded to Wikipedia.
• The place to work on images is Wikimedia Commons; there, a default pattern may be appropriate. Wikipedia is an encyclopedia, not an image repository, and our focus should be knowledge and education.