MediaWiki talk:Common.css/Archive 1

message: Please replace the ".Merge" and ".Merge td" styles with this code. Basically, this was mistakenly added as a "class", rather than an "id".  Note that in this CSS, disambig and spoiler are done as id, so this change is consistent.  Perhaps you could also group those template styles together so they are easier to see.
(code removed for space)
Let me know when this is complete, so I can correct the related templates quickly. -- Netoholic @ 21:22, 13 July 2005 (UTC)
replies: text: Ids are supposed to be unique on a given page; classes can be reused.  Multiple merge templates on the same page sometimes make sense, as recently seen on Wikipedia:How to create policy (even though the actual merges didn't). —Cryptic (talk) 22:58, 13 July 2005 (UTC)
replies: text:  You make a good point.  This is a good time to move to the class-only method.  I've changed the code above to a better scheme. You can see a test here using both divs and tables.  Can I get someone to add the new code? -- Netoholic @ 02:32, 14 July 2005 (UTC)
replies: text:  This has been completed.  -- Netoholic @ 04:31, 17 July 2005 (UTC)

text: Clear your cache.  That should solve it. -- Netoholic @ 16:33, 17 July 2005 (UTC)
replies: text:  It does work now. Normally purging the page is sufficient; in this case it wasn't. Let me guess: the CSS is cached no matter what... JRM · Talk 08:08, 18 July 2005 (UTC)
thread_title:  Merge template style 

message: In the German wikipedia I've added empty-cells:show; to the prettytable template. With it, adding " " or using other ugly tricks to get borders around all cells is unnecessary. My suggestion would be adding it to the "prettytable" class (or whatever it's name ends up to be), would be good as well. And yes, I know it won't work on older browsers. BTW, I stumbled upon the issue again, when looking at the article Comparison of accounting software in it's version (http://en.wikipedia.org/w/index.php?title=Comparison_of_accounting_software&oldid=20546718). For "normal" users, I'd assume it's a big help. --S.K. 19:23, 8 August 2005 (UTC)
thread_title:  empty-cells:show; for "prettytable"? 

message: Moved this thread from User talk:Lexor on 11:48, September 8, 2005 (UTC)
Hmmm. Why did you do this? First, I think there should be semicolons after "display : none ! important;", and second, plainlinksneverexpand should never expand links, whether in print or on screen... Lupo 09:13, September 8, 2005 (UTC)
:I am stumbling around trying to ensure that external links with class="plainlinksneverexpand" embedded in infoboxes like Template:Infobox Country don't get expanded in the print backend especially.  My CSS isn't great, if you can help me out, great.  I fixed the semicolon problem.  Lexor|Talk 09:24, September 8, 2005 (UTC)
:e.g, try doing "Printable version" of United States, because of the external co-ordinate link for Washington, the whole infobox consumes the entire screen real-estate.  I tried wrapping the link with a , and added a corresponding CSS rule in Common.css for class='external text' but for some reason it doesn't work the same as for the class='external autonumber'.   Lexor|Talk 09:28, September 8, 2005 (UTC)
:Here's a standalone testcase: User:Lexor/test.  If you click printable version, you should not see the external link in either case, but only the one with the autonumbering "[1]" is the external link supressed. Lexor|Talk
::Yeah, I see what you mean. Beats me. The "a.external.text:after" case you added should suppress this. Why it doesn't, I do not know. Lupo 10:29, September 8, 2005 (UTC)
:::Now I just added this:
 .plainlinksneverexpand a.external.text:after {
  display: none !important
 }
:::to my local customization monobook.css, and it works!  (try adding it to your User:Lupo/monobook.css), but it really should be applied globally, IMHO. Lexor|Talk 14:07, September 9, 2005 (UTC)
::::I moved it to MediaWiki:Monobook.css, seems to work there.  Mysterious, though.  Lexor|Talk 14:23, September 9, 2005 (UTC)
:::::Could this have something to do with the funny way MediaWiki:Monobook.css imports Common.css? What does "smaxage=2678400" mean? Lupo 14:39, September 9, 2005 (UTC)
::::::Dunno, could be, maybe.  Don't know what smaxage means, I'm guessing it limits the age of the edit it uses or something?  I guess try making other minor (test) modifications to Common.css and see if they take effect, maybe that's the problem, Monobook.css isn't "seeing" the changes to Common.css. Lexor|Talk 14:55, September 9, 2005 (UTC)
:::::::That "funny way" is exactly the same way the import of Monobook.css is done (view the source of any page and you will see). I made it that way exactly to avoid any possibility of the import not working (because if it didn't work, Monobook.css itself wouldn't work). Did you clear your cache after changing Common.css (Shift-Reload on Firefox)? Did you check with a CSS validator? --cesarb 00:39, 11 September 2005 (UTC)
thread_title:  Suppressing external links in print backend 

message: .wikitable should not define margins in the main class. There should be sub-classes, wRight, wLeft and wCenter, as the margins are dependent on table alignment. ed g2s • talk 14:32, 15 September 2005 (UTC)
replies: text: In the examples shown above in IE6 I do not see the caption separated by the margin! The margin goes neatly on top of the caption. I strongly urge to keep at least top and bottom margins, as removing them would disturn layout in most articles. Suppressing the right margin will hopefully not do too much harm and will allow both left and right alignment on table level. −Woodstone 19:34, 19 September 2005 (UTC)
thread_title:  Wikitable margins 

message: Padding is too small and text is too large. It looks strange. Either increase the padding, or decrease the font size. Thanks. —Cantus…☎ 06:28, 16 September 2005 (UTC)
replies: text: We changed the padding to a font-proportional size instead of a pixel size.  It looks the same as the old template on my screen.  Do you have an especially high- or low-res screen/big or small screen font?  Can you show a screenshot?  — Omegatron 13:38, 16 September 2005 (UTC)

text: It would help if you could reference the article where this table comes from, so we can compare. −Woodstone 08:14, 18 September 2005 (UTC)
replies: text: Tennis Masters Series. Oops :-) —Cantus…☎ 04:11, 19 September 2005 (UTC)

text: I like it smaller.  The screenshot looks great to me.  :-)  — Omegatron 00:23, 20 September 2005 (UTC)
thread_title: wikitable padding/font size

message: I would like to request that we consider accessibility as a priority. Moving to a stylesheet is probably a 'good thing' for accessibility.
However, there are still some features within the proposed standard style that could be improved. For example, the colours reduce contrast. It would improve access if contrast between text and background were increased.
People may also wish to check example pages with:
http://valet.webthing.com/access/url.html
Many thanks. Bobblewik 14:14, 20 September 2005 (UTC)
thread_title:  Accessibility 

message: I like the captions of the prettytable template better; at the bottom of the table and bolded.  What do others think?  — Omegatron 18:01, 21 September 2005 (UTC)
replies: text: At the bottom, but not bolded would be my preference, which is consistent with how it's done by default for pictures. −Woodstone 19:09, 21 September 2005 (UTC)
thread_title:  wikitable captions 

message: This page is now imported directly into the HTML for all skins. The @import lines can be removed from all the skin-specific CSS pages, after a few days have elapsed for cache expiry. -- Tim Starling 10:55, 23 October 2005 (UTC)
replies: text: Cool! I didn't expect my idea of creating a separate common CSS on the MediaWiki: namespace would go that far. --cesarb 19:31, 23 October 2005 (UTC)
thread_title: Imported directly

message: I'm shortly going to add a little bit of CSS to this file for the proposed new Main Page design. This is for testing purposes only, to check if this design works correctly live on Wikipedia. It will not alter the display of the live site. Please don't remove it for the moment. Thanks, Tom- 23:19, 25 October 2005 (UTC)
thread_title:  Main Page CSS 

message: I originally reported this here, not knowing where else to post it. I filed a bug and was referred here, so here's the original message, somewhat redacted:
There are two problems with the Common stylesheet that should be fixed ASAP. First, the  statement on line 225 should simply be removed: It is nonstandard and produces errors messages in Firefox's debugging console. Secondly, the  property on line 208 has no units (should be , I'm sure), which is invalid and also causes error messages. —HorsePunchKid→龜 19:36, 18 November 2005 (UTC)
thread_title:  Invalid CSS causing parsing errors in Firefox 

message: y with macron, ȳ, Unicode 233 hex, which is used in Old English morphology, appears as a box on my computer even though it is enclosed in Template Unicode. The same problem occurs with Template IPA: 
I use MSIE 6.0, and my fonts include Arial Unicode MS, Microsoft Sans Serif.
The problem appears to be that Arial Unicode MS appears before Microsoft Sans Serif in MediaWiki:Common.css, but Arial Unicode MS doesn't support codes 218-24F. I propose that the order of these two fonts be reversed. --teb728 01:31, 3 December 2005 (UTC)
replies: text: OK, let me restate this as a request rather than as a problem. Someone please put Microsoft Sans Serif ahead of Arial Unicode MS in the font list. --teb728 21:27, 14 December 2005 (UTC)
thread_title:  Font problem for y with macron 

message: It ain't working! When I print, it expands the external URLs. This is having a major effect in a few template:
* Template:Ref
* Template:Note
* Template:usc
* Template:usc-clause
Can someone fix this? - Ta bu shi da yu 08:08, 5 December 2005 (UTC)
replies: text: Probably not. It works fine in Firefox and Mozilla, as well as screen output in IE. However, it fails on print output with IE, where the ref links are still expanded. Seems to have something to do with a bug in IE relating to multiple class names (see , , ): the ref links have class="external autonumber" set (i.e., they're in two classes named "external" and "autonumber"), and that seems to confuse the print engine of IE. I've tried using only "external" or only "autonumber" in the CSS, duplicating any version and wrapping explicitly in a "@media print" block, explicitly setting the  of that ":after" pseudo-element to the empty string; but to no avail. Lupo 12:30, 5 December 2005 (UTC)
thread_title:  plainlinksneverexpand 

message: Since a large portion of people are color blind in some sense, we should address this quickly:
(copied from User talk:Jimbo Wales)
----
:Hi Mr. Wales, or Jimbo, which ever you prefer.
:I'm just inquiring about a recent change in the edit thingy. When you enter into "History" of an article & then click on the "Compare Selected Changes" button, the changes were shown in dark red. But now they are hardly visible, & for an editor with colourblindness, it is quite hard to see what changes people have made to the article. Could you please supply me with an answer if this will be changed or remedied or if it will stay the same.
:I would have posted this on the appropiate page, but I do not know of one, so selected you because you are the "Main Man" on Wikipedia I suppose.
:Regards, Spawn Man 23:15, 7 December 2005 (UTC)
thread_title: Need diff colors that are compatible with color-blind people

message: Seeing the edit http://en.wikipedia.org/w/index.php?title=List_of_The_Simpsons_episodes&diff=31567503&oldid=31556419 – where a hard-coded color is applied to every 2nd table row – earlier today made me think: "we need a standard color for highlighting stuff/text/table rows". How about adding
 table.wikitable .highlight,
 table.prettytable .highlight {
   background: #ececf6;
 }
to this CSS. Then we might simply use

{| class="wikitable"
|-
| one row || one row
|- class="highlight"
| another || another row
|}

instead of the hardcoded colors? --Fred Bradstadt 08:39, 16 December 2005 (UTC)
replies: text: I'm not a fan of this. It seems to narrow a usage, and I'd rather see us just leave that color choice up to the table author. -- Netoholic @ 14:17, 16 December 2005 (UTC)

text: Agreed.  Wikitable is a css'ed version of , which originally had highlighting, too, through , , etc.  Those should really be css classes that match with the user's skin, though, rather than hardcoded colors. — Omegatron 15:50, 16 December 2005 (UTC)
replies: text:  So are you proposing only red, blue, and gold highlights be added, or are we going to support the thousands of other possibilities that people may want to use?  How many tables really are using highlights awyway? -- Netoholic @ 16:00, 16 December 2005 (UTC)
replies: text: This must be a rhetorical question because obviously we aren't going to see thousands of classes created.  There is nothing wrong with having one (or just a few) standard highlighting that people can use that goes well with the standard CSS style.  And if someone feels he would rather go off and do something "funky" instead, he can do so (at least until someone else comes along and decides their idea of funky is better).  —Mike 01:17, 17 December 2005 (UTC)
thread_title:  Highlighting (wikitable) table rows