MediaWiki talk:Common.css/Archive 2

message: Per my Village Pump proposal, I'm going to be adding a bit of CSS to enable the creation of metadata (ala Personendaten in the German Wikipedia). This will allow us to try out some metadata schemes and hopefully implement some in the future. See this article for more info. Kaldari 19:27, 22 December 2005 (UTC)
replies: text: BTW, if anyone's interested, I've set up the first metadata project at Wikipedia:Persondata. It's gotten a lot of positive feedback so far. Kaldari 19:56, 2 January 2006 (UTC)
thread_title:  CSS for metadata 

message: See Template talk:Dynamic navigation box. Monobook contains the code missing in other CSS. -- User:Docu
: I disagree with this change completely.  You're using a template to perform a function which really should be added as a software feature. Templates should be used to replicate text among article, not change the fundamental navigation structure outside of the article body. -- Netoholic @ 19:31, 2 January 2006 (UTC)
replies: text: That's nice. But a lot of templates are used as navigational aids (navboxes, etc). See for example, . That the necessary code to make the show/hide buttons work isn't available in the other skins is something that should be rectified. —Locke Cole • t • c 19:42, 2 January 2006 (UTC)
thread_title: CSS for navbars

message: I have restored the specifications for the date display templates which got removed for no reason explained in the Edit Summary.
If this was a purposeful removal, then could whoever does it explain it here before doing it again, please?
HTH HAND —Phil | Talk 08:16, 5 January 2006 (UTC)
thread_title:  Restoring missing stuff 

message: As reported on Wikipedia:Village pump (technical)#Bug in Monobook.css there appear to be two errors in Common.css:
:Unknown property 'filter'.
:Error in parsing value for property 'line-height'. 
Also, this may be completely unrelated, but my Firefox fails to display certain images while IE is able to display them (cache cleared, control-shift-R tricks all tried in vain):
*:Image:Reflection_nebula_IC_349_near_Merope.jpg 
*:Image:Reflection_nebula_IC_349_near_Merope_full.jpg 
Most other images are fine, and IE seems Ok with these. -Wikibob 03:54, 13 January 2006 (UTC)
replies: text: Both errors were from the experimental main page stuff. I went ahead and changed the line-height:auto since it wasn't valid CSS. The filter thing is an IE only special deal. Should we keep it or scrap it? Kaldari 04:19, 13 January 2006 (UTC)

text: As for the images, check if you aren't using a misconfigured ad blocker. The first one has /ad/ on its URL, which is often indiscriminately blocked. --cesarb 04:51, 15 January 2006 (UTC)

text: Yes, the IE filter thing keeps popping up in my js console.  Can you hide it from non-IE browsers?  Apparently this recalc thing does it? — Omegatron 01:48, 18 January 2006 (UTC)
thread_title: Bug in Monobook.css?

message: (conversation moved to Wikipedia talk:HiddenStructure#CSS hack reduces accessibility) -- Netoholic @ 15:28, 27 January 2006 (UTC)
thread_title:  CSS hack reduces accessibility 

message: (conversation moved to Wikipedia talk:HiddenStructure#Why Not Weeble?) -- Netoholic @ 15:29, 27 January 2006 (UTC)
thread_title:  Why Not Weeble? 

message: (conversation moved/archived to Wikipedia talk:HiddenStructure#Change request) -- Netoholic @ 15:33, 27 January 2006 (UTC)
thread_title:  Change request 

message: (conversation moved/archived to Wikipedia talk:HiddenStructure#CSS hack reduces accessibility, confirmed) -- Netoholic @ 15:34, 27 January 2006 (UTC)
thread_title:  CSS hack reduces accessibility, confirmed 

message: Add this to your user css (User:YOURUSERNAME/monobook.css):
.audiolink a{
    background: url("http://upload.wikimedia.org/wikipedia/commons/f/f7/Loudspeaker.png") center left no-repeat !important;
    padding-left: 16px !important;
    padding-right: 0 !important;
}
and then reload this page:
* External audio link:
*: pronunciation
* External audio link with audiolink class:
*: pronunciation
* Internal audio link:
*: pronunciation
* Internal audio link with audiolink class:
*: pronunciation
This way people can click on the loudspeaker icon without going to the loudspeaker's image description page. If it works for everyone, can we add it to MediaWiki:Common.css and use the audiolink class where appropriate?
The icon should really be a system icon (in http://en.wikipedia.org/skins-1.5/monobook/), but we can use a (protected?) image from the Image: namespace for now.  I made a copy here to be protected, but maybe that's not necessary.
Same discussion here. — Omegatron 18:56, 18 January 2006 (UTC)
replies: text: Did you try looking at it with Firefox's DOM Inspector? It's usually very enlightening. --cesarb 18:33, 30 January 2006 (UTC)
replies: text: I didn't try any troubleshooting.  I didn't want to leave it in the sitewide css if it was breaking something.  Maybe I'll try later.  It works fine in my user css. — Omegatron 21:44, 30 January 2006 (UTC)

text: It's not working correctly there, either.  The speaker should be clickable and go to the same place as the link.  A non-clickable speaker is better than one that goes to the image page, though. :-) — Omegatron 21:46, 30 January 2006 (UTC)

text: It's basically the same code, and it works fine when I tried it in my user css.  The speaker is clickable and goes to the sound file directly.  I'll try to mess with the DOM inspector later. — Omegatron 18:57, 31 January 2006 (UTC)

text: I had assumed that would be the logical solution. Links to irc channels, to secure external websites, and to external websites, all automatically display an icon. Adding another filetype to the list shouldn't be difficult. -- Ec5618 10:47, 31 January 2006 (UTC)
replies: text: That's what bugzilla:3726 is for.  But do we really want it to display a speaker for all audio files?  I wanted to add it just for a specific class, so we could pick and choose.  I have code that will work for all audio files, too. — Omegatron 18:57, 31 January 2006 (UTC)
thread_title:  A solution 

message: I have created Wikipedia:Catalogue of CSS classes as a place to list and describe all the CSS classes (and IDs). The idea is to have a central place to put all the descriptions, instead of having them scattered all around the wiki. --cesarb 04:22, 3 February 2006 (UTC)
thread_title:  Catalogue of CSS classes 

message: I have been working to update the media templates to a semantic HTML/CSS version, but I need some opinions from CSS gurus.  The current templates use tables for visual layout and an inline image for decoration.  I propose changing these templates to a simple unordered list and doing the styling with a CSS class.  I've already added the (experimental) CSS to Common.css, and the list versions of the templates look like this:
=== Template:Listen ===
=== Template:Multi-listen_start ===
=== Template:Video ===
=== Template:Multi-video_start ===
If you turn off CSS, they just look like lists:
*  (file info)
** Chords being played on an accordion — 145 KB
** Problems listening to the file? See media help.
Questions:
* I have assumed that a list is better for accessibility, but I could be wrong about this.  I'm sure it's better than the table currently in use, but is something else better?
* I've replaced an inline image with a decorative background image.  Since it's just a decorative image, I figure this is good.  This will prevent people from clicking on it and going to the image description page, for one thing.  But maybe it's not?
* Should we genericize the list formatting as class="medialist", and have the individual classes like class="videolist" do nothing besides specify the icon?  That way if other templates are wanted it is less CSS to change:  I've done this.
Feedback:
* I think they look awesome. Nice templates. I'll be sure to use them when the need arises. —Michiel Sikma, 09:53, 8 May 2006 (UTC)
thread_title:  New style for media templates 

message: If you turn off CSS, they just look like lists:
*  (file info)
** Chords being played on an accordion — 145 KB
** Problems listening to the file? See media help.
Questions:
* I have assumed that a list is better for accessibility, but I could be wrong about this.  I'm sure it's better than the table currently in use, but is something else better?
* I've replaced an inline image with a decorative background image.  Since it's just a decorative image, I figure this is good.  This will prevent people from clicking on it and going to the image description page, for one thing.  But maybe it's not?
* Should we genericize the list formatting as class="medialist", and have the individual classes like class="videolist" do nothing besides specify the icon?  That way if other templates are wanted it is less CSS to change:  I've done this.
Feedback:
* I think they look awesome. Nice templates. I'll be sure to use them when the need arises. —Michiel Sikma, 09:53, 8 May 2006 (UTC)
thread_title:  [[Template:Multi-video_start]] 

message: I have been working to get rid of table-based visual layouts lately, and tried to tackle content in columns, like some people prefer with See also sections that have tons of links, etc.  I don't really like putting stuff in columns at all, but whatever; I might as well make them work well.  Besides, with the CSS-based layout, people who really don't like the columns can turn them off in their monobook.css.  ;-)  The original table-based templates are at , and my new div- and CSS-based ones are at Template talk:Columns.  I need feedback and it needs tweaking.  Bypass your cache if you don't see the example. — Omegatron 20:33, 19 March 2006 (UTC)
thread_title:  Columns of content without ugly tables 

message: In concert with MediaWiki talk:Monobook.css#Coordinates in article heading, Wikipedia talk:WikiProject Geographical coordinates#Coordinates at the top of the article, and bug 4719, need something like:
----
de:MediaWiki:Common.css
 /* Do not expand kvaleberg.com-URLs for printing */
 
 #content span.coordinates a.external.text:after, #content span.coordinates a.external.autonumber:after {
         content: "";
 }
----
:--William Allen Simpson 11:05, 21 March 2006 (UTC)
thread_title:  Coordinates in article heading 

message: Why do plainlinks have  padding: 0 ! important;?  It's overriding my user CSS.  I can't change the padding even with !important. — Omegatron 00:23, 24 March 2006 (UTC)
thread_title:  plainlinks padding 

message: Please see "Updates to CSS and JS pages to reduce redundancy". --Melancholie 00:45, 24 March 2006 (UTC)
thread_title:  Update Common.css to reduce redundancy 

message: A problem has been signalled with linked IPA strings in the discussion at wikipedia talk:Manual of Style (pronunciation). Such strings often contain diacritics and slight modifications under the base line. If such a string is underlined, readability is damaged. Therefore it would be better to suppress any underlining of IPA links. The IPA strings are supported by the template:IPA and the class IPA defined in this style sheet. Adding specific style elements for IPA links would achieve this, approximately as follows:
 
 .IPA a:link, .IPA a:visited {text-decoration: none}
Could someone check this out and add it? −Woodstone 16:46, 29 March 2006 (UTC)
replies: text: Strongly agree.  The underlining is very hard to read for some characters, but it's very useful to link various IPA characters to their respective articles.  Compare  vs. . —Simetrical (talk • contribs) 19:16, 22 August 2006 (UTC)
replies: text: Done. —Mets501 (talk) 03:49, 26 August 2006 (UTC)
thread_title:  Suppress underline of linked IPA 

message: ::Please answer at VPT:Highlight search box
A proposal that came out the Main Page Redesign discussions was:
*Improve visibility of the left-navigation search box in the default MonoBook skin, with an orange-colored border (as used on the active tabs at the top).
This would be to aid new users in finding the search box.
:::this is easily shown by adding this line to one's user/monobook.css. (and presummably common or monobook css for sitewide)
#searchBody {border-color: #FABD23;}
The only question remaining is can this highlight be easily coded to display on only select pages? (specifically the Main Page, and possibly any others we wanted to choose) (or only for non-signed-in users, or other useful permutations?) Or is it a choice of "site-wide or not at all"?
Once this is answered, I will copy the proposal to the proposal page. Thanks. --Quiddity 04:19, 6 April 2006 (UTC)
replies: text: You could probably do it by inserting a stylesheet altering #p-search directly onto the Main Page code. Unfortunately, I can't think of how to do this without having MediaWiki allow the <style> tag, which would be a major vulnerability. —BorgHunter ubx (talk) 03:23, 5 May 2006 (UTC)
replies: text: You could add it to the same Javascript file that hides the title header for the main page, maybe. But I recommend against it, since it's nothing but an inconsistent change in colors that only further confuses the user by the already abundant amount of colors on the main page. There's also zero feedback to let the user know exactly what this highlighted box means; sure, it's a search box, but why is it highlighted? Although the answer is obvious, it's not directly so. I think that perhaps the best way to make the search box more accessible to first-time users would be to move it to a different (yet logical) place (for example, right above the navigation box is not a logical place). I've got some ideas and will make mock-ups for them later. —Michiel Sikma, 12:23, 9 May 2006 (UTC)

text: Also, please note that a lot of people come in via http://www.wikipedia.com/ and will use the search box on the front page of the portal rather than the one right here. People who specifically come to http://en.wikipedia.org/ are the ones who have been there before and thus know how to navigate. —Michiel Sikma, 12:24, 9 May 2006 (UTC)

text: Here is what I'm talking about. —Michiel Sikma, 06:33, 11 May 2006 (UTC)
thread_title:  Highlight search box 

message: is a bit too low contrast.
Would someone please bump that up to this ? The tone is the same, but it's more of a tint than a shade, and easier on the eyes. Thanks.
 
--James S. 22:57, 11 April 2006 (UTC)
replies: text: I disagree. I like the old colors. And besides, I don't think you should just make changes that easily to a CSS property that affects a whole lot of templates which weren't designed for that color anyway. —Michiel Sikma, 06:30, 4 May 2006 (UTC)
thread_title:  .messagebox.standard-talk 

message: Like in subject.  This imposition is definitely not consensus, and causes problems for lots of people. Think disability community, for example; but also just pages that already use sizing of notes (which I don't think is a good idea either, but it's article-by-article).  If users want custom CSS, that's fine, but don't impose disruptive CSS on all readers. LotLE×talk 19:08, 4 May 2006 (UTC)
replies: text: There was consensus on WP:VPT. —Locke Cole • t • c 20:34, 4 May 2006 (UTC)
replies: text: This change was not discussed on a sufficiently visible forum.  The "consensus" consisted of exactly two (2) users.  More than that have already objected. --Blainster 21:25, 4 May 2006 (UTC)
replies: text: Yeah, the only thing I can find on this alleged "consensus" is a discussion where maybe 3 people thought it was a good idea, and 4-5 thought it was a bad idea.  And since then, numerous other editors have objected.  At the very least, someone with the power to do so (I'm not an admin) should roll it back pending actual consensus being reached about the fairly dramatic and system-wide change. LotLE×talk 21:46, 4 May 2006 (UTC)
replies: text: Please also look at the older discussion . There were more voices pro CSS. --Ligulem 21:49, 4 May 2006 (UTC)

text: The dissenters showed up after the change was made. AFAIK there were no dissenters prior to the change. —Locke Cole • t • c 22:04, 4 May 2006 (UTC)

text: I don't know how much more visible it could get than being discussed on the village pump twice. Maybe we should have asked for a notice to be placed in MediaWiki:Sitenotice too? *rolleyes* —Locke Cole • t • c 22:04, 4 May 2006 (UTC)

text: There seem to be many more people arguing against this change than there are arguing in favour of it. Quite apart from the fact that it seems to have been changed without sufficient discussion beforehand, even retrospectively there is nothing approaching a consensus in favour of the change. It should be reverted for this reason alone. If references are now unreadable for many users, then this makes the need to revert still more urgent – Gurch 06:56, 5 May 2006 (UTC)
thread_title:  Please, please, please revert harmful change 

message: The following CSS code should allow for dark/black wikitables and infoboxes. Significantly, this overrides the standard link colors so they'll work against a dark background.
This code should be placed below the existing wikitable CSS classes.
/* wikitable dark class for skinning tables/infoboxes */
table.wikitable.dark {
  background: #000000;
  color: #ffffff;
}
table.wikitable.dark th {
  background: #808080;
}
table.wikitable.dark a {
  color: #ffd447 !important;
}
table.wikitable.dark a:visited {
  color: #a5c969 !important;
}
table.wikitable.dark a:active {
  color: #0558ff !important;
}
This code should be placed below the existing infobox CSS classes.
/* Infobox dark template style */
.infobox.dark {
   background-color: #000000;
   color: white;
}
.infobox.dark a {
  color: #ffd447 !important;
}
.infobox.dark a:visited {
  color: #a5c969 !important;
}
.infobox.dark a:active {
  color: #0558ff !important;
}
If you'd like to see an example of this in use, please see User talk:Locke Cole/tvb. Please note that you'll need to copy the above CSS code into your userspace Monobook.css (or whichever skin you use). Note that the link colors are simply inversions of the existing link colors (hence why they're kind of ugly). If someone has a better idea for link colors, I'm all ears. =) But otherwise, I don't think there's anything else wrong with this (though I'd love some input from any CSS gurus out there). —Locke Cole • t • c 02:30, 5 May 2006 (UTC)
replies: text: Why? — Omegatron 17:53, 6 May 2006 (UTC)
replies: text:  Someone wanted to do an infobox with a black/dark background, but with links it was hard to read. The only way to override the link color is to do something like.. WikiLink. Obviously it'd be nicer if you could specify a different CSS class and have all the links changed automatically. —Locke Cole • t • c 21:11, 6 May 2006 (UTC)
thread_title: Dark tables/infoboxes

message: R. Koot, your change  specifically effected every browser except MSIE.  Furthermore, the font you specified, Arial Unicode MS, has a serious bug affecting its display of some IPA.  Please discuss changes to the style sheet before you make them.  —Michael Z. 2006-05-06 18:27 Z
What are the style .LatinX and .MUFI?  Where were these additions discussed?  —Michael Z. 2006-05-06 18:31 Z
: Okay, I found  and .  Is it not possible to create a single font list to roll  into ?  Shouldn't the class names and template names be capitalized the same way, to prevent confusion?  —Michael Z. 2006-05-06 19:21 Z
:: Replied at Michael's talk page. —Ruud 19:14, 7 May 2006 (UTC)
thread_title:  Undiscussed changes 

message: Please add
 .same-bg { background: none }
to MediaWiki:Common.css. Thanks, CWC(talk) 13:13, 3 June 2006 (UTC)
replies: text: Done. howcheng  {chat} 17:27, 7 July 2006 (UTC)

text: This CSS code is incorrect.  background: none sets the background image to none, not the background color, and so is superfluous (since background-images are generally impossible in MediaWiki).  The correct CSS style is background: transparent See the W3C specs.  Both appear to work in Firefox, but none might not work as expected in all browsers, since it's not standards-compliant.  Sorry, my bad, background is a sneaky attribute.  It resets everything unspecified to its initial values, so what you have does work if you don't care about resetting all the image-related background stuff.In any case, the default for table background should be transparent.  Look at Special:Movepage/Cat, for instance, for an example of the current Monobook's ugliness.  But that's a Monobook question. —Simetrical (talk • contribs) 22:32, 9 July 2006 (UTC)
thread_title:  Request for Edit 

message: Can someone add to table.wikitable font-size: 95% and change the padding to 0.4em? The table looks very "thin" and big right now and it is not aesthetically pleasing. Class="wikitable" looks so bad now that people are just not using it anymore and have gone back to using custom styled tables, which is exactly what we are trying to avoid in Wikipedia by using a Common style. For a comparison between the current style and what I'm proposing, see User:CieloEstrellado/tmp ☆ CieloEstrellado 03:14, 19 May 2006 (UTC)
replies: text: No one else wants that.  Just add table.wikitable {font-size: 95%;} to User:CieloEstrellado/monobook.css — Omegatron 20:56, 20 May 2006 (UTC)

text: Quite a while a discussion on this point (see above) has led to no change. Certainly no one agreed to more padding. Currently it is 0.2em. Making it 0.4em makes the table even thinner (your words). There was also no consensus for 95% font size, because many tables contain special characters that may become difficult to read. However, you can easily scale the font by setting  in a specific case. −Woodstone 12:07, 20 May 2006 (UTC)
replies: text: What good would that do? 95% font size is hardly even visibly smaller. It's imperative that we keep a consistent font size, anyway. I do think that it would be useful if the header of tables were in bold, though. —Michiel Sikma, 14:44, 20 May 2006 (UTC)
replies: text:  The headers of tables are in bold. — Omegatron 20:56, 20 May 2006 (UTC)
replies: text:  Oh, sorry, I didn't mean the header cells, I meant the captions. E.g.: —Michiel Sikma, 11:25, 21 May 2006 (UTC)

text: I agree.  I proposed this a while ago, when the class was still a template, along with putting the caption beneath the table, but it never happened. — Omegatron 14:00, 22 August 2006 (UTC)
thread_title: Table font sizes

message: Hey all. I thought that people who watch this page may be interested in a proposal that I've posted on Wikipedia:Village pump (proposals) about striping wikitables. It involves changing CSS and JS. It's posted here: Village_pump_%28proposals%29#Proposal:_striped_table_CSS_class_.2B_JS. —Michiel Sikma, 05:21, 22 May 2006 (UTC)
replies: text: I looked into the same thing. — Omegatron 14:34, 22 August 2006 (UTC)
thread_title:  Proposal: striped table CSS class + JS 

message: I've read over the discussion here, but it's a bit unclear to me as to what exactly the references class was originally meant for.  I thought it was just for footnotes (in long notes sections), and not reference sections, but that isn't clear.  Could someone confirm that for me? --Spangineer[es] (háblame) 13:11, 22 May 2006 (UTC)
replies: text: It is meant to be used in both the references and footnote sections (if such a distinction exists in the articles), but I've also seen at least one article use it for the external link section. —Ruud 13:35, 22 May 2006 (UTC)
replies: text: This duality could even be one reason why we aren't able to reach a consensus. I, for one, could live with smaller footnotes, but I'd like references to be normally sized (especially because they usually have lot of italics, bold, etc., as estabilished by the Cite web, Cite news templates). In any case, that's just my taste and it means pretty much nothing. What matters is that we can't allow style choices on a per article basis. Accessibility and best practices considerations apart, I have never seen an encyclopedia where each article uses its own typographical style for footnotes or references. —Gennaro Prota•Talk 14:12, 22 May 2006 (UTC)

text: I have replaced hard coded font size reductions with class references-small that I found in sections named like "Notes", "Footnotes", "References" and the like. Some example diffs might help (see my contribs for more): , , , , . --Ligulem 16:47, 22 May 2006 (UTC)
replies: text: Initially I started with hardcoded font size and as I later discovered the class, I changed to references-small class --Oblivious 18:25, 22 May 2006 (UTC)

text: Leaving this up to the individual authors of the articles to decide. Yes, that's what I'm doing. But I do replace hard coded size reductions on referencing stuff I find with the CSS class references-small. BTW a whole lot of FA had used hard coded 90%. I've replaced that on those articles with the CSS class references-small. What's the problem with that? This is clearly better than hard-coded 90%. --Ligulem 21:55, 22 May 2006 (UTC)
replies: text: We need a clear and stricter style guide for this. I've been working on a citation style guide in my user space which will also cover reference sizes in the future. Once it's finished, I'll link to it here; maybe we can use the ideas I'll outline for the official Wikipedia style guide if it is agreed with. It's at least a good idea to get some sort of policy going. —Michiel Sikma, 10:29, 23 May 2006 (UTC)
replies: text: Ligulem, you're doing exactly what I'd like; there's no problem.  Others have been systematically shrinking references sections using this new class, and I don't think that's a good idea. --Spangineer[es] (háblame) 12:23, 23 May 2006 (UTC)
replies: text: Ah. Ok. I agree that applying references-small to cases where the references previously were non-shrunken, is bad. But if it's the per article consensus, then better doing it with CSS. We simply can't decree that references should be 100% everywhere. There are too many fans of the smaller fonts for the references. We should try to keep going forward with that CSS references-small and only apply it where wanted. This is better than a failed try to centralize on a singly style that half of the wikipedians deliberately ignore and then resort to hard coded font-size "corrections" again. --Ligulem 13:17, 23 May 2006 (UTC)

text: I disagree with the rename. --Ligulem 15:23, 23 May 2006 (UTC)
replies: text: Me too. --Siva1979Talk to me 03:23, 26 May 2006 (UTC)

text: I disagree; the whole point of the class is to change the presentation of the section on a visual browser. --cesarb 22:00, 26 May 2006 (UTC)
thread_title:  References class in references sections 

message: The class "references-small" is named after its presumed presentation in a visual browser.  This is contrary to good authoring practices for semantic/structural HTML.  In text-only browsers and audible screen readers, this text will not be smaller, but it may be given a different colour, font weight, tone, pitch, etc.  We may decide to use the same format for sections other than "References", including Notes, Further reading, See also, and External links, e.g. supplementary sections.
I propose renaming the class "s-supp", an abbreviation of "section, supplementary".  Other future classes intended to apply to sections of an article could also be named with the s- prefix.  
References:
* Standardizing CSS class and id names
—Michael Z. 2006-05-23 14:44 Z
:I disagree with the rename. --Ligulem 15:23, 23 May 2006 (UTC)
replies: text: Me too. --Siva1979Talk to me 03:23, 26 May 2006 (UTC)

text: I disagree; the whole point of the class is to change the presentation of the section on a visual browser. --cesarb 22:00, 26 May 2006 (UTC)
thread_title:  Class name 

message: Could some admin please put a link to CSS somewhere in the comment section on the top? This would help the newbies learning what CSS is. Thanks! --Ligulem 17:03, 25 May 2006 (UTC)
replies: text: Done. —Ruud 13:20, 27 May 2006 (UTC)
thread_title:  Minor edit request: link to article about CSS in comment 

message: I created a syntax highlighting proposal a while ago, at WP:VPR#Syntax Coloring.  It seemed to making some headway, but Rick Block suggested I move it here:
===Proposal===
Currently, source code in Wikipedia looks rather dull: 
 /*
  * This is fake Java code to demonstrate syntax coloring.
  * */
 public static void main(String[] args)
 {
   String s = new String("This is a test");
   char ch = 'c' + 123;
 }
Would it be better if syntax coloring could be applied to the code?  Here is an example:
 /*
 <span
 style="color: rgb(0, 153, 0);"> * This is fake Java code to demonstrate syntax coloring.</span>
  * */
 public static void main(<span
 style="color: rgb(128, 0, 128);">String</span>[] args)
 {
   String s = <span
 style="font-weight: bold; color: rgb(0, 0, 255);">new</span> <span
 style="color: rgb(128, 0, 128);">String</span>(<span
 style="color: rgb(128, 0, 0);">"This is a test"</span>);
   char ch = <span
 style="color: rgb(255, 165, 0);">'c'</span> + <span
 style="color: rgb(51, 204, 255);">123</span>;
 }
To implement this, I had to use several  tags to achieve this, which makes the code almost incomprehensible.  What I am suggesting is a modification to MediaWiki:Common.css or MediaWiki:Monobook.css.  We would define styles for various types of words in a syntax block:
/* CSS code */
syntax key {
color:blue;
font-weight:bold;}
syntax string {color: maroon;}
syntax char {color: orange;}
syntax number {color: teal;}
syntax comment {color: green;}
In the source code, we could simply write out:
<syntax>
<comment>/**
this is a comment</comment>
<string>"Hey there!"</string>
</syntax>
This makes future editing much simpler.  If a certain user wished to customize the colors and styles, or turn them off, all he would need to do is modify his own CSS file.  This would also pave the way for a possible syntax highlighting tool, much like the <math> tool.  The parser would already have the styles in place.
Please, relay your thoughts to me. --  Talk [ (add)] 04:04, 23 May 2006 (UTC)
replies: text: I strongly oppose the use of colour in code samples. As most code samples in Wikipedia are very short, colour makes the code much harder to read (instead of easier, especially for people with vision problems). Any formatting of code can be done using bold and italic, which doesn't require any CSS classes. Also see Wikipedia:WikiProject Computer science/Manual of style (computer science). —Ruud 22:09, 26 May 2006 (UTC)

text: I tend to agree with Ruud — syntax highlighting is more likely to be a hindrance than a help in the case of most code on Wikipedia. Wikipedia shouldn't contain large chunks of code (that kind of thing is more appropriate for Wikibooks, or sites like LiteratePrograms). --Allan McInnes (talk) 22:56, 26 May 2006 (UTC)

text: Better not doing it in color. Syntax highlighting is ok for a programmer-editor, but not here. I agree with Ruud. --Ligulem 09:03, 27 May 2006 (UTC)

text: I also oppose color syntax highlighting. It might look "neat", but I really do not think it has much actual value for this context (especially since pseudocode is supposed to be used whenever possible anyway). I think it would just get in the way. However, if we do end up having this go through, please make sure the standard colors are tolerable for those of us with various forms of color blindness. -- Zawersh 06:57, 28 May 2006 (UTC)

text: Support. I think that Wikipedia should definitely do this. In fact, I can't see why this hasn't been done before. It's a great thing to be able to use the Web's capabilities to show color in code, something that books usually don't do simply for commercial reasons, as printing in color is expensive. This is a great thing and will help out the articles about code a lot. —Michiel Sikma, 19:09, 28 May 2006 (UTC)

text: Support. Articles would benefit from it. --Siva1979Talk to me 04:09, 16 July 2006 (UTC)
thread_title:  Syntax Highlighting Proposal 

message: Currently, source code in Wikipedia looks rather dull: 
 /*
  * This is fake Java code to demonstrate syntax coloring.
  * */
 public static void main(String[] args)
 {
   String s = new String("This is a test");
   char ch = 'c' + 123;
 }
Would it be better if syntax coloring could be applied to the code?  Here is an example:
 /*
 <span
 style="color: rgb(0, 153, 0);"> * This is fake Java code to demonstrate syntax coloring.</span>
  * */
 public static void main(<span
 style="color: rgb(128, 0, 128);">String</span>[] args)
 {
   String s = <span
 style="font-weight: bold; color: rgb(0, 0, 255);">new</span> <span
 style="color: rgb(128, 0, 128);">String</span>(<span
 style="color: rgb(128, 0, 0);">"This is a test"</span>);
   char ch = <span
 style="color: rgb(255, 165, 0);">'c'</span> + <span
 style="color: rgb(51, 204, 255);">123</span>;
 }
To implement this, I had to use several  tags to achieve this, which makes the code almost incomprehensible.  What I am suggesting is a modification to MediaWiki:Common.css or MediaWiki:Monobook.css.  We would define styles for various types of words in a syntax block:
/* CSS code */
syntax key {
color:blue;
font-weight:bold;}
syntax string {color: maroon;}
syntax char {color: orange;}
syntax number {color: teal;}
syntax comment {color: green;}
In the source code, we could simply write out:
<syntax>
<comment>/**
this is a comment</comment>
<string>"Hey there!"</string>
</syntax>
This makes future editing much simpler.  If a certain user wished to customize the colors and styles, or turn them off, all he would need to do is modify his own CSS file.  This would also pave the way for a possible syntax highlighting tool, much like the <math> tool.  The parser would already have the styles in place.
Please, relay your thoughts to me. --  Talk [ (add)] 04:04, 23 May 2006 (UTC)
thread_title: Proposal

message: The earliest comments are still on the original page.  Unsure of policy on this issue, I felt it was best not to copy their comments over.--  Talk [ (add)] 06:26, 26 May 2006 (UTC)
replies: text: I strongly oppose the use of colour in code samples. As most code samples in Wikipedia are very short, colour makes the code much harder to read (instead of easier, especially for people with vision problems). Any formatting of code can be done using bold and italic, which doesn't require any CSS classes. Also see Wikipedia:WikiProject Computer science/Manual of style (computer science). —Ruud 22:09, 26 May 2006 (UTC)

text: I tend to agree with Ruud — syntax highlighting is more likely to be a hindrance than a help in the case of most code on Wikipedia. Wikipedia shouldn't contain large chunks of code (that kind of thing is more appropriate for Wikibooks, or sites like LiteratePrograms). --Allan McInnes (talk) 22:56, 26 May 2006 (UTC)

text: Better not doing it in color. Syntax highlighting is ok for a programmer-editor, but not here. I agree with Ruud. --Ligulem 09:03, 27 May 2006 (UTC)

text: I also oppose color syntax highlighting. It might look "neat", but I really do not think it has much actual value for this context (especially since pseudocode is supposed to be used whenever possible anyway). I think it would just get in the way. However, if we do end up having this go through, please make sure the standard colors are tolerable for those of us with various forms of color blindness. -- Zawersh 06:57, 28 May 2006 (UTC)

text: Support. I think that Wikipedia should definitely do this. In fact, I can't see why this hasn't been done before. It's a great thing to be able to use the Web's capabilities to show color in code, something that books usually don't do simply for commercial reasons, as printing in color is expensive. This is a great thing and will help out the articles about code a lot. —Michiel Sikma, 19:09, 28 May 2006 (UTC)

text: Support. Articles would benefit from it. --Siva1979Talk to me 04:09, 16 July 2006 (UTC)
thread_title: Comments

message: Does anyone object to adding 
 * {
     font-family: "Arial Unicode MS", "Lucida Sans Unicode", sans-serif;
     font-family /**/:inherit;
 }
 textarea {
     font-family: "Arial Unicode MS", "Lucida Sans Unicode", monospace;
     font-family /**/:monospace;
 }
 pre {
     font-family: monospace;
 }
to Common.css? Disadvantage (Internet Explorer only): it overides the font selected by the user in their browser preferences, and can only be re-overridden by changing their own monobook.css. Advantage: it avoids situations such as this, this and probably many more. —Ruud 01:03, 27 May 2006 (UTC)
replies: text: P.S. I believe the default font in Internet Explorer is Arial, so for most users which have Microsoft Office installed (with which Arial Unicode MS ships) there should be no difference. —Ruud 01:05, 27 May 2006 (UTC)
replies: text: For the articles themselves we already have methods that should be used to mark unicode text so it displays correctly while not effecting the bulk of the body text (and your assertion that ariel and ariel unicode ms are identical for western text is not true). As for the edit boxes i'm not sure sacrificing a fixed width font is worth it. You could consider simsun for the edit box but i'm not sure how widely installed it is on western systems and it renders some ranges (such as greek) horriblly. Plugwash 01:09, 27 May 2006 (UTC)
replies: text:  The problem is that  is not used consistently. Using Arial/Lucida Unicode for textarea is optional, however I see little advantage in using a monospaced font as (unlike source code or HTML) wiki markup doesn't use any "alignment". —Ruud 01:38, 27 May 2006 (UTC)

text: I have added the proposed definitions to my monobook.css. I don't know if this produces the same as adding them to Common.css, but I noticed that the font of h1,h2,h3 as rendered on my Windows XP pro SP2 with IE 6.0 (patches all current) looks horribly bad. The fonts are rendered in a very poor resolution (I have 1280x1024 resolution on 19 analog CRT monitor and I use standard type smoothing of fonts - not Cleartype, which is for LCD screens). This does not happen without these definitions. If requested, I can upload/email a screen shot. --Ligulem 09:28, 27 May 2006 (UTC)
replies: text:  A screenshot would be helpful. —Ruud 13:13, 27 May 2006 (UTC)
replies: text: Without the proposed CSS modification: → :Image:Fonts-WinXP-PRO-SP2-IE-6-Wikipedia-test-1.png. With your proposed modification made in my Monobook.CSS → :Image:Fonts-WinXP-PRO-SP2-IE-6-Wikipedia-test-2.png. --Ligulem 14:25, 27 May 2006 (UTC)
replies: text:  In the second screenshot, font smooting is disabled entirely. I have no idea why that happens? Do you have Arial/Lucida Unicode installed? What happens if you select Arial/Lucida Unicode in Internet Settings > Fonts > Latin? Can anyone else reproduce this? —Ruud 15:41, 27 May 2006 (UTC)
replies: text: Do you have Arial/Lucida Unicode installed? I do have "Arial (True Type)", "Arial Black (TrueType)", "Arial Black Italic (TrueType)", "Arial Bold (TrueType)", "Arial Bold Italic (TrueType)", "Arial Italic (TrueType)", and "Arial Unicode MS (TrueType)". When I double click on "Arial Unicode MS (TrueType)" in the Fonts system folder, it get a window with font examples and information about the font. The 18 size font looks bad, all other examples look good. BTW I do have font smoothing enabled (set to standard, as noted above). My Arial Unicode MS has the following additional info: Arial Unicode MS (OpenType), OpenTypeFont, Digitally Signed, TrueType Outlines, Version: 1.01, Digitized data copyright (c) 1993-2000 Agfa Monotype Corporation. --Ligulem 16:27, 27 May 2006 (UTC)

text: I asked my brother. He has an LCD monitor with the same resolution as I have. He said it looks the same on his Windows XP pro as on my PC (he saw it on my PC), but only if he has set the font-smoothing to "Standard". If he has set it to "Cleartype", then it looks good (which is his ususal setting on his LCD monitor with digital interface). I conclude that this is a bug of the Arial Unicode MS font, that manifests if font-smoothing is set to standard. It looks good when font smoothing is set to "Cleartype", but that's not recommended for CRT type monitors. --Ligulem 16:35, 27 May 2006 (UTC)

text: What happens if you select Arial/Lucida Unicode in Internet Settings > Fonts > Latin? If I open "Tools → Internet options → Fonts" and do set "Arial Unicode MS" for Latin based Language script in IE, the rendered page in IE looks equally bad as when I use your new CSS definitions in my Monobook.css, that means it looks exactly as this one → :Image:Fonts-WinXP-PRO-SP2-IE-6-Wikipedia-test-2.png (which is lousy). Addendum: I forgot to remove your new CSS definitions from my monobook.css. Now, If I set "Tools → Internet options → Fonts" to "Arial Unicode MS" for Latin based Language script in IE, the rendered page looks good. --Ligulem 16:48, 27 May 2006 (UTC)

text: Hoho, Arial Unicode MS is a decent article... Should have read that before. Yes, really strange that smoothing is not supported in that range. --Ligulem 18:55, 27 May 2006 (UTC)
replies: text: This is likely because it's supposed to be an add-on to the existing Arial font in case some glyphs can't be displayed with it. These are usually characters that aren't hinted (mostly because there are so many of them, like the Chinese alphabet, for example). Unhinted anti-aliasing would look awful on those fonts, so it simply isn't. It's still very stupid that it indiscriminately turns off anti-aliasing for all glyphs, though. —Michiel Sikma, 21:09, 27 May 2006 (UTC)
replies: text:  They probably are hinted at 14-18pt but I think that hinting and smoothing are mutually incompatible. I can imagine that unhinted/smoothed CJK characters would look worse than hinted/unsmoothed ones. —Ruud 21:43, 27 May 2006 (UTC)
replies: text:  Well, yeah, they're hinted to show up okay without anti-aliasing, which is why those fonts look legible, but if you try to anti-alias such a font when it isn't hinted, it'll end up as a big black unreadable blob. —Michiel Sikma, 19:11, 28 May 2006 (UTC)

text: What's interesting though, is that they obviously did ClearType smoothing (which is for LCD monitors). I knew that my beloved electron canon in front of me is a doomed species... (I hate these lame duck LCD's). --Ligulem 21:39, 27 May 2006 (UTC)
replies: text:  As above, except that ClearType always looks better than hinting, so it overrides some "hint/do not smooth" setting in the font. —Ruud 21:43, 27 May 2006 (UTC)
thread_title:  Force font to Arial Unicode MS, Lucida Sans Unicode on Microsoft Internet Explorer 

message: Hi guys,
after an enervating discussion at template talk:languageicon we couldn't find any consensus on the final appearance of link language indications. However there were many requests for a less flashy design; thus I ask to add the following class to common.css, so that anyone wanting a more sober design can obtain it via his personal style sheet:
 .language-indication {
   cursor: default;
   font-family: sans-serif;
   font-size: 0.84em;
   font-weight: bold;
   color: navy;
   position: relative;
   bottom: 0.08em;
 }
This leaves the default aspect as it is now. Thanks —Gennaro Prota•Talk 18:30, 2 June 2006 (UTC)
replies: text: I personally think that this move (putting it in common.css) is premature as the template is not stable. Rather than a "no consensus", it's more a case of one user refusing to compromise and threatening an edit war if the template is changed, and a few other users opposing a more discreet design ignoring agreed-upon usability issues that would justify a simplification, and failing to provide any rationale for keeping it as it is. Please have a look at the discussion, your comments would be appreciated. PizzaMargherita 06:39, 3 June 2006 (UTC)

text: I just filed a RfC about this discussion, so please don't do it just yet. Thanks. PizzaMargherita 07:05, 3 June 2006 (UTC)
thread_title:  language-indication class 

message: I think it is time to remove the hiddenStructure class. This was originally incorporated here as an alternative to  for hiding conditional text in templates. However, there are a number of accessibility problems with this method and it has been obsolete since m:ParserFunctions were introduced as a built-in way of performing the same tasks. Most of the existing uses of 'hiddenStructure' were converted to the '#if:' parser function weeks ago without incident. There are doubtless some pages still using hiddenStructure, but I think it would take minimal time to locate and convert them once the class is removed. Perhaps some sort of public notice could be given that some templates may stop hiding conditional text and info on where to go for help converting them. Thoughts? --CBDunkerson 10:44, 8 June 2006 (UTC)
replies: text: Wouldn't it be a better idea to remove it after all uses have been replaced (or make all hiddenStructures show up red and blinking :). Typing "hiddenStructure" into the searchbox reveals that it is still used on a few pages. —Ruud 01:24, 11 June 2006 (UTC)
replies: text:  Yes.  Remove it from the site and then remove it from the stylesheet.  Or just remove it from the stylesheet and it will be removed from the site when it stops working... — Omegatron 14:41, 22 August 2006 (UTC)
thread_title:  hiddenStructure 

message: I want to use the prettytable settings on my wiki. My brute force approach was to copy http://en.wikipedia.org/wiki/Wikipedia:Common.css to my Common.css page, but this hasn't worked. Does anyone know how I can make something like this work? I am using MediaWiki 1.6.7.  dryguy 19:24, 19 June 2006 (UTC)
replies: text: You could probably copy http://en.wikipedia.org/wiki/Wikipedia:Common.css to your common.css page and http://en.wikipedia.org/wiki/Wikipedia:Monobook.css to your Monobook.css page. —Mets501 (talk) 12:58, 20 June 2006 (UTC)
thread_title:  Using Wikipedia Settings on Other Wikis 

message: Talk page notices are currently set at a standard width of 80%.  Looking at the spectrum of talk page templates in use in en:Wikipedia, this is creating inconsistencies.  It also, in my opinion, makes less than optimal use of the page.  The border and colored background is sufficient to draw attention to these notices.  Limiting the width to 80% is unnecessary.  I would like to reset this default to 100%.  Rossami (talk) 13:29, 24 June 2006 (UTC)
replies: text: Are there any objections or may I be bold?  Rossami (talk) 01:57, 13 July 2006 (UTC)
replies: text: There's a rather old style guideline on this at Wikipedia:Template standardisation, which agreed upon 85% as the width.  Personally, I find 100%-width boxes pretty ugly; I prefer 80 or 85%. —Simetrical (talk • contribs) 02:10, 10 August 2006 (UTC)
replies: text: Agreed. I feel that it would be appropriate to follow the style guidelines as much as possible. --Siva1979Talk to me 20:29, 10 August 2006 (UTC)
replies: text:  So am I asking in the wrong place?  Should I be asking somewhere else to change that particular style guideline?  I ask because the vandalism warnings in particular are creating an unreadable hash of many anon talk pages.  Templates that are typically at the top of the page (like ) are okay but some templates are intended for use in the body of the talk page (like ,  and all their variations).  When you have to start reading down the page, there is a confusing mix of text, template and table showing the various warnings, all with varying widths, colors, images, etc.  It's become quite difficult to sort through those pages when you need to investigate the history of a returning vandal.  Rossami (talk) 20:39, 10 August 2006 (UTC)
replies: text:  Point this discussion out on the village pump somewhere, that's all.  I was just mentioning the guideline, not saying you had to change it first — agreement to change the 80% size here would be sufficient to deem the guideline changed.  (It's already wrong, specifying 85% when the standard is 80%.)  Personally, I'd be okay with expanding to 85%, but no further, for the various pastel boxes.  On the other hand, messages directed at the one whose talk page it is shouldn't be in pastel boxes at all, they should read like ordinary messages; pastel boxes should be used only for general information of some kind. —Simetrical (talk • contribs) 01:19, 11 August 2006 (UTC)

text: 80% seems obviously better. — Omegatron 20:48, 10 August 2006 (UTC)
replies: text: Was that a typo? —Simetrical (talk • contribs) 01:19, 11 August 2006 (UTC)
replies: text:  I have no idea what that was.  Lack of sleep? — Omegatron 14:42, 22 August 2006 (UTC)
thread_title:  Width setting for Talk page notices 

message: Please see Wikipedia talk:Image copyright tags#Template standardization for discussion on standardizing these templates. —Simetrical (talk • contribs) 02:08, 10 August 2006 (UTC)
thread_title:  Standardization of image copyright tags 

message: Can anyone tell me what efforts are being made to keep consistancy between these two (and other sister projects) with respect to this rather important central resource? Why isn't there a master copy from Meta controlling? Or at least the same master used on both the English language defaulted commons and this en.wikipedia (The hands down 800# gorrilla of wikipedia's by article count!)<g>I'm curious, in that some text templates that were debugged and working fine are now evincing a variety of display issues including total disfunctionality.One of these manifested two weeks back (square 'undef'd character', irrc, seen first on the commons) before my vacation trip. I've been tripping on others since last evening on both sister projects. The sqaure 'undef'd' char box seems to point logically directly to this (Commons:MediaWiki:Common.css) specific  resource.See:  if you care to help sort through this vexation and are a code guru.While I didn't put that up for general consumption, in a nutshell, if it's not shown in bold (indicating a display 'nowiki' block, and hence the desired display effect) one should not be seeing any {s}, {space}, or {i} or {indent} manifestations in the captured HTML. Something prior to reverts (about 18:00, 17 August 2006) was causing total dysfunction. (Note: This post is heavily indented using the now 2X reverted1  [called via the  'eye' template]). // <B>Fra</B>nkB 20:00, 17 August 2006 (UTC)
thread_title:  [[Commons:MediaWiki:Common.css]] & interwiki problem