MediaWiki talk:Common.css/Archive 3

message: Currently, Titus Cyberbit Basic is listed first in the Unicode template.  However, this causes a lot of characters to not display at all (i.e. blank space appears instead) when surrounded with .  An example is the blackboard bold chars on Blackboard bold.  Surrounding them instead with  works for me, because some other font takes precedence; likewise if I de-install Titus Cyberbit Basic.  If I use the Symbol viewer on MS Word, it doesn't show the blackboard bold chars in Titus Cyberbit Basic at all, but for some reason MSIE gets confused.  Perhaps we can demote this font?
Benwing 00:29, 3 September 2006 (UTC)
replies: text: I see its been demoted one step below code2000, can someone check how it compares to the other fonts and decide if it shuld be demoted further. Plugwash 00:20, 4 September 2006 (UTC)
thread_title:  Remove or demote Titus Cyberbit Basic in template unicode 

message: Since I last looked here, a lot of classes have been moved across from monobook.css to here. Colour declarations for classes such as wikitable and infobox should be in monobook.css as they are specific to that skin. ed g2s • talk 09:44, 13 September 2006 (UTC)
replies: text: Depends on whether, in a given situation, it would be better to have Monobook-y colors or no difference at all.  They can be overridden in the other skins' stylesheets if someone's actually maintaining them; if they're not, plain text for infoboxes is much worse than colors that maybe clash with the skin.  They have to be set off one way or another.  Something like wikitable, yeah, color specs should probably go in Monobook.css, with the rest (margin, border, padding, weight, alignment) remaining here. —Simetrical (talk • contribs) 02:54, 14 September 2006 (UTC)
thread_title:  Common.css vs Monobook.css 

message: This page is getting too large. Should I archive the talk page? Any comments about this would be welcomed. --Siva1979Talk to me 20:11, 15 September 2006 (UTC)
replies: text: Just archive if you feel like it, usually take all from the start to the end of the last month and archive it. →AzaToth 21:45, 15 September 2006 (UTC)

text: Yes please. No need to ask, though. Assume consensus ;) --Ligulem 23:10, 15 September 2006 (UTC)
replies: text: Well, I have just archived the contents up to August 2006 comments. Hope it is up to satisfaction. --Siva1979Talk to me 02:08, 16 September 2006 (UTC)
replies: text:  You should really have only archived things that were "finished"; now they're just going to be brought up again.  And August is too recent. — Omegatron 00:54, 18 September 2006 (UTC)
replies: text: No big deal. If old things do re-pop-up, put a pointer into the archive. I agree though that up to August might have been a bit too early. But no harm done, Siva1979 did it fine in principle. Leave it as it is for now. --Ligulem 08:32, 18 September 2006 (UTC)
replies: text: Well, Omegatron, I will take your suggestions into account in any future archiving which I may be involved in. Thanks for pointing this out to me. --Siva1979Talk to me 19:09, 19 September 2006 (UTC)
thread_title:  Archive? 

message: Please revert combination of references small and references 2-column. Some people prefer single-column small references, and there are articles with layout assuming they will be a single column. Also, the 2-column CSS does not render as 2 columns on some common browsers. Gimmetrow 21:52, 24 September 2006 (UTC)
replies: text: Done. —Ruud 21:57, 24 September 2006 (UTC)

text: It is preferable to those who prefer it. Some editors consider two column footnotes to "look bad" in nearly all circumstances, so for them single column is nearly always preferable. The fact that some browsers to not render two columns is a problem, as it results in two different layouts. Only the most conscientious editors will verify the layout of both versions is acceptable. Gimmetrow 00:48, 25 September 2006 (UTC)

text: Please stop changing the reference style for individual articles.  If there is a good reason for references to be in a small font or double columns (there isn't), then get a majority of people to support it and the style will be changed for all articles.  It needs to be consistent.  There should just be a huge site-wide vote for it. — Omegatron 00:55, 25 September 2006 (UTC)
thread_title:  References small 

message: I think it's a really bad idea to introduce new elements in MediaWiki message pages and hide them using CSS display:none with yet another CSS hack class: . I don't see the purpose of a delete link on the what links here page (MediaWiki:Linkshere). This simply distracts, especially the non-admins, which seems to be the reason why people go for yet another client side hiding venture. This is just confusing and complete unneeded as admins do have a delete tab on each page, which non-admins don't have. Since we have currently two admins who disagree with me, I won't do anything more against that. But I strongly suggest we refrain from relying on yet another client side hiding feature. See also Wikipedia:hiddenStructure for why this is a bad idea (it was specifically deemed as bad by Brion Vibber, as you can read on that page). --Ligulem 12:10, 22 October 2006 (UTC)
replies: text: This is not a case where css-incapable browsers will display some odd kind of formatting or incorrect words or whatever.  There is no delete tab on the whatlinkshere page, and since that is the last page an admin is supposed to check before deletion, a delete link on that page is very helpful.  It is hidden by default for all users, and admins who want the link can add it themselves in their personal css.  If a browser cannot handle css, it will simply display the delete link for all users, which is not the end of the world. —Mets501 (talk) 12:52, 22 October 2006 (UTC)
replies: text: I sure know that there is no delete tab on on the what links here page. It's on the page itself (one click away). Deleting is an important action that needs quite some consideration, so I don't see the point to have it so prominent. What's so difficult to click back to the page you are deleting? We have had it like this for a long time already and I don't see the point in adding a delete link on other pages. Really, I don't see the point in creating this confusion. The tabs at the top of the pages are sufficient. --Ligulem 15:32, 22 October 2006 (UTC)

text: Great idea, but can you figure out a way to pass the article title to document.getElementById('specialDeleteLink').innerHTML? —Mets501 (talk) 15:43, 22 October 2006 (UTC)
replies: text: Hmmm. It looks like you could rely on this: MediaWiki talk:Common.css. You'd have to turn the spaces back into underscores and do a little bit more work, but I think JS code exists for that part (possibly in User:Lupin's popups code). Finding the "H1" elements with getElementsByTagName and getting the one with "firstHeading" should be reliable (considering this is on a special page). Mike Dillon 16:43, 22 October 2006 (UTC)
thread_title:  Hiding links with new .admin class 

message: For use in template:Navigation bar I'd like to add a class that makes list items inline, like the following: 
.scrollbarlist li {
  display: inline;
}
This would allow the "list" parameter to be specified as an explicit list of items, allowing traversal between them using the JAWS screen reader (as it stands, the entire list is a single list item).  This would facilitate JAWS traversal in a logically 2-level list, like Template:Footer Olympic Champions 4x400 m Men.  Sound reasonable? -- Rick Block (talk) 16:30, 22 October 2006 (UTC)
thread_title:  Class for inline list 

message: We seem to have yet another problem of ignorance regarding accessibility issues. See the reasoning of User:MatthewFenton at Template talk:Hiddenref. Do we really need to rule over minorities? Do we really need to discuss this again? We had all this discussed at nauseum on WP:AUM and Wikipedia:hiddenStructure. Carl and I are currently removing the hiddenStructure hack from a pile of remaining templates (see User:Ligulem/work/templates using hiddenStructure). Once this is done, I think we should finally remove
/* hiddenStructure from Monobook - allows selective hiding of markup in templates */
.hiddenStructure {
   display: none;
   speak: none;
}
from MediaWiki:Common.css. The 8 transclusions of Template talk:Hiddenref are not worth keeping this obnoxious hiddenStructure definition any longer. --Ligulem 18:09, 1 October 2006 (UTC)
replies: text: There are litterally thousands of palces this template can be transcluded to, it has also only be "alive" for two weeks. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 18:27, 1 October 2006 (UTC)
replies: text: I've put  on  Tfd --Ligulem 18:44, 1 October 2006 (UTC)

text: Then we must hope that no one are going to transclude the template to more places. →AzaToth 18:57, 1 October 2006 (UTC)

text: There are about two dozen pages which have the hiddenStructure class substituted in them. I'll be working on those. —Ruud 10:32, 13 October 2006 (UTC)

text: So now will you remove the hiddenStructure section from the Common.css? -- Netoholic @ 05:17, 23 October 2006 (UTC)
replies: text: No. As long as there is a hiddenStructure definition in for example http://en.wikipedia.org/skins-1.5/monobook/main.css (which is loaded before common.css) we should override it here. Removing the current hiddenStructure override from Common.css currently would simply reenable hiddenStructure as it was before. Plus the current marking helps identifying residuals/reinsertions. --Ligulem 08:41, 23 October 2006 (UTC)
replies: text:  So wait, let me understand, you've decided to disable a component that was put into the MediaWiki software by the developers?  Brazen.  Where was consensus reached that HiddenStructure needed to be made extinct? -- Netoholic @ 17:36, 23 October 2006 (UTC)
replies: text:  Every meaningful style rule added to Common.css is disabling (or modifying) a component that was put into the MediaWiki software by the developers.  I have no idea why Gabriel Wicke added the class to his skin, but I join Brion et al. in saying that it's a bad method for accessibility.The class is not, by the way, ever used in a default MediaWiki install, so removing it doesn't break existing behavior if all templates are fixed. —Simetrical (talk • contribs) 04:48, 24 October 2006 (UTC)

text: The only reason hiddenStructure has stuck around this long is that it isn't easily traceable (by just clicking on a link). Community consensus from the 'AUM wars' was entirely clear... as were the developers. Hiddenstructure was a bad method for solving a 'performance problem' which didn't really exist. There is nothing which can be done with hiddenstructure that can't be done with parser functions... except that hiddenstructure works improperly on some browsers. Which hardly ought to be our goal. See other info on hiddenstructure and why it has been eliminated here. --CBD 22:44, 24 October 2006 (UTC)
thread_title:  hiddenStructure again 

message: Jitse, I used your code. It works great. How shall we add this to the main CSS page? I would like to start using it. -- Ganeshk (talk) 18:13, 7 November 2006 (UTC)
replies: text: It does not affect any existing things, so there is no harm.  I've added it now.  See  for how to add the optional small parameter. —Mets501 (talk) 19:30, 7 November 2006 (UTC)
replies: text: Thanks! -- Ganeshk (talk) 19:38, 7 November 2006 (UTC)
thread_title: Implementation

message: Hard-coding navbox width here at 100% could cause some problems, especially because smaller navboxes often look much better than ones that fit the entire page.  If there are no objections, I move that we remove this clause from the CSS, because I don't think it really does anything useful.  I can't think of any possible advantages of guaranteeing that every navbox on the entire site has 100% width.  Karl Dickman talk 21:22, 8 November 2006 (UTC)
replies: text: I object: having multiple navboxes with different widths in the same article looks horrible, see User:R. Koot/navbox. 100% makes the navboxes have the same width as the category bar, making them stand out less, which is a good thing in my opinion. —Ruud 22:05, 8 November 2006 (UTC)
replies: text: I maintain that all the examples have too many navboxes.  WikiProject Aircraft, for example, discussed writing a policy that would essentially limit the page footer to no more than one navbox.  Although the policy has not yet been officially implemented (added to the standards pages and applied to the articles), it received virtually no objections.  Karl Dickman talk 00:47, 9 November 2006 (UTC)
thread_title:  Navbox width 

message: Why have all rollback links suddenly made boldface? (Radiant) 21:37, 18 November 2006 (UTC)
replies: text: Yup. Looks ugly in bold. --Ligulem 00:05, 19 November 2006 (UTC)
replies: text: Undone for now (because I don't see any discussion on the subject and I do see dissent here). (Radiant) 14:36, 20 November 2006 (UTC)
replies: text: They used to be bold when viewing diffs, but not when viewing a user's contribs. (This was before they existed on page histories) – Gurch 12:25, 23 November 2006 (UTC)
thread_title:  Rollback 

message: FireFox's error console reports the following CSS error on every page:
 Warning: Unknown property 'column-count'.  Declaration dropped.
 Source file: http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=2678400
 Line: 33
An error, cross-browser compatibility issue, or typo? haz (talk) e 20:23, 6 December 2006 (UTC)
replies: text: This has been discussed at MediaWiki talk:Common.css/Archive 2#references-2column class breaks Firefox and MediaWiki talk:Common.css/Archive 3#Minor non-compat bug. I believe it was left as is as a "harmless" compatibility issue. Mike Dillon 21:35, 6 December 2006 (UTC)
thread_title:  CSS error 

message: Many cleanup templates use the messagebox style and a table to align images.  This table must have the attribute style="width:100%;background:none" to behave as expected.  Can we add the following to common.css?
.messagebox table {
  width:100%;
  background:none;
}
Which would eliminate that inline styling. -- PatrickFisher 00:38, 8 December 2006 (UTC)
replies: text: I've just removed such a 100% from Template:Unreferenced which solved this problem posted at Template talk:Unreferenced#Layout problem with Infoboxes. So I wonder if this is a good idea. --Ligulem 13:12, 17 December 2006 (UTC)
thread_title: Messagebox tables require inline styles

message: Does anyone object to increasing the font-size of .references-small to 92%? The references are significantly smaller on Firefox than on IE (also see :Image:Footnotes90from"Alexander Litvinenko poisoning".png) and some users find them too small. —Ruud 19:08, 18 December 2006 (UTC)
replies: text: The larger the better. No problem with increasing to 92%. It just hope this change won't disturb the current wiki-peace about the fontsizes.... :] --Ligulem 23:09, 18 December 2006 (UTC)

text: OK, back to the original question. As long as the output is the same in both browsers, with default settings, that's good enough for me. That means 85% or 92%, but not 90%. However, I actually find 85% better. Just look at United States, there are 107 references! --ChoChoPK (球球PK) (talk | contrib) 20:06, 18 December 2006 (UTC)
replies: text: So 91% and 90% are the same in both browsers. My opinion above is holds. --ChoChoPK (球球PK) (talk | contrib) 21:37, 18 December 2006 (UTC)
replies: text: Oh gee. Look at that screenshot with font hinting in Linux. So THAT's why that guy kept complaining that he found 90% too small, and that we should use 92% instead. He just doesn't like small text at all, he would rather have the references look almost the exact same as 100%. References are supposed to look small. They do look smaller now that we use a font size of 90%. But if we change it to 92%, that means that the references will appear almost completely identical to most Linux users (most distros have Bitstream Vera Sans and have font hinting set to medium/high). This reduces cross-platform consistency pretty badly.  11:47, 19 December 2006 (UTC)
replies: text:  This proposal is partly motivated by a desire for a consistent appearance, and to reduce the instances of style="font-size:XX%" on individual wikipages.  is one of the larger systematic sources of font-size tags, and it sets font-size to 92%. The custodians/users of that template have been resistent to replacing style="font-size:92%" with class="references-small" within the template because of the 90%. Gimmetrow 21:42, 20 December 2006 (UTC)
replies: text: I'm talking about cross-platform consistency. If all font sizes for the references were at 90%, they'd be more consistent than if they were all at 92%. I believe that 85% may be even better. Again, I should mention that the purpose of having a smaller font for references is so that they look smaller... not so that they look nearly the exact same as normal text. That's really my gripe with this.  22:58, 20 December 2006 (UTC)

text: My point is that as it currently stands, some articles have 90% notes, and others have 92% notes. Even from the same browser some articles look different than other articles because not all are using the CSS class.  If the CSS had 92%, we could eliminate one of the largest cases not using the CSS class. If that could be done without upsetting other things, great! If not, that's fine too. Gimmetrow 23:46, 20 December 2006 (UTC)
replies: text: We don't have to bend over backwards for things that don't have consensus.  If consensus is against 92%, then change the template to 90%, and if someone gets ornery and refuses to accept consensus, follow the usual procedures.  I'm agnostic on small refs, but I agree that 92% is basically indistinguishable from 100% on Firefox. —Simetrical (talk • contribs) 07:02, 21 December 2006 (UTC)
thread_title:  .references-small -> 92% 

message: There are 3 types of rows
.infobox.geography .mergedtoprow td,
.infobox.geography .mergedtoprow th {
   border-top: solid 1px #ccd2d9;
   padding: 0.4em 0.2em 0.2em 0.8em;
/* top 0.4, bottom 0.2 */
}
.infobox.geography .mergedrow td,
.infobox.geography .mergedrow th {
      border: 0;
      padding: 0 0.2em 0.2em 0.8em;
/* top 0, bottom 0.2 */
}
.infobox.geography .mergedbottomrow td,
.infobox.geography .mergedbottomrow th {
   border-top: 0;
   border-bottom: solid 1px #ccd2d9;
   padding: 0 0.2em 0.4em 0.8em;
/* top 0, bottom 0.4 */
}
 correctly implements row groups (several rows enclosed by the same visible borders) with the first being , the last being , and everything in between with . Examples include ,  ... up to 5.
All these leader titles are optional. So any one of them could be the last one.  handles this by something like

print leader 2
This is to assume that editor will always fill the leaders with the correct sequence from 1 up. This may not be perfect, but good enough. However, I'm facing a difficulty with , which is being sandboxed at User:Chochopk/Template sandbox 2. In the currency infobox, there are many row group where any attribute is optional, and there's no sequential dependency. The prime example is the subunit symbol. It is not at all unlikely that there is no symbol for subunit 1, but there is for subunit 2, like the case for the United States dollar. The same problem exists on nickname, ERM, used coins and banknotes, etc.
So I have no way of telling which row is the last row. Let's say that I don't insist on the 0.4-0.2-0.4 set up, I use 0.4-0.4-0.4. I have 2 ways of doing this:
# write  for many many rows in my infobox
# add something like  or  to the css with 0 0.2em 0.4em 0.8em
#1 is a hack and impractical to deploy widely to similar infobox, and I don't have the permission to do #2.
What do you think? --ChoChoPK (球球PK) (talk | contrib) 03:04, 21 December 2006 (UTC)
replies: text: We should not be writing specific infobox classes, and definitely not overriding the colour. Can't you just use the mergedrows class? ed g2s • talk 17:39, 24 December 2006 (UTC)
replies: text:  OK, I can use inline style, I'm fine with that. But what's up with the recent change about "moving style to monobook.css"? I use monobook and  an  certainly look different. Isn't this supposed to be just a move? I don't see .infobox.geography anywhere. --ChoChoPK (球球PK) (talk | contrib) 21:00, 24 December 2006 (UTC)
thread_title:  geography infobox style 

message: I have reverted this on the grounds that there seems to have been no discussion of this change at WP:VPT.  Before making such drastic changes, please make sure that you actually have people who support your decision.  So far, at least two of us have reverted you.  Karl Dickman talk 22:54, 25 December 2006 (UTC)
replies: text: Nothing's changed, I just moved the colour over to monobook, as the colour is skin specific. If you are using a different skin, then add the correct colours to the skin file. ed g2s • talk 04:31, 26 December 2006 (UTC)
thread_title:  Removal of styling information for wikitable and infobox classes 

message: Right Id names  #privacy, #about, #disclaimer was fixed in revision 18763, so this can be removed from common.css . --Li-sung 09:13, 2 January 2007 (UTC)
thread_title:  Useless link in printout fixed 

message: What talk page headers was reducing the font size of this disrupting? In general, a template needs to handle various sizes properly anyway, because people are using different systesms with different font sets and using different sizes. —Centrx→talk • 23:41, 30 December 2006 (UTC)
replies: text: It wasn't disrupting in the sense of breaking, but it looked awkward on templates that were not talk page templates but were using that class (which is actually a surprising number of templates). —Mets501 (talk) 02:51, 31 December 2006 (UTC)
replies: text: Okay, we should move those to a new class then. Why are people using "standard-talk" on things that have nothing to do with talk. Not having to making individual edits everywhere is the whole point of CSS. —Centrx→talk • 03:26, 31 December 2006 (UTC)
replies: text: Where are the ones that are a problem? —Centrx→talk • 03:39, 1 January 2007 (UTC)
replies: text: Things like  looked sort of awkward.  It's really the main focus of a bot's userpage, and yet it would be small if the font size were changed. —Mets501 (talk) 16:07, 1 January 2007 (UTC)
replies: text: Okay, I changed that to use the regular messagebox class. Any other templates? —Centrx→talk • 00:47, 4 January 2007 (UTC)
thread_title:  Font size of message box standard-talk 

message: I can't seem to add this to my own wiki without receiving a message that says that I'm a "link spammer" or something. What's going on and can anyone help? Sana Jisushi 00:53, 16 January 2007 (UTC)
replies: text: I'm not sure what it is you're trying to add, but you might want to try editing Monobook.css with a admin account. What version of MediaWiki are you using? You might also want to look at the setting of $wgSpamRegex. Mike Dillon 01:07, 16 January 2007 (UTC)
thread_title:  "Hello link spammer" 

message: 
There's some inconsistency in edit-screen messages at the moment; it was suggested on MediaWiki talk:Talkpagetext that there should be a CSS class that can be used for consistent styling. I'd like the following to be added to common.css (originally taken from MediaWiki:Longpagewarning:
 .editscreenmsg {margin: 0 0 1em; padding: .5em 1em; vertical-align: middle; border: solid #aaaaaa 1px}
(It could be argued that this should go in monobook.css, as it's an interface message, but placing it in common.css is the least change to the current situation.) It would be nice if MediaWiki:Talkpagetext, MediaWiki:Longpagewarning, and MediaWiki:Newarticletext were all updated to use the new class (resulting in no visible changes to the first two, and only a slight change to the third), but I'll put up  messages after the class is added if necessary. --ais523 09:16, 7 December 2006 (UTC)
replies: text: Isn't this what .standard-talk is for? —Simetrical (talk • contribs) 02:31, 8 December 2006 (UTC)
replies: text: standard-talk is for divs/tables placed at the top of a talk page. This is for divs/tables added by the software above the edit box when editing a page, and looks quite different. --ais523 14:56, 12 December 2006 (UTC)

text: The discussion has now been archived: . Could we have a done/not done for my and/or Simetrical's suggestion? --ais523 13:26, 17 January 2007 (UTC)
replies: text: Not done.  Please decide which you wish made. Proto::► 18:21, 5 February 2007 (UTC)
thread_title:  Consistent styling for edit-page messages 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: Note that all skins support the namespace classes. —Simetrical (talk • contribs) 01:11, 9 March 2007 (UTC)

text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)

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

message: I know it has been [[/Archive 3#.references-small -> 92%|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)
replies: text: 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)
thread_title:  references-small again 

message: 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)
replies: text: 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)

text: 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)

text: Reverted. —Ruud 12:08, 24 March 2007 (UTC)
replies: text: Much better, thank you. --After Midnight 0001 14:15, 24 March 2007 (UTC)

text: 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)
replies: text: True, but the child selector is so common I though all major browsers supported it. →AzaToth 15:30, 24 March 2007 (UTC)
replies: text:  Never trust anything to just work in IE ;) —Ruud 19:54, 24 March 2007 (UTC)
thread_title:  Wikitable changes 

message: 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)
replies: text: Sounds good. —Centrx→talk • 02:23, 17 February 2007 (UTC)

text: 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)
replies: text: If you could do this with CSS, I'd be very impressed ;) Mike Dillon 02:11, 18 February 2007 (UTC)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  About to remove checkerboard background 

message: 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)
replies: text: 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)
thread_title:  Consistent padding for "div.NavFrame" and "table.navbox" 

message: 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 , 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)

text: 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)
replies: text:  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)
replies: text:  Help:Multilingual support would be a great place. —Ruud 12:16, 30 March 2007 (UTC)
replies: text:  Thanks. I'll try to add a section to there. —Yoshigev 13:34, 30 March 2007 (UTC)
thread_title:  Unicode/IPA class doesn't work with IE7 

message: I think we should use CSS so that some boxes, such as TOCs, "pseudo-category" type boxes like the lists at the foot of Birmingham,and perhaps infoboxes, don't print. Guidance could be given on how to override this, for those who must waste trees. Or at least we should provide tools to make individual boxes not print. Thoughts? Andy Mabbett 13:07, 4 April 2007 (UTC)
replies: text: Anyone? Andy Mabbett 11:07, 9 April 2007 (UTC)
thread_title:  non- printing areas 

message: Why do we need a poll on this? It won't effect anything substantial at all, and the people lamenting that it looks ugly can (as they so kindly pointed out) easily override it. Why waste the community's valuable time with a poll over such a completely trivial issue? --tjstrf talk  15:38, 5 April 2007 (UTC)
replies: text: You are free to ignore this poll. —Ruud 20:42, 5 April 2007 (UTC)
replies: text: Yes, of course. However, that doesn't answer my question. Why are we having a bureaucratic poll over something completely insignificant? --tjstrf talk  20:58, 5 April 2007 (UTC)
replies: text:  Because "we" would like to determine what the general opinion on removing or keeping the checkered background is. Those who are in favour of it or against it can voice their opinion, whose who think it is insignificant can ignore the poll. It's an efficient way of consensus building and in no way bureaucratic. —Ruud 00:57, 6 April 2007 (UTC)
replies: text:  Are there any viable alternatives to polling? --Aarktica 22:31, 9 April 2007 (UTC)
replies: text:  You might consider to participate in the discussion above :-) Cacycle 22:51, 9 April 2007 (UTC)
replies: text:  Which one? --Aarktica 23:03, 9 April 2007 (UTC)
thread_title:  Why do we need a poll on this? 

message: *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)
replies: text: 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)

text: Looks good; validates. Andy Mabbett 22:17, 1 April 2007 (UTC)
replies: text: I added it to the CSS file. It validates under CSS 3. CMummert · talk 00:38, 2 April 2007 (UTC)
thread_title: Outdent 2

message: 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.
* All the arguments against are on the basis that the pattern is distracting, however the pattern is so light and subtle it doesn't actually distract from the image.
* It highlights errors in an image, such as the incorrect use of transparency, or missing transparency. Typical errors include the use of transparency to make images "lighter", rather than the use of lighter colors.
* Most editors won't know how to / be bothered to add it to their own stylesheet, meaning these errors will often go unnoticed.
* Transparency can often convey important information in an image, such as the difference between a hole, filled disc.
** If the information is important, it should not depend on the presence of a checkerboard pattern in the background.--Eloquence* 14:30, 2 April 2007 (UTC)
replies: text:  Of course there's not going to be a consensus about what is or isn't unaesthetic. Some people might love to have little ponies in the background of each image. However, the point here is that we as Wikipedia are making a particular choice what to show in the background of images that someone else created, a choice that affects both the aesthetics and the usefulness of the image. We are making that choice, as has become very clear, to aid editors.--Eloquence* 00:48, 3 April 2007 (UTC)
replies: text:  Is agree with ed_g2s, the pattern is not shown in articles to the public, is is only shown on image description pages for editors who intend to use the image in articles or want to re-use them. They definitely need to know about transparency, and aesthetic questions are of less importance there. Cacycle 16:41, 2 April 2007 (UTC)
replies: text:  Uh, what? Both the "zoom" link and the main link around the image take a reader to the image page. That is the page that includes the full size view of the image, which is intended as much for readers as for editors to see details of the image that are lost in the thumbnail. The thumbnail is only a preview; the image page is the full view. And that is where the transparency pattern is shown. The argument that this is not a "published" use is very divorced from reality; this website is where most readers will be exposed to these images, and it includes the chessboard pattern.--Eloquence* 00:10, 3 April 2007 (UTC)
replies: text:  I strongly doubt that a typical reader ever intentionally visits the image description page (other than for inadequately scaled images in articles, which should be fixed in the articles). Cacycle 20:26, 12 April 2007 (UTC)

text: *Further, the option to show a checkerboard pattern on description pages only could be added in Preferences, under Files, and turned off by default - if a user prefers checkered transparency, they will be able to turn it on. —The preceding unsigned comment was added by Vanderdecken (talk • contribs) 14:17, 2 April 2007 (UTC)

text: comment we have enough js on this site already. A page load very slowly on my browser compared to other sites. --ChoChoPK (球球PK) (talk | contrib) 14:27, 2 April 2007 (UTC)
replies: text: If you're worried about the time it takes the load the script, the script should be cached by your browser. If your worried about execution time, this script won't do anything until you click the "show transparency" button or whatever it is. ed g2s • talk 15:43, 2 April 2007 (UTC)

text: Wikipedia's loading time is mainly due to slow servers.  A couple hundred KB of CSS and JavaScript that's heavily cached anyway is not the issue. —Simetrical (talk • contribs) 17:03, 2 April 2007 (UTC)

text:  As a (inline) javascript it would take only about 100 characters, that is negligible. Cacycle 17:05, 2 April 2007 (UTC)

text: Transparency indicated by , click here for a white background
The link would use inline-javascript to change the background style or would reload the page with a white background if JavaScript is turned off. Cacycle 17:02, 2 April 2007 (UTC)
thread_title:  Poll on transparency issue 

message: * It helps to indicate the presence of transparency and therefore makes it easy to see on which backgrounds the image can be used.
* All the arguments against are on the basis that the pattern is distracting, however the pattern is so light and subtle it doesn't actually distract from the image.
* It highlights errors in an image, such as the incorrect use of transparency, or missing transparency. Typical errors include the use of transparency to make images "lighter", rather than the use of lighter colors.
* Most editors won't know how to / be bothered to add it to their own stylesheet, meaning these errors will often go unnoticed.
* Transparency can often convey important information in an image, such as the difference between a hole, filled disc.
** If the information is important, it should not depend on the presence of a checkerboard pattern in the background.--Eloquence* 14:30, 2 April 2007 (UTC)
thread_title:  Arguments in favor 

message: * 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.
** Readers may also want to know if an image has transparency if they are intending to reuse the image. Apart from disagreeing with your opinion that the pattern is unaesthetic, I also question your assertion that no illustrator would create an image for which they expected the transparency to be made apparent by such a technique. I also question the suggestion that the Image: page should be consisdered the "published version" of the image. I doubt any Wikireaders would include the Image: namespace. ed g2s • talk 15:58, 2 April 2007 (UTC)
replies: text:  Of course there's not going to be a consensus about what is or isn't unaesthetic. Some people might love to have little ponies in the background of each image. However, the point here is that we as Wikipedia are making a particular choice what to show in the background of images that someone else created, a choice that affects both the aesthetics and the usefulness of the image. We are making that choice, as has become very clear, to aid editors.--Eloquence* 00:48, 3 April 2007 (UTC)
replies: text:  Is agree with ed_g2s, the pattern is not shown in articles to the public, is is only shown on image description pages for editors who intend to use the image in articles or want to re-use them. They definitely need to know about transparency, and aesthetic questions are of less importance there. Cacycle 16:41, 2 April 2007 (UTC)
replies: text:  Uh, what? Both the "zoom" link and the main link around the image take a reader to the image page. That is the page that includes the full size view of the image, which is intended as much for readers as for editors to see details of the image that are lost in the thumbnail. The thumbnail is only a preview; the image page is the full view. And that is where the transparency pattern is shown. The argument that this is not a "published" use is very divorced from reality; this website is where most readers will be exposed to these images, and it includes the chessboard pattern.--Eloquence* 00:10, 3 April 2007 (UTC)
replies: text:  I strongly doubt that a typical reader ever intentionally visits the image description page (other than for inadequately scaled images in articles, which should be fixed in the articles). Cacycle 20:26, 12 April 2007 (UTC)

text: *Further, the option to show a checkerboard pattern on description pages only could be added in Preferences, under Files, and turned off by default - if a user prefers checkered transparency, they will be able to turn it on. —The preceding unsigned comment was added by Vanderdecken (talk • contribs) 14:17, 2 April 2007 (UTC)
thread_title:  Arguments against 

message: ==== Remove chessboard pattern from default skin ====
==== Keep chessboard pattern in default skin ====
==== Other ====
"It may also be possible to implement a JavaScript which activates the overlay with a click, though this does not currently exist." seems like a very interesting compromise if there is a consensus against using it by default. ed g2s • talk 14:19, 2 April 2007 (UTC)
replies: text: comment we have enough js on this site already. A page load very slowly on my browser compared to other sites. --ChoChoPK (球球PK) (talk | contrib) 14:27, 2 April 2007 (UTC)
replies: text: If you're worried about the time it takes the load the script, the script should be cached by your browser. If your worried about execution time, this script won't do anything until you click the "show transparency" button or whatever it is. ed g2s • talk 15:43, 2 April 2007 (UTC)

text: Wikipedia's loading time is mainly due to slow servers.  A couple hundred KB of CSS and JavaScript that's heavily cached anyway is not the issue. —Simetrical (talk • contribs) 17:03, 2 April 2007 (UTC)

text:  As a (inline) javascript it would take only about 100 characters, that is negligible. Cacycle 17:05, 2 April 2007 (UTC)
thread_title:  Poll options (not open to voting yet) 

message: "It may also be possible to implement a JavaScript which activates the overlay with a click, though this does not currently exist." seems like a very interesting compromise if there is a consensus against using it by default. ed g2s • talk 14:19, 2 April 2007 (UTC)
replies: text: comment we have enough js on this site already. A page load very slowly on my browser compared to other sites. --ChoChoPK (球球PK) (talk | contrib) 14:27, 2 April 2007 (UTC)
replies: text: If you're worried about the time it takes the load the script, the script should be cached by your browser. If your worried about execution time, this script won't do anything until you click the "show transparency" button or whatever it is. ed g2s • talk 15:43, 2 April 2007 (UTC)

text: Wikipedia's loading time is mainly due to slow servers.  A couple hundred KB of CSS and JavaScript that's heavily cached anyway is not the issue. —Simetrical (talk • contribs) 17:03, 2 April 2007 (UTC)

text:  As a (inline) javascript it would take only about 100 characters, that is negligible. Cacycle 17:05, 2 April 2007 (UTC)
thread_title:  Other 

message: I am strongly for keeping the checkered background on image description pages. Transparency is an important feature for editors that want to use the image on pages with non-white backgrounds and for editors who want to improve or update an image. The checkered pattern is the standard method to indicate this in a wide range of image processing programs. However, in order to not confuse anybody and to see the actual appearance in an article, I suggest to add a small legend below the images:
: Transparency indicated by , click here for a white background
The link would use inline-javascript to change the background style or would reload the page with a white background if JavaScript is turned off. Cacycle 17:02, 2 April 2007 (UTC)
thread_title:  Legend 

message: I went ahead and tried to implement the new class by entering the markup "__TOC__" at List of musical instruments by Hornbostel-Sachs number.  But at least for me the TOC is displaying the same as before, with the outline #'s.  Did I screw up?  —Turangalila talk 08:05, 13 April 2007 (UTC)
replies: text: It's most likely that you haven't refreshed your browser cache. Here's the notice about that, pasted from .js pages:
Note: After saving, you have to bypass your browser's cache to see the changes. Firefox/Mozilla/Safari: hold down Shift while clicking Reload (or press Ctrl-Shift-R), Internet Explorer: press Ctrl-F5, Opera/Konqueror: press F5.
Harryboyles 10:10, 13 April 2007 (UTC)
replies: text: Ok, cool.  Mucho thanks to Harryboyles, Simetrical, and Splarka!  —Turangalila talk 16:46, 13 April 2007 (UTC)

text: Done.  It now validates at W3C (except for the 2column part). CMummert · talk 12:12, 15 April 2007 (UTC)
thread_title:  "nonumtoc" - working? 

message: Hello, smart people.  I brought this up at Wikipedia:Village pump (technical) week before last (April 1); it was suggested that I ask  here...
After viewing this page:  List of musical instruments by Hornbostel-Sachs number, I wondered if there was way to make the automatic table of contents render differently. I'm envisioning a TOC that would still compile automatically, but would render the headings with no outline numbers, ie:
:Thing
::Sub-thing
instead of
:1 Thing
::1.1 Sub-thing
This would be useful in the article in question, and possibly others, because the article itself is a demonstration of a numerical typology or classification system, analagous to the Dewey Decimal system or the DSM-IV; thus it makes some sense to include the H-S system's own numerical designations in the headings, but in the default TOC this combines with the automatically generated outline #'s to render as numerical gibberish.  
The consensus seemed to be that this is not possible, however User:Splarka made the following suggestion, which I'm cutting and pasting here since I really don't understand the syntax involved:
You could request at MediaWiki_talk:Common.css an un-numbered class for wrapping your TOC in, such as:
.nonumtoc .tocnumber { display:none; }
.nonumtoc #toc ul,
.nonumtoc .toc ul {
  line-height: 1.5em;
  list-style-type: square;
  margin: .3em 0 0 1.5em;
  padding: 0;
  list-style-image: url(/skins-1.5/monobook/bullet.gif);
}
///(or a variation thereof). Which could be placed with __TOC__. Note that you'd have to be rather convincing to get it ^_^.
It seems to me this would be analagous to the currently available alphanumeric TOC's, and could possibly be useful in more than just the one article.  Is it doable in technical and policy terms?  Thanks much,  —Turangalila (talk) 16:45, 10 April 2007 (UTC)
replies: text: It would be feasible from both perspectives.  Note that that markup would place a square before each list item; list-style: none; would probably be better. —Simetrical (talk • contribs) 03:21, 12 April 2007 (UTC)
replies: text: Ok, your version sounds better...how do I go about making it happen?  Do I just ask again here or somewhere else?  (please bear with me–I'm still kinda new here and I hadn't even heard of .css until this month.)  —Turangalila talk 07:20, 12 April 2007 (UTC)

text: I've added the class to Common.css. However, when it is used, the indenting disappears (as if the headings were all the same level). If someone can come up with a fix for that... Harryboyles 07:25, 13 April 2007 (UTC)
replies: text: Whoops.  Add .nonumtoc #toc ul ul, .nonumtoc .toc ul ul { margin: 0 0 0 2em; }.  I forgot that the other lists would also inherit. —Simetrical (talk • contribs) 19:08, 13 April 2007 (UTC)
replies: text:  All fine now. Harryboyles 19:15, 13 April 2007 (UTC)
replies: text: Could this get documented somewhere, like maybe Help:Section which documents __TOC__? (are there problems with that since it's mirrored from Meta?) jhawkinson 04:18, 17 April 2007 (UTC)
thread_title:  Possible option on TOC's? (to omit outline #'s) 

message: I've added language pseudo-classes for languages using Nastaliq, for CJK disambiguation, and for grc (). In theory, this should yield distinguishably Chinese vs. Japanese vs. Korean rendering for the example table at Han_unification#Check_your_browser if any of the fonts named are installed.
*令免入全具刃化區外情才次海漢画直真空紀草角請道餓骨 (zh)
*令免入全具刃化區外情才次海漢画直真空紀草角請道餓骨 (zh-Hans)
*令免入全具刃化區外情才次海漢画直真空紀草角請道餓骨 (zh-Hant)
*令免入全具刃化區外情才次海漢画直真空紀草角請道餓骨 (ja)
*令免入全具刃化區外情才次海漢画直真空紀草角請道餓骨 (ko)
*نستعلیق (Nafees Nastaleeq font)
*نستعلیق (ur)
*نستعلیق (ar)
*Μῆνιν ἄειδε, θεὰ (grc) / Μῆνιν ἄειδε, θεὰ (el)
*נְקֻדּוֹת (he) /  
The font list and its ordering probably needs to be optimized, I've compiled the font lists based on a cursory glance at http://www.wazu.jp/index.html.
dab (𒁳) 11:04, 17 April 2007 (UTC)
thread_title: pseudo-classes

message: Sometimes, it's desired to remove very-low-level section headings from the TOC. (This could be useful in some project pages with low-level subheadings used for edit-section purposes; there are probably list-like articles that would benefit (e.g. ones which have a long list of sections each corresponding to a different country, and this sort of thing would also allow section headers to be used at RfA without noinclude tricks). The code to do this would be
 .toclimit-2 .toclevel-2 {display:none;}
 .toclimit-3 .toclevel-3 {display:none;}
 .toclimit-4 .toclevel-4 {display:none;}
 .toclimit-5 .toclevel-5 {display:none;}
 .toclimit-6 .toclevel-6 {display:none;}
 .toclimit-7 .toclevel-7 {display:none;}
(I have tested this in my own userspace, and it validates according to W3C); it would allow
 __TOC__
to remove any headings below level 3 (assuming level 1 headings aren't used, which they shouldn't be on most pages), etc. Does anyone object to me making this change? --ais523 14:02, 18 April 2007 (UTC)
replies: text: I've made the change. --ais523 16:13, 18 April 2007 (UTC)

text: Looks like a winner to me. -- nae'blis 20:33, 18 April 2007 (UTC)
thread_title:  Limiting the TOC display level 

message: I originally asked this in 2004, and it was never implemented.  I don't remember why.
We should add something like this: 
 div#bodyContent > pre {
     overflow: auto;
     width: auto;
 }
To the CSS so that code examples and the like don't extend beyond the edge of the layout.  Each long section gets its own scroll bar so you can continue to read the article text while looking at the code.  This is the standard way of doing it in Linux help forums and the like.  Maybe this, too:
 /* p { 
     overflow: auto; 
 } */
See: 
* http://bugzilla.wikipedia.org/show_bug.cgi?id=414
* http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css/Archive_1#pre_autoflow
— Omegatron 14:08, 17 May 2007 (UTC)
thread_title:  Scroll bars for pre tags 

message: moved from MediaWiki talk:Monobook.css, where I placed it by mistake --ais523 16:15, 17 May 2007 (UTC)
replies: text: Personally, I don't have any objections, but I do have a few thoughts. Because it won't be compatible in IE6 (and most likely other browsers), I'm wondering if it would be better just to fix the problem on your end using a Greasemoneky script or something similar (if that's possible). That way, the CSS wouldn't have to be changed for such a small task. Thoughts? --MZMcBride 19:47, 17 May 2007 (UTC)
replies: text: The information would be visible to everyone, so the fix would need to be made for everyone. (I can, and have, fixed it to my own view by using Special:Mypage/monobook.css.) It's not unusable without the fix, or with the fix degrading, but it would improve the view for standard-compliant browsers. (I'm only using the coding on AfD at the moment, but hope to place it on RfA as well eventually. It would probably be an improvement even without the fix, but having two page names side-by-side, each with one word wrapped, looks quite silly.) --ais523 14:03, 18 May 2007 (UTC)
replies: text:  Done. Cheers. --MZMcBride 22:10, 18 May 2007 (UTC)

text: Eh, it doesn't appear to work in IE. I may be wrong. GracenotesT § 13:57, 22 May 2007 (UTC)
replies: text: I know it doesn't work in IE (and probably has no hope of working), so I just made sure it degraded gracefully. It doesn't work in IE, but doesn't bork pages either. --ais523 10:53, 23 May 2007 (UTC)

text: Incidentally, you should use the list-style-image or whatever from the standard UL if you want it to look right for most users (added to MediaWiki:Monobook.css, obviously, not here). —Simetrical (talk • contribs) 02:36, 25 May 2007 (UTC)
thread_title:  Listifying special page transclusions 

message: It seems to make sense to add
.redirect-in-category {
  font-style: italic;
}
Now that redirects in categories are marked with that class. I would personally prefer a more conspicuous style alteration than mere italics, but that's just me (and I can customize it, anyway!). GracenotesT § 19:15, 17 May 2007 (UTC)
replies: text: Finally! —Ruud 19:28, 17 May 2007 (UTC)
replies: text:  By all means, add it :D Surely no one shall protest. GracenotesT § 19:32, 17 May 2007 (UTC)
replies: text:  Done. —Ruud 19:36, 17 May 2007 (UTC)
thread_title: Italicize redirects in category

message: The .infobox.geography .mergedrow does not display correctly in IE when footnotes are included in the text. This is noticeable in Infobox U.S. state. It squishes the text together and the second "p" in population has the bottom cut off on my machine, others are worse (this may be a problem with mergedtoprow). See InfoboxUS states display problems.jpg for an example screenshot. The space between lines has to be slightly increased. Mr.Z-mantalk¢ 21:34, 26 May 2007 (UTC)
replies: text: Anyone want to suggest a way to fix this? I was surprised to find that an infobox has custom CSS here, since it ought to be possible to style the infobox using CSS inside table code.  CMummert · talk 02:50, 28 May 2007 (UTC)
replies: text: There used to be explicit styling in the table code in a variety of templates, like Template:Infobox Country, Template:Infobox Settlement, and others, with the net effect that these very similar infoboxes looked very different.  The infobox.geography styles are intended to unify the look of these infoboxes (see the moribund proposal at Wikipedia:Geographical infoboxes).  -- Rick Block (talk) 18:04, 28 May 2007 (UTC)

text: I'm not really a CSS expert, I will talk to someone who is however, as to how to fix it. Mr.Z-mantalk¢ 05:37, 28 May 2007 (UTC)
replies: text: Well, there are css options such as line-height, that might work, and in a pinch we can just increase the padding, but that's a hack. From the screenshot it looks to me like a vertical alignment problem. But I don't have any access to IE so I couldn't test any changes to see whether they help. CMummert · talk 12:19, 28 May 2007 (UTC)

text: There's a potential fix described at User:Mzajac/monobook.css/Superscript fix.  Increasing the line-height seems to work as well.  It seems elminating the explicit line-height setting might also work, but I haven't tried this yet.  -- Rick Block (talk) 15:35, 28 May 2007 (UTC)
thread_title: IE .infobox.geography .mergedrow problem

message: I wanted to add some non-bold text to a table caption, and was forced to use
  nonbold text
Should there be a class for such things?jhawkinson 21:45, 31 May 2007 (UTC)
replies: text: I don't think it's common enough (from what I've seen) to warrant a separate class. The span tag works just fine. Cheers. --MZMcBride 22:02, 31 May 2007 (UTC)
replies: text: Concur with MZMcBride. — SMcCandlish [talk] [cont]  ‹(-¿-)› 18:04, 2 June 2007 (UTC)
thread_title:  Non-bold text in table captions? 

message: allows to switch easily the skin used to view the same (test) page. 
Please avoid adding it to pages in article namespace ("articles"). -- User:Docu
:It seems like Wikipedia:Village pump (technical) would be a better place to announce this. Mike Dillon 15:39, 3 June 2007 (UTC)
thread_title:  {{tl|Selectskin}} 

message: Small messageboxes would be very handy on a number of Wikipedia-namespace pages, especially cluttered project pages. Please add:
.messagebox.small {
  width: 238px;
  font-size: 85%;
  float: right;
  clear: both;
  margin: 0 0 1em 1em;
  line-height: 1.25em; 
}
I.e., .small instead of .small-talk, and no color override of .messagebox's default near-white.  If .small will conflict with something, .small-non-talk will do. — SMcCandlish [talk] [cont]  ‹(-¿-)› 23:12, 28 May 2007 (UTC)
replies: text: Any objections or problems found with the code? —Centrx→talk • 18:47, 31 May 2007 (UTC)
replies: text:  Done. Cheers. --MZMcBride 02:40, 4 June 2007 (UTC)
thread_title: Why limit small message boxes to talk header coloring?

message: is an example of a sidebox.  What classes should these have? Do we need to create a new class?  It's clear neither a navbox nor infobox.  —Dispenser 22:09, 3 June 2007 (UTC)
replies: text: How is it clearly not an infobox? — SMcCandlish [talk] [cont]  ‹(-¿-)› 02:02, 4 June 2007 (UTC)

text: That's a navigational template of the side boxes and headers variety. It's not an infobox because it doesn't include information specific to each article. It's a navbox because it's used for navigating between articles related to the topic Firefox. As listed in my second link, some of them use the classes infobox, toccolours and/or arbitrary styles. Some of them have the recognizable look of , but it's probably a good idea to have a coherent standard for most if not all of them. –Pomte 02:27, 4 June 2007 (UTC)
replies: text: Could we get some sort of class now for these so we don't have these thing tagged as infoboxes?  It's better to do it now rather than later.  —Dispenser 06:02, 18 June 2007 (UTC)
thread_title:  A class for sideboxes  

message: A few months ago, there was enthusiastic support for highlighting references made using m:Cite.php when they get clicked. Could the same be applied to the ref and note templates? This would be very useful as the symbols (^) aren't always numbered, so it's hard to figure out which note it is at the bottom of the page. I notice that these use definition lists (dl) instead of ordered lists (ol), but setting dd:target works the same way, right? –Pomte 16:29, 3 June 2007 (UTC)
replies: text: As long as the id attribute is on the , it will work the same way in the browsers that support :target. However, I'm not seeing the definition lists you're talking about. What I see in  is a  tag with an id that can be suppressed. Mike Dillon 16:55, 3 June 2007 (UTC)
replies: text: My mistake; I got confused because I listed some  the tags with : instead of * or #. Do it on the  tag then, even if it'll highlight only a short symbol? –Pomte 17:20, 3 June 2007 (UTC)

text: These should be highlighted in a different color so people will know to replace them. — 21:38, 23 June 2007 (UTC)
thread_title:  Highlighting {{tl|ref}} and {{tl|note}} 

message: The following code creates a class that removes the styling from a TOC. Using this makes it possible to choose a different styling (width , background-color, border, etc.). I can imagine that it's not something you'd want to happen in normal articles, but in user talkpages, portals, etc. it can be very useful to be able to do this. Would it be possible to have this added to Common.css? 
/* this class removes border and background-color from the TOC */
.tocnostyle table#toc, .tocnostyle table.toc {
   border: none;
   background-color: transparent;
   padding: 0;
}
Freestyle 18:27, 20 June 2007 (UTC)
replies: text: What about setting background-color to inherit rather than transparent? --ais523 10:17, 22 June 2007 (UTC)
replies: text: Yes, that's also possible. I think the end result will be similar for both options. Freestyle 12:03, 22 June 2007 (UTC)

text: My understanding of the current practice is that we avoid adding things to common.css unless we know they have an important use, to keep bandwidth down. Is there a specific use for this being planned? — Carl (CBM · talk) 19:51, 23 June 2007 (UTC)
thread_title:  TOC withouth styling 

message: This may be obvious to some, but others seem to find it difficult to know what this article is all about.  Perhaps it would be handy to place a comment near the top of these messages spelling out that one should view it's source and past the contents into the MediaWiki:Common.css article/message at your mediawiki site.  I can tell you that I felt a little dumb having spent a few days figuring out something this obvious which a simple comment might have told me.  --D0li0 22:11, 21 June 2007 (UTC)
replies: text: If you want your styling to be identical to Wikipedia's, yes. The main purpose of this page is to provide the styling for Wikipedia; the page's name has special meaning to the software (as do most pages in the MediaWiki namespace). --ais523 10:15, 22 June 2007 (UTC)
thread_title:  How to install 

message: 
This added the colors DarkGray and PapayaWhip.  The only valid CSS colors as of 2.1 are "aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, orange, purple, red, silver, teal, white, and yellow". Please use #FFEFD5 and #A9A9A9 respectively instead of PapayaWhip and DarkGray: this breaks CSS validation. —Simetrical (talk • contribs) 19:43, 15 July 2007 (UTC)
replies: text: Done. DarkGray → #A9A9A9, PapayaWhip → #FFEFD5. Thanks, mattbr 20:03, 15 July 2007 (UTC)
thread_title:  Do not use invalid colors 

message: Just how does one go about 'activating' common.css and common.js on other wikis? I've been wondering this for some time, but have never really been able to find information on it. It would really help if the location of a tutorial or something for doing it was made obvious on here, too. --Dinoguy1000 Talk 18:26, 13 July 2007 (UTC)
replies: text: All Wikimedia Foundation wikis have it enabled.  Third-party wikis can enable it using $wgSiteCss = $wgSiteJs = true; in LocalSettings.php.  This is not normally necessary, however, because they're turned on by default.  The feature only exists in 1.5 or later. —Simetrical (talk • contribs) 02:51, 15 July 2007 (UTC)
replies: text:  Thanks, now I can check if it's enabled on a wiki I help out at. --Dinoguy1000 Talk 16:33, 16 July 2007 (UTC)
thread_title:  Activating on other wikis 

message: Please add "-webkit-column-count:2;" to the rule for .references-2column, so Safari and other applications using the WebKit framework can display the columns. Ms2ger 11:39, 1 August 2007 (UTC)
replies: text: Done. Cheers. --MZMcBride 14:09, 1 August 2007 (UTC)
replies: text: Thanks :) Ms2ger 18:50, 1 August 2007 (UTC)
thread_title:  references-2column 

message: Does anybody oppose setting a default presentation for  elements? These elements are used in several citation templates such as :Template:Citation and :Template:Cite book, and they are all forced to include an inline style="font-style:normal" attribute to prevent the citations from being italicized in most browsers. COGDEN 22:47, 20 July 2007 (UTC)
replies: text: This is the standard display style of  in all browsers.  I agree it kind of sucks, but I don't know if just giving it an arbitrarily different behavior from expected is the best way to go.  Perhaps it is, yes. —Simetrical (talk • contribs) 03:51, 22 July 2007 (UTC)
replies: text: As a practical matter, all uses of  I know of in Wikipedia already change the default representation, but they just do it inline, which isn't the best policy. I can't foresee any possible use of the element in Wikipedia where you would want an italic representation. Alternatively, and more conservatively, I guess we could create a new class for the  element, such as ".citation".COGDEN 21:35, 1 August 2007 (UTC)
replies: text:  I agree with setting it to non-italics everywhere.  I think italics is the exception to the rule.  See  for instance. — Omegatron 21:01, 11 August 2007 (UTC)

text:  Oh wait it's already there. — Omegatron 21:06, 11 August 2007 (UTC)
thread_title:  Standard formatting for <nowiki><cite></nowiki> elements 

message: and  are unknown property declarations that get dropped on every Wikipedia page. Please fix it. --Gamer Eek 03:25, 23 August 2007 (UTC)
replies: text: is a CSS3 property,  and  are two custom non-standart properties for WebKit and Gecko engines. Until CSS3 is widely implemented, using all these properties together is a common way to make multi-column layout work in several browsers at the same time. There is nothing to fix, you simply have to ignore these CSS warnings ∴ Alex Smotrov 04:50, 23 August 2007 (UTC)
thread_title:  Unknown property declarations 

message: Wikipedia:Template standardisation includes proposed additions to Commons.css - please review the discussion on the talk page.  violet/riga (t) 19:16, 1 September 2007 (UTC)
replies: text: I think it would be better to use a meta template, instead of adding a whole page of code to common.css. --David Göthberg 21:58, 1 September 2007 (UTC)
replies: text: The  class adds about as much code here as the template standarisation project would. And we're talking here about a major improvement, affecting possibly all article templates (just like  can be found everywhere, too). I believe a project of this magnitude deserves some space in this file. :-) Миша13 10:28, 2 September 2007 (UTC)

text: A meta-template cannot be customized by end-users as easily.  This is exactly the place to use CSS. —Simetrical (talk • contribs) 15:58, 2 September 2007 (UTC)
replies: text: Agreed, CSS is the right thing to use here. I have no objection to putting the appropriate CSS here; out of the alternatives mentioned, I'd prefer drawing the bar using a large border than with an empty cell, both for browser compatibility reasons, and because the bar is a big border. --ais523 14:34, 3 September 2007 (UTC)
replies: text: Yes, I prefer that too as a simpler solution. I also don't see an issue with the amount of css being added, whichever method is used there won't be too much. We already use css for the current messageboxes and talk page templates. the wub "?!" 22:08, 3 September 2007 (UTC)
replies: text: People here and at the project talk page have managed to convince me that I was wrong. Now I think I agree that those article message box templates need some CSS code. (But we still probably will use a meta template too, but that meta template in turn will use the CSS so it will be fully "skinnable".) Oh, should probably mention we are still working on it so the CSS code is not ready to deploy just yet. --David Göthberg 23:45, 6 September 2007 (UTC)

text: Done. --ais523 16:22, 14 September 2007 (UTC)
thread_title:  Template standardisation 

message: Proposed changes to Monobook.css are being discussed here. Input is sought and welcome. --MZMcBride 02:49, 6 October 2007 (UTC)
thread_title:  Monobook.css changes 

message: Please change:
:lang(grc) {
       font-family: Athena, Gentium, "Palatino Linotype", "Arial Unicode MS", "Lucida Sans Unicode", "Lucida Grande", Code2000;
to
:lang(grc) {
       font-family: "Athena Unicode", Gentium, "Palatino Linotype", "Arial Unicode MS", "Lucida Sans Unicode", "Lucida Grande", Code2000;
The original Athena Roman font is no longer available. The current version of Athena Unicode gives "Athena Unicode" for its font family and not "Athena", and so is not detected.
Apparently Athena Roman can still be found, but there are reports that it doesn't play well with modern software. . TCC (talk) (contribs) 02:23, 17 October 2007 (UTC)
replies: text: .  — Edokter • Talk •  14:57, 17 October 2007 (UTC)
thread_title:  font change 

message: Would people be willing to help to sofixit? discussion on admin's noticeboard --Kim Bruning 02:39, 23 October 2007 (UTC)
replies: text: Actually, I've made a seperate page for this now, Wikipedia:Fundraising redesign.  Dragons flight 05:12, 23 October 2007 (UTC)
replies: text:  And I've already thrown a heap of stuff on there. :-) --Kim Bruning 05:32, 23 October 2007 (UTC)
thread_title:  sofixit 

message: table.navbox tr:not(:first-child) th {
    background-color: #ddf;
}
This rule is here for Template:Navbox generic. Look at the two included examples on Template:Navbox_generic#Layout_of_table: in Firefox the rule works and the backgrounds under {group1} and {title} are different. Not so in IE and Opera (see Comparison of layout engines (CSS)). I really doubt CSS3 should be used in Common.css. Either not() should be removed (making the rule work in Opera and IE7, but not in IE6) or, even better, the whole rule should be removed and  should be modified like  which specifies inline styles for all rows and thus doesn't need any advanced CSS at all ∴ AlexSm 18:26, 17 October 2007 (UTC)
replies: text: I think the background should not be defined inline. Instead, I think defining a sererate #id for the row headers would be more appropriate.  — Edokter • Talk •  18:40, 17 October 2007 (UTC)
replies: text: Actually, since  has been deprecated in favor of  (and thus shouldn't be (but not necessarily isn't being) used for any navigation boxes), this isn't terribly important. I'll put in an editrequest on Navbox generic anyways, though (unless someone beat me to the punch). --Dinoguy1000 Talk 04:58, 18 October 2007 (UTC)

text: I'll remove it; I have updated  with the default colors, so this rule isn't needed anymore.  — Edokter • Talk •  11:57, 18 October 2007 (UTC)

text: What is the point of removing code that only rendered extra information to those using a browser better supporting CSS.  Using style inline is a dirty solution and should be avoided whenever possible as it uses more bytes than if it set in the style sheets.  Additionally it prevents users from accessing those elements using their monobook.css page.  It wanted to support those users you always remove the negate function and swap the two colors around.  —Dispenser 21:57, 5 November 2007 (UTC)
replies: text: Agreed; unless the CSS3 code renders improperly in browsers that don't support it, there's no reason to not have the code. EVula // talk // ☯ // 22:25, 5 November 2007 (UTC)
replies: text: In this particular case the code was only used for deprecated template and only good for Firefox but not for IE and Opera. I think that was a good enough reason to remove it. You're welcome to suggest :first-child (without :not) at  talk page; don't forget to mention that this won't work in IE6. P.S. The statement about user's monobook.css is false: just use !important ∴ AlexSm 00:02, 6 November 2007 (UTC)

text: If the same can be done without CSS3, it should be done that way (using an extra class or id). There's absolutely no reason to use CSS3 if it can be avoided.  — Edokter • Talk •  00:17, 6 November 2007 (UTC)
replies: text:  What about all the navboxen that don't use the template but are just plain tables with the navbox class? —Ruud 00:49, 6 November 2007 (UTC)
replies: text: The CSS3 capable browsers loose their first TH color, for other browsers it stays the same (which didn't show the right color anyway).  — Edokter • Talk •  01:02, 6 November 2007 (UTC)
thread_title:  CS3 ? 

message: Please remove
/* Enables borders on PNG images in IE 5.5 and 6 */
 
.thumbborder {
border:1px solid #DDDDDD;
}
from common.css. Changes to the PngFix workaround in Mediawiki:Common.js made it so that this class is no longer used. —Remember the dot (talk) 05:46, 12 November 2007 (UTC)
replies: text: Done --ais523 15:38, 12 November 2007 (UTC)
thread_title:  Remove unused class 

message: 
.not-patrolled {
    background-color: #ffffaa;
}
—Random832 02:37, 17 November 2007 (UTC)
replies: text: Could you elaborate on why this needs to be included and what the intended effect is?  — Edokter • Talk •  12:33, 17 November 2007 (UTC)
replies: text:  Not done - I don't think this will have any effect: I tested Special:Newpages in all skins, and the only one that did not use yellow was Nostalgia ([ preview]). I'm ignoring myskin because its purpose is to be user-customized. MediaWiki:Nostalgia.css already includes this code, so an addition here probably won't have any effect. Nihiltres{t.l} 16:14, 17 November 2007 (UTC)
replies: text: The CSS files are cached.  My first thought when this effect didn't show up for me (in classic skin) was that it was a monobook-only feature.  Wikipedia:Bypass your cache should probably be mentioned on the page describing it. -- Rick Block (talk) 16:31, 17 November 2007 (UTC)
thread_title:  not yellow on other skins 

message: Keeping Common.css as bloated as possible? What's wrong with inline CSS or using several classes on one element? ∴ AlexSm 15:52, 7 November 2007 (UTC)
replies: text: Where is this class even used? --Dinoguy1000 Talk 17:15, 7 November 2007 (UTC)
replies: text: Apparently, only in .  — Edokter • Talk •  17:21, 7 November 2007 (UTC)
replies: text: Heh, I saw that before I posted. I've really got to learn to search before I speak... ^_^;; --Dinoguy1000 Talk 17:37, 7 November 2007 (UTC)
replies: text: In any case, it probably shouldn't be in Common.css. I asked Physchim62 why he put it in.  — Edokter • Talk •  18:29, 7 November 2007 (UTC)

text: Then perhaps the class should have been simple metadata { display: none; speak: none } from the start? Right now it can be at least merged with persondata class above ∴ AlexSm 21:00, 7 November 2007 (UTC)

text: Why is that? Search engine don't actually look at the class name, do they? All it does is control the display. For .persondata it's too late to change it's name since it is being used to much, but it's not too late to create .metadata for InChI and possible future metadata templates. I'll implement it now, and I would urge to convert InChI to use .metadata instead.  — Edokter • Talk •  21:49, 7 November 2007 (UTC)
replies: text: Let's not use "metadata" for this; we have a bazillion templates with class="boilerplate metadata" floating around.  —Ilmari Karonen (talk) 22:08, 7 November 2007 (UTC)
replies: text: Oops... Any other suggestions?  — Edokter • Talk •  22:15, 7 November 2007 (UTC)

text: Leaving it as it is isn't good enough. This is the most appropriate forum, beside the Village Pump maybe, but this is more of an administrative issue then it is a technical one. We can't have Common.css fill up with seperate, yet identical metaclasses that are only used in one template. So we need to come up with a classname that serves any future metaclasses.  — Edokter • Talk •  13:16, 8 November 2007 (UTC)

text: Actually, I do regard myself as one (of many) guardians if this and other system files, and there is nothing wrong with that; this page is loaded with every pageload, therefor each addition must be discussed beforehand. There is nothing "pretentious" about it. I'm actually more inclided now to just remove the class, as you seem to misunderstand that Common.css is not to be used for adding low-use classes, which are better served in-line. We add them when they become high-use. We just had a major cleanup, and I for one like to prevent another one.  — Edokter • Talk •  13:52, 8 November 2007 (UTC)

text: Sorry? What are the relevant points then? Your rational that "the metadata is different" doesn't hold; you could easily have used persondata and it would have worked fine. Or at least you could have put the name in the same class (as I did) instead of ceating an entirely new, duplicate class. I will repeat though that Common.css must be as small as possible, that is something you cannot dismiss. Now, please come up with a new, generic, metadata class name and use that one instead. Because .InChI isn't going to be around much longer.  — Edokter • Talk •  17:43, 8 November 2007 (UTC)

text: Do we want a seperate class for each type of metadata, or is one class sufficient? In second case, is there, besides the perhaps somewhat non-generic name, any good reason not to use the persondata class for the chemical metadata as well? —Ruud 20:50, 8 November 2007 (UTC)
replies: text:  The "persondata" class may be used by programs parsing the metadata, so it probably shouldn't be reused.  What I'd suggest, for the future, would be to give each type of hidden metadata two classes: one, defined here, which simply marks it as hidden and has no deeper semantic significance, and another designating which kind of metadata it is.  The latter would not necessarily need any CSS rules applied to it; it would simply serve as a semantic marker.  Of course, the system could and should be modified as needed to accommodate the peculiarities of any existing microformats we might wish to implement.  Anyway, as for the name of the generic metadata class, might I suggest simply "hidden"?  Assuming it's not in use already, of course.  —Ilmari Karonen (talk) 21:45, 8 November 2007 (UTC)
replies: text:  That might cause some creative people to abuse it for things it's not intended for. machine-readable might be a better name in that case. —Ruud 22:11, 8 November 2007 (UTC)
replies: text:  Well, at least that's better than .hiddenStructure... --ais523 19:31, 22 November 2007 (UTC)
thread_title:  Unnecessary class 

message: I propose adding:
 .hidden-redlink A.new { display: none; }
to help in redesigning templates to be less server burdensome per the dev's instructions at: Wikipedia:Village_pump_%28technical%29#.23ifexist_limit.  More detail on the justification for this is at that wikilink.  Dragons flight 22:03, 1 December 2007 (UTC)
replies: text: Very evil, but probably acceptable for . Maybe add a safeguard to prevent it from being used on anything but talk pages? —Ruud 01:45, 2 December 2007 (UTC)

text: Hey... actually, weren't ParserFunctions created to eliminate HiddenStructure? <.< GracenotesT § 04:20, 2 December 2007 (UTC)
replies: text:  Given the issues with Wikipedia:HiddenStructure, is this the best solution to the ifexist problem? Gimmetrow 04:42, 2 December 2007 (UTC)
replies: text: Gimmetrow is right; the developers were pretty clear about this last time. As such, editprotected request disabled. --MZMcBride 00:25, 3 December 2007 (UTC)
thread_title:  Add a hidden redlink class 

message: I've started a discussion at navbox to use CSS classes rather than the inline styles.  —Dispenser (talk) 06:48, 9 December 2007 (UTC)
thread_title:  Adding classes for [[template:navbox]] 

message: Why does this skin have this archive? -Cupper52 (talk) 16:18, 7 October 2020 (UTC)
thread_title:  Script