MediaWiki talk:Monobook.css: Difference between revisions
Jitse Niesen (talk | contribs) →Consistent list alignment: plain indents |
|||
Line 988: | Line 988: | ||
:::: How is that a reason not to try it? A fix in monobook.css and chick.css is easily modified or removed, and the feedback from en.wikipedia editors would save the developers lots of debugging cycles. ''—[[User:Mzajac |Michael]] [[User talk:Mzajac |Z.]] <small>2006-02-02 18:39 Z</small>'' |
:::: How is that a reason not to try it? A fix in monobook.css and chick.css is easily modified or removed, and the feedback from en.wikipedia editors would save the developers lots of debugging cycles. ''—[[User:Mzajac |Michael]] [[User talk:Mzajac |Z.]] <small>2006-02-02 18:39 Z</small>'' |
||
::::: Change it in your personal stylesheet, but there is too much potential for "surprise factor" and your method is not one I think works everywhere. Wikipedia will not collapse without this, and it's not even that helpful. -- [[User:Netoholic|Netoholic]] [[User talk:Netoholic|@]] 05:20, 3 February 2006 (UTC) |
|||
While you are at it, I wondered whether you could also look at the indent of inserted by ":" (at the start of a line). I sometimes write things like |
While you are at it, I wondered whether you could also look at the indent of inserted by ":" (at the start of a line). I sometimes write things like |
||
Line 1,012: | Line 1,014: | ||
But that's not ideal either :( Is this also a CSS issue? -- [[User:Jitse Niesen|Jitse Niesen]] ([[User talk:Jitse Niesen|talk]]) 21:34, 2 February 2006 (UTC) |
But that's not ideal either :( Is this also a CSS issue? -- [[User:Jitse Niesen|Jitse Niesen]] ([[User talk:Jitse Niesen|talk]]) 21:34, 2 February 2006 (UTC) |
||
: ":" translates to the HTML tag <nowiki><DD></nowiki>, which, while it ''can'' be used to indent, is ultimately not the ''right way'' to indent. Can you wrap the <nowiki><math> structure in a <DIV></nowiki>? Give me a live example and I'll see if I can help. It's a corner-case, and changing ''all'' instances is unpredictable. -- [[User:Netoholic|Netoholic]] [[User talk:Netoholic|@]] 05:20, 3 February 2006 (UTC) |
Revision as of 05:20, 3 February 2006
Meta | Commons | Wikibooks | Wikiquote | Wikisource | Wiktionary | Wikivoyage | Wikidata | Deutsch | Français | Nederlands
This message on this site, depending on the user-specified interface language:
• en (English): /* Don't display some stuff on the main page */ body.page-Main_Page #deleteconfirm, body.page-Main_Page #t-cite, body.page-Main_Page #lastmod, body.action-view.page-Main_Page #siteSub, body.action-view.page-Main_Page #contentSub { display: none !important; }
- siteNotice {
margin-top: 5px; margin-bottom: -.5em; }
- mw-dismissable-notice {
background: transparent; }
/* BEGIN LIGHT BLUE SECTION
Make content area light blue in all namespaces except articles (main namespace). This is done by setting the background color for all #content areas to light blue, and then overriding it back to white for any #content enclosed in a .ns-0 (main namespace). We do the same for the "tab" backgrounds and some other objects. */
div#content, div#p-cactions li a:hover, div#p-cactions li.selected a, div#content div.thumb { /* "Margin" for thumbs, padding for galleries */ background-color: #F8FCFF; /* Light blue */ } div#p-cactions li a { background-color: #F7F9FB; /* Light blue-gray inactive tabs */ }
.ns-0 div#content, .ns-0 div#p-cactions li a:hover, .ns-0 div#p-cactions li.selected a, .ns-0 div#content div.thumb { background-color: white; /* Set back to white for articles */ } .ns-0 div#p-cactions li a { background-color: #FBFBFB; /* Light gray inactive tabs in articles */ }
@media print { div#content { background: white; } /* White background on print */ }
/* END LIGHT BLUE SECTION */
/* Talk page tab "+" / "new section".
Sets the same padding as the other tabs have. */
div#p-cactions #ca-addsection a { padding-left: .8em; padding-right: .8em; }
/* Make "From Wikipedia, the free encyclopedia" a bit smaller */
- siteSub {
font-size: 92%; }
div#footer #lastmod, div#footer #copyright { display: block; }
p.error { font-weight: bold; }
/* Remove default styles for MediaWiki:Noarticletext. */ div.noarticletext { border: none; background: transparent; padding: 0; }
/* Class styles */
/* .toccolours added here because version in
monobook/main.css wasn't being used by the print style */
.toccolours { border: 1px solid #aaa; background-color: #f9f9f9; padding: 5px; font-size: 95%; }
/* Don't underline links in portlets/specialchars even with pref "Underline links:Always" */ .portlet a,
- editpage-specialchars a {
text-decoration: none; } .portlet a:hover,
- editpage-specialchars a:hover {
text-decoration: underline; }
/* Position coordinates */
- coordinates {
position: absolute; z-index: 1; border: none; background: none; right: 0; top: 3.7em; float: right; margin: 0; padding: 0; padding-right: 30px; line-height: 1.5em; text-align: right; text-indent: 0; font-size: 85%; text-transform: none; white-space: nowrap; } /* Prep for moving coordinates into mw-indicator */
- mw-indicator-attached-kml,
- mw-indicator-coordinates {
font-size: 13px; }
.ve-ce-surface #coordinates { margin-top: -3em; }
/* FR topicon position */ div.flaggedrevs_short { position: absolute; z-index: 10; top: 10px; right: 110px; }
.ve-ce-surface #coordinates { top: 0; padding: 0; }
/* Add bolding to ooui destructive buttons */
- mw-prefs-restoreprefs,
- wpConfirmB,
- mw-editform-cancel,
- oo-ui-flaggedElement-destructive,
.oo-ui-buttonElement-frameless.oo-ui-flaggedElement-destructive, .oo-ui-buttonElement-framed.oo-ui-flaggedElement-destructive, .oo-ui-buttonElement-framed.oo-ui-flaggedElement-destructive > .oo-ui-buttonElement-button, .oo-ui-buttonElement-frameless.oo-ui-flaggedElement-destructive > .oo-ui-buttonElement-button > .oo-ui-labelElement-label { font-weight: 700; }
@media (max-width:550px) { /* Break long words when they cause overflow */ .mw-body { overflow-wrap: break-word; } }
/* Workaroud for T309948 */ .ext-ipinfo-button{
height: 1em;
}
- af (Afrikaans / Afrikaans): /* All CSS here will be loaded for users of the MonoBook skin */
- ar (Arabic / العربية): /* الأنماط المتراصة CSS المعروضة هنا ستؤثر على مستخدمي واجهة مونوبوك */
- bg (Bulgarian / Български): /* Чрез редактиране на този файл можете да промените облика Монобук */
- bn (Bengali / বাংলা): /* All CSS here will be loaded for users of the MonoBook skin */
- da (Danish / Dansk): /** CSS inkluderet her vil være aktivt for brugere af Monobook-temaet . */
- de (German / Deutsch): /* Das folgende CSS wird für Benutzer der Benutzeroberfläche MonoBook geladen */
- eo (Esperanto / Esperanto): /* La jena CSS influos la paĝaspekton por uzantoj de la Libreja temo. */
- es (Spanish / Español): /* El CSS colocado en esta página afectará a los usuarios que usen la apariencia "MonoBook" */
- eu (Basque / Euskara): /* Hemen idatzitako CSS kodeak Monobook itxuran bakarrik izango du eragina */
- fr (French / Français): /* Tout CSS placé ici sera chargé avec les pages accédées par les utilisateurs de l’habillage MonoBook */
- fy (West Frisian / Frysk): /* Al it CSS hjirre sil foar brûkers fan de MonoBoek-foarmjouwing laden wurde */
- it (Italian / Italiano): /* Gli stili CSS inseriti qui vengono caricati dagli utenti che usano il tema Monobook */
- la (Latin / Latina): /* All CSS here will be loaded for users of the MonoBook skin */
- li (Limburgian / Limburgs): /* Alle hier geplaatste CSS-code wordt geladen voor gebruikers van de vormgeving MonoBook */
- nl (Dutch / Nederlands): /* Alle hier geplaatste CSS-code wordt geladen voor gebruikers van de vormgeving MonoBook */
- no (Norwegian / Norsk (bokmål)): /* All CSS here will be loaded for users of the MonoBook skin */
- pl (Polish / Polski): /* Umieszczony tutaj kod CSS zostanie załadowany przez użytkowników korzystających ze skórki Książka */
- pt (Portuguese / Português): /* Todo o código CSS colocado aqui será carregado para os utilizadores do tema Monobook */
- ru (Russian / Русский): /* Весь размещённый здесь код CSS будет применяться к пользовательской теме оформления «Monobook» */
- sv (Swedish / Svenska): /* All CSS här kommer att läsas in för de som använder utseendet MonoBook */
Pages in the MediaWiki namespace regarding this message
For the monobook skin, Wikipedia uses the stylesheet http://en.wikipedia.org/style/monobook/main.css . The page here overwrites parts of that. Individual users can adapt this again for themselves, see m:User styles.
A good deal of common code, not specific to Monobook, was moved to MediaWiki:Common.css.
Archives
- Archive 1 (most of 2004)
In the Talk page of {{prettytable}} it was suggested to take the discussion about moving that template into sitewide CSS here, but somehow nobody did. Therefore I'm repeating my comment from there:
The current code is
border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
It is correct that IE does not support 'border-spacing', but it does support 'border-collapse: collapse', which always implies "border-spacing: 0", which is the same as "cellspacing=0". It also supports 'padding' for 'td' and 'th' correctly, which is what "cellpadding=4" does. Even that contradicting "border=2" and "border: 1px #aaa solid" is handled the same as in Firefox. Therefore I really cannot see any reason not to move this into the stylesheets (there are more skins than Monobook). Even if in IE some spacing was one or two pixels off or the border color a little darker—it did not matter! Server resources are much more valuable than such a minor glitch. So my proposal is:
table.pretty { margin: 1em 1em 1em 0; border-collapse: collapse; background: #f9f9f9; color: #000; /* font-size: 95%;*/ } table.pretty th, table.pretty td { border: 1px #aaa solid; padding: 4px; }
And while we are at it, add something like this, that IE really does not support:
table.pretty th[scope="col"], /* column header */ table.pretty>tbody>tr:first-child>th, table.pretty th[scope="row"], /* row header */ table.pretty>tbody>tr>th:first-child { background-color: #F00; } table.pretty th[scope="row"], /* row header */ table.pretty>tbody>tr>th:first-child { text-align: left; } table.pretty>tbody>tr:hover>td, table.pretty>tbody>tr>td:hover {/* or '*' instead of 'td' */ background-color: #8A5; }
Note that I do not like all the style choices made in this template, especially not the reduced font size. The actual color codes should be skin dependent. Furthermore I doubt that a class is at all required, because we could just make all tables look nice instead (I already did in my stylesheet, but I'm using Standard not Monobook). Christoph Päper 12:16, 23 Jun 2005 (UTC)
- So is there a reason that there have some changes been made to MediaWiki:Monobook.css since I wrote this, but I haven't even gotten a reply (neither positive nor negative)? Shall we go on using that ugly compromise that is Template:Prettytable? Christoph Päper 28 June 2005 15:39 (UTC)
- I have not tested your
.pretty
-code, but I like the initiative. If it works in the major browsers, I cannot see why we shouldn't include it in the stylesheet(s). The Template:Prettytable is temporary and usable, but hard on the servers. -Fred Bradstadt 09:59, July 21, 2005 (UTC)
- I have not tested your
- Er... guys, I didn't know about this... and I just added some tags to MediaWiki:Common.css... which I have applied to Microsoft Jet. - Ta bu shi da yu 10:09, 21 July 2005 (UTC)
- Right, I just noticed that as well :-) I'm im favor of changing the css on Common.css with the css listed above, since it has relative margins and better colors. Though, I like the idea of
<th>
having a background color, for example #efefef. What do you think? - Another argument in User:Crissov's edit above is that we could change the look of tables in general, so they would all look "pretty". Does anyone here know to which extend that would break the style for the entire page? -Fred Bradstadt 10:33, July 21, 2005 (UTC)
- Right, I just noticed that as well :-) I'm im favor of changing the css on Common.css with the css listed above, since it has relative margins and better colors. Though, I like the idea of
- Whatever you do, don't use the word "pretty" in the class name! A class name should describe the function on the element, not the current appearance, which is likely to change. See what the W3C has to say on the matter: http://www.w3.org/QA/Tips/goodclassnames . ed g2s • talk 11:13, 21 July 2005 (UTC)
- I agree, but I cannot come up with a better name than "pretty", maybe because I cannot describe which tables should be "pretty" and which should not. The ones that should not be "pretty" are fx infobox, taxobox and other tables that ought to have their own css class definitions. So maybe the "prettytable" thing should really apply for tables in general? But, as mentioned above, I do not know the exact consequences of changing the css for tables in general... -Fred Bradstadt 11:28, July 21, 2005 (UTC)
- Finally I got attention! Maybe I should have added this to the bottom of the page like I usually do.
- I advocate good class names myself, but ‘pretty’ is a border case IMO. Name it whatever you want, though, as long as people can remember it and associate with the correct meaning, which currently is just prettyfying. This argument would of course be nil, if all tables were changed.
- Note that the second part of my code, that is not intended to work in IE, is not perfect. If Wikipedia really used XHTML—currently it's just tagsoup labeled as XHTML, which is bad—the selectors with ‘tbody’ would not work; solution: duplicate and remove “tbody>” once. The header background color part is of course just an example, often just selecting ‘th’ would be enough (and nobody uses ‘scope’ on WP anyway). Christoph Päper 11:53, 21 July 2005 (UTC)
- What about default table, standard table or skinned table? I'm sure that between us we can do better than "pretty". ed g2s • talk 12:28, 21 July 2005 (UTC)
- “Default” or “standard” should be just ‘table’, not ‘table.foo’. “Skinned” implies that it's different in each Skin, i.e. it wouldn't belong into common.css. Christoph Päper 13:36, 21 July 2005 (UTC)
- What about default table, standard table or skinned table? I'm sure that between us we can do better than "pretty". ed g2s • talk 12:28, 21 July 2005 (UTC)
- Hey guys, I think this is an important initiative - let's not leave it stranded because we cannot agree on a class name! Are there any problems in changing the general table design to the prettytable css? -Fred Bradstadt 11:46, July 24, 2005 (UTC)
- I agree that if the intention is for this to be the default table styling then it shouldn't have classname at all, but should only apply to all tables inside an article (i.e. replace
table.pretty { ... }
with#content table { ... }
). I can't see any other problems with implementing it. ed g2s • talk 12:59, 24 July 2005 (UTC)
- I agree that if the intention is for this to be the default table styling then it shouldn't have classname at all, but should only apply to all tables inside an article (i.e. replace
Please see my suggestions on MediaWiki talk:Common.css#Proposal for CSS for tables. -Fred Bradstadt 16:15, August 20, 2005 (UTC)
"text-align: justify;"
It seems to me that someone is adding and removing "text-align: justify;" in the current stylesheet. It causes the Unicoded texts, especially Tamil to flip in Firefox. See, this bug report. So, please don't "justify" text-align. Thanks. --Rrjanbiah 07:53, 5 Dec 2004 (UTC)
- This is actually a bug in MediaWiki, where it sometimes sends you the CSS for other people's Special:Preferences, instead of your own. If it annoys you do a full reload (ctrl-f5) until it's fixed. Goplat 16:52, 5 Dec 2004 (UTC)
- This should have been fixed some while ago, please confirm. --Brion 07:20, Jan 12, 2005 (UTC)
Updating the cache
I make changes to my monobook.css, but they won't show up (I suppose they will someday). I even load the css in my browser window and shift- alt- command-refresh a dozen times—no luck. Sure is a pain to trouble-shoot CSS changes this way. Is there a trick, or just patience required? —Michael Z. 00:01, 2005 Jan 16 (UTC)
Invalid style sheets
Both /skins/monobook/main.css and monobook.css are currently invalid. I've been experiencing some very annoying styling goofiness in Safari/Mac lately. Can someone please remove the invalid declarations and fix the syntax errors? —Michael Z. 2005-01-21 18:03Z
error in TOCs
Please revert this change ASAP. It is messing up the display of table of contents. -- Netoholic @ 06:19, 2005 Feb 10 (UTC)
Extra space between paragraphs
I don't like this at all. Fredrik | talk 02:55, 13 Feb 2005 (UTC)
- Nor do I —User:Mulad (talk) 02:18, Feb 14, 2005 (UTC)
- It looks especially bad for category boxes. Goplat 02:40, 14 Feb 2005 (UTC)
bullet.gif -> bullet.png
The bullet used by lists is bullet.gif. This should be bullet.png, IMHO. It should link to [1], so that it is in the control of the Editor. Gerritholl 11:47, 14 Feb 2005 (UTC)
- Things like bullets and the Wikipedia logo should not be in control of the editor. :-) - Omegatron 20:13, July 9, 2005 (UTC)
class="plainlinks" fix
Would someone please add this to the file:
#bodyContent .plainlinks a {padding: 0 !important}
Thanks. – ABCD 03:20, 24 Feb 2005 (UTC)
- Another, probably better way would be to add the
!important
code to the http://en.wikipedia.org/style/monobook/main.css file. – ABCD 03:59, 24 Feb 2005 (UTC)
messed up section edit links - CSS or Mozilla issue?
Village pump (technical)#section edit links showing up badly - this may be a problem with the CSS, or it may be a Mozilla/Firefox/etc problem that can still be fixed by changing the CSS. Please have a look. --SPUI (talk) 17:55, 1 Mar 2005 (UTC)
framed image background color
should we change
div.thumb div a img { border:1px solid #cccccc; }
into
div.thumb div a img { border:1px solid #cccccc; background-color:#ffffff; }
(I added this to my user css and it works the way I expected.)
to fix this:
![](http://upload.wikimedia.org/wikipedia/commons/f/f9/Currentmirror.png)
Or maybe we just shouldn't be uploading images with transparent backgrounds? But they look better on pages with colored backgrounds like this:
- Omegatron 16:39, Mar 21, 2005 (UTC)
- Can you make it transparent? My personal CSS makes various namespaces different colours, and the framed areas stand out quite glaringly, although it's actually the area around the frame which is most obvious. --Phil | Talk 17:07, Mar 21, 2005 (UTC)
- I think background-color: transparent; would do it. Now that I think of it, it should be white, though. - Omegatron
- Nope. This doesn't work when I add it to my user css, presumably because it just shows the color of the gray div underneath it. - Omegatron 17:36, Mar 21, 2005 (UTC)
- Also, this is related: Wikipedia_talk:Extended_image_syntax#Multiple_images_in_one_frame - Omegatron 17:27, Mar 21, 2005 (UTC)
- See PNG -- the picture has to be saved with binary transparency to display properly in Internet Explorer and some other browsers. — Catherine\talk 20:34, 21 Mar 2005 (UTC)
- It's not about the transparency itself; it's about the background color of the frame, which only shows in the presence of transparency. - Omegatron 17:45, Mar 22, 2005 (UTC)
I'm going to be bold and add it. - Omegatron 17:49, Mar 28, 2005 (UTC)
- And no one has complained! - Omegatron 20:13, July 9, 2005 (UTC)
small :) request
Per discussion at Wikipedia talk:WikiProject Stub sorting#A simple idea to make stub templates look less ugly/obtrusive, could someone with The Power append the following line?
#stub { font-size: smaller; }
—Korath (Talk) 11:55, Apr 14, 2005 (UTC)
- Is there a wide consensus for this? I don't like it. - Omegatron 17:14, Apr 15, 2005 (UTC)
- My first thoughts on seeing the new reduced stub message: "What is going on, they shrunk the stub templates? For what? It looks uglier." I also think it draws attention to the stub messages, instead of making them more ignorable. --cesarb 19:45, 15 Apr 2005 (UTC)
- Then I suggest making your displeasure known at the discussion linked above; my part was only to direct the change to place where it could be added (or removed) easily, instead of putting <small> tags in the templates themselves (as had already been started). —Korath (Talk) 20:06, Apr 15, 2005 (UTC)
- Somehow the small text is still in place, despite the recent reversion:
- I wish people would spend less time with stub templates and all of their politics and nonsense and more time fixing stubs... - Omegatron 21:12, Apr 15, 2005 (UTC)
- The small text is a caching issue; it should go away if you force a reload of the css link as it appears to your browser. Stub sorting should hopefully be obsolesced by category math, though that unfortunately seems to be a ways off. —Korath (Talk) 21:49, Apr 15, 2005 (UTC)
indents next to images
I imagine this is just a css problem. See Twisted pair. The bullets along the image are not indented as they would be elsewhere. - Omegatron 17:10, Apr 15, 2005 (UTC)
Actually. Don't see it. I'll show you here:
Bullets indented correctly
Twisting wires decreases interference because:
- Bulleted text. The loop area between the wires (which determines the magnetic coupling into the signal) is reduced as much as physically possible.
- Indented text. The directions of current generated by a uniform coupled magnetic field is reversed for every twist, cancelling each other out.
- Double indented text. The directions of curr
- TRIPLE INDENTED TEXT
- Double indented text. The directions of curr
- Triple
- Bulleted
- Text
- Bulleted
Bullets indented wrongly
![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/de/25_pair_color_code_chart.png/100px-25_pair_color_code_chart.png)
Twisting wires decreases interference because:
- Bulleted text. The loop area between the wires (which determines the magnetic coupling into the signal) is reduced as much as physically possible.
- Indented text. The directions of current generated by a uniform coupled magnetic field is reversed for every twist, cancelling each other out.
- Double indented text. The directions of curr
- TRIPLE INDENTED TEXT
- Double indented text. The directions of curr
- Triple
- Bulleted
- Text
- Bulleted
Unfortunately there is no practical way to fix it. The problem is that the margins and padding for the text items are all less than the width of the image. If the text was wrapped in a <div> with a style of margin-left:125px
(125 px because the image is 100px wide + padding), you would see normal (desired) formatting. But because there is normally no way to determine how much text will be affected (it depends on an individual's browser settings), it is just not practical to do that. Instead you will just need to avoid left-floating an image with a list. Float it to the right instead. (I did add it to the article Twisted pair as an example of what it would look like.) —Mike 02:10, July 21, 2005 (UTC)
- I don't see any problems in Safari or Firefox, but the bullets to the right of the image disappear in MSIE/Windows. Maybe they'll fix it in MSIE 7. —Michael Z. 2006-02-1 20:42 Z
New infobox class
Many infoboxes now use class="toccolours". For good semantics there should really be a class="infobox", initially with the same properties as toccolours. Also seeing as most infoboxes (in fact, everyone I've ever seen) floats right, it would be good to include an .infobox.right class (or similar) which defines properties such as float:right; clear:right; left and bottom margins. If we could come to a site-wide agreement this would save a lot of arguments based around "but it's not a table of contents", and we could easily bring some consistency to Wikipedia's ubiquitous infoboxes. ed g2s • talk 15:41, 16 Apr 2005 (UTC)
- Proposed classes:
.infobox { border:1px solid #aaaaaa; background-color:#f9f9f9; padding:5px; font-size: 95%; border-collapse: collapse; } .infobox.right /* this may have to be .infobox.info_right if the class .right already exists */ { float:right; clear:right; margin:0 0 1em 1em; /* 1em to the left and below */ } /* Other possible classes that would be useful, in my experience */ .infobox tr { vertical-align: top; } .infobox_image { border:1px solid #aaaaaa; padding: 0; }
- Stupid question, I know, but why not just make the infobox class itself include the float:right and margins, and have a special form with float:none for those that want it?
- James F. (talk) 20:42, 16 Apr 2005 (UTC)
- We should probably have a class for navigation boxes then too. ed g2s • talk 08:46, 27 Apr 2005 (UTC)
- Default to float:right. In the very rare case that this isn't desirable, it can be overridden with a style attribute in the page.
- Some other suggestions:
- use shortcuts, like #aaa instead of #aaaaaa.
- use keywords for font size.
- 0.5em bottom margin always leaves a line space, but doesn't get too big.
- centre images.
- keep it simple and minimal.
- Some other suggestions:
.infobox { border:1px solid #999; font-size: 95%; border-collapse: collapse; float:right; clear:right; margin:0 0 .5em 1em; } .infobox tr th, .infobox tr td { vertical-align: top; } .infobox image { margin: 0 auto; }
- Adding the styles to the style sheet also gives us the opportunity to redesign the infobox. I've made up a specific proposal at User:Mzajac/sandbox#AFV infobox. —Michael Z. 2005-04-27 15:11 Z
I have 3 comments/requests - see below:
(1) I think we should consider changing from the gray color to white or something else. For exampe #F9F9F9 becomes white on 256 color machines. Additionally, other customizations such as the debate which sparked this at Template:Infobox pope are attractive, not overly fancy and give Wikipedia a nice fit and polished look.
Not all infoboxes are created equally - I think navigation type infoboxes such as the ones that are used for a series of related articles as a kind of quick link table of contents for related articles such as Template:christianity, Template:Worldmusicbox, Template:USmusic, etc are much more effective that Categories for quick navigation amongst closely related articles. (2) These should probably resemble as close as possible the Table of Contents look and feel since they serve a similar purpose.
However some infoboxes are mearly informational with few wikilinks (see Template:Infobox Game for an example) others like the Infobox pope provide mostly information with rarely used links to location of birth, links to significant dates, etc.(3) I see no reason why these should all conform to a standard box style other than a few guidelines, lines no thicker than x, no more than 2 horizontal lines in the middle of the box, etc. The use of templates allows these formatting characteristics to be standard across related articles without the extra burden of making them standard across the entire project. The community itself will force attractive (no Bold RED on light Orange titles) through concensus rather than programming decree Trödel|talk 16:33, 27 Apr 2005 (UTC)
- I think for this skin we should stick to the standard colours - when we had a vote on the image thumbnails (see meta), this style was a run-away winner, and for a good reason. ed g2s • talk 18:57, 27 Apr 2005 (UTC)
- Actually white is a standard color for a box in the monobook class - which is the color you have criticised at Infobox pope. I still don't understand what your objection is to that template. "it doesn't match toccolours" is not enough - there must be some reason that you want to use toccolours - have you modified your monobook.css file so that it displays in very different colors which you need for some reason. If so the suggestion to have more than one style for different kinds infoboxes (that match the theme) is a good compromise. Please help me to understand your concern Trödel|talk 20:19, 27 Apr 2005 (UTC)
Ed's not interested in dialogue, only in convincing everyone that everything must be homogenous and conforming, and that there is no wiggle room for varying the style of the presentation to any degree, regardless on how the style clashes with the coloring of the presented information. There is nothing that mandates the use of toccolours, and by forcing it into the infoboxes he's stifling community involvement. Carry on in creating the infobox you feel you need to make and don't be inhibited by a non-existent style mandate that not everyone finds appealing. - UtherSRG 18:59, Apr 28, 2005 (UTC)
css specification of line-height using "em" is bad
Monobook makes frequent use of line-height specifications using the unit "em". While these lengths _are_ font-size-relative, which is good, the computed value, and not the relative value is inherited by child elements, which is bad.
The problem becomes apparent when a child node uses a different font-size. E.g. many boxes on Wikipedia use font-size:80%. However, because the computed value of line-height is inherited, the line-height stays unchanged (i.e. too large) and the style of the box has to manually fix the line-height.
The solution is to use plain number line-heights, i.e. "1.5" instead of "1.5em". That way, the line-height will properly scale when the font-size is changed.
Here's the relevant section from the CSS2 spec: http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height
Values for this property have the following meanings: [...] <length> The box height is set to this length. Negative values are illegal. <number> The computed value of the property is this number multiplied by the element's font size. Negative values are illegal. However, the number, not the computed value, is inherited.
Crossposted at http://bugzilla.wikimedia.org/show_bug.cgi?id=2013
K. Sperling 00:53, 2005 Apr 29 (UTC)
A request for CSS experts
I have a query at Wikipedia_talk:A_proposal_re_BCE-CE_Debate#Let's implement a preference-based solution today about what is technically possible with CSS. If answered positively, it may help break the deadlock in the interminable BC/BCE debate, so please have a brainstorm about the best solution and comment there! Many thanks. Pcb21| Pete 10:11, 16 May 2005 (UTC)
New class "plainlinksneverexpand"
I have added a new class "plainlinksneverexpand" that behaves like the existing class "plainlinks", but not only suppresses the external link arrow but also URL expansion. Resulted from this discussion at the Village pump. See also Template talk:Ref and Template:Ref, where this is used. Does this need to be ported over to other skins (Cologne, Classic)? Lupo 20:36, 24 May 2005 (UTC)
- Does this also fix the Template_talk:Ref#Printing_problem., where URLs of references were being printed? (Not necessary because the references are further down in the article) (SEWilco 06:41, 26 May 2005 (UTC))
- Yes it does. In fact, that was what prompted me to add this new class. Lupo 07:47, 26 May 2005 (UTC)
Is it possible that recent edits to monobook.css, {{note}} or {{ref}} broke the working of footnotes? This was pointed out by Raul654 at Wikipedia talk:Featured article candidates#Extremely important problem!. I've crossposted this at the two relevant talk pages as I don't know where to search for the problem. — mark ✎ 17:39, 4 Jun 2005 (UTC)Never mind, it's most probably caused by a Mediawiki bugfix as was pointed out by Cesarb at User talk:Raul654. — mark ✎ 17:54, 4 Jun 2005 (UTC)- The date given there is June 2. The {{note}} and {{ref}} behavior has been discussed since June 1. Wikipedia_talk:Footnote3#template:note_now_broken (SEWilco 03:37, 5 Jun 2005 (UTC))
- Can't June 2 equal June 1 depending on the relative timezones? Now if you can find a complaint before June 1, or show the time of the problem is before the time of the fix, things would become more interesting. --cesarb 20:24, 11 Jun 2005 (UTC)
- The date given there is June 2. The {{note}} and {{ref}} behavior has been discussed since June 1. Wikipedia_talk:Footnote3#template:note_now_broken (SEWilco 03:37, 5 Jun 2005 (UTC))
forcing underlined links?
Does anyone know why we override people's browser settings to underline links? I can't find the original discussion on this - although there is some stuff in the archives from people saying they would prefer us not to have this in the style sheet. We have had an email to the foundation pointing out that this can be an accessibility issue for some types of vision problems. Of course, forcing people to view without underline would also cause accessibility problems for some, so surely we should leave this to browser settings. I know we have preferences settings for this, but that's not a good solution for our large number of non-logged in readers. -- sannse (talk) 20:06, 11 Jun 2005 (UTC)
- The preferences setting doesn't actually work for the default monobook skin. Users need to customise their monobook.css page to remove the underlines. The choice might have had something to do with the Link style vote. I'd rather it were left to browser defaults if that's possible, but I don't know if that can be changed using this page. Angela. 21:53, Jun 11, 2005 (UTC)
- I believe (emphasis believe) that removing the very first line of the style sheet would change this. I would, however, be wary of doing this without a vote first. Removing any explicit instruction should make this work. smoddy 22:11, 11 Jun 2005 (UTC)
- How come? I use the Monobook skin, and the preference to remove the underlines does work for me... I don't even have a custom monobook.css. --cesarb 22:58, 11 Jun 2005 (UTC)
- The override (to no underlines) does work for me on Firefox and Mozilla, but not on IE. On Firefox and Mozilla, the preference works to turn underlines back on. So it could be a browser problem... the CSS validates fine however, so it's probably an IE quirks thing. --bainer (talk) 09:23, 12 Jun 2005 (UTC)
The line "forcing" underlining was apparently removed today by ABCD. Unfortunately, that broke underlining entirely for me, on Firefox 1.0.6. (I have "Underline Links" set in my browser preferences, but they no longer appear at all, when using the Monobook skin.) I left ABCD a note on his/her talk page, but unless this was discussed somewhere else, it seems unwise if it breaks things. I would revert it but I do not know how, since it comes from Mediawiki and is not a local page. I don't know enough about CSS to know why removing the line forces no underlining instead of letting it be determined by browser prefs. MCB 23:34, 14 October 2005 (UTC)
Request
Wikipedia:WikiProject Spoken Wikipedia would like to put a link to spoken articles to the right of the page heading. For this we will require the following piece of css added:
h1#spoken { display: block !important; border-bottom-style: none; float: right; font-size: 150%; position: absolute; right: 2%; top: .25em; }
A demonstration of what this will look like is Wikipedia_talk:WikiProject_Spoken_Wikipedia#Link_at_top_of_article.3F here. Ta, Joe D (t) 13:54, 26 Jun 2005 (UTC)
This code urgently needs to be corrected to:
#spoken { display: block !important; border-bottom-style: none; float: right; font-size: 150%; position: absolute; right: 2%; top: 0.6em; }
...in order to deal with a problem in MediaWiki 1.5. — Chameleon 28 June 2005 12:05 (UTC)
- I've changed the distance from the top from 0.25 to 0.6em which works better for me in Opera and IE when using div, I haven't checked in firefox though. Joe D (t) 28 June 2005 12:23 (UTC)
OK, that code got screwed up by the site notice. I think that the following code is definitive and should always work:
#bodyContent .plainlinksneverexpand a { background: none !important; padding: 0 !important } #bodyContent { position: relative; } #spoken { position: absolute; float: right; text-align: right; font-size: 90%; right: 0; z-index: 1; background: none; border-bottom-style: none; top: -2.2em; }
— Chameleon 30 June 2005 12:05 (UTC)
- This bit screws up Z-ordering in Internet Explorer, causing bugzilla:2641 (header lines displaying over floated infoboxes), for example on Owl (comics), see screenshot:
#bodyContent { position: relative; }
- I'd recommend removing it. --Brion July 1, 2005 03:57 (UTC)
- I agree with Brion. This change causes problems with header lines and infoboxes in literally hundreds of pages in IE. —Lowellian (talk) July 1, 2005 08:47 (UTC)
- OK, but that breaks the display of pages with {{Spoken Wikipedia}}. What are you going to do about that? — Chameleon 2 July 2005 09:38 (UTC)
- Yo! Can all you guys just stop messing around with Monobook.css? It was working fine until about four days ago. Now things have been really getting screwy all over WP (like header lines shooting straight through infobox templates), which is why I just visited this talk page to figure out what's going on.
- I'm not sure Spoken Wikipedia is really that important (last time I checked, blind Web users use speech readers) but if we really need links to versions spoken by human beings, I don't understand why we can't just put a link in the toolbox or in the page footer. --Coolcaesar 4 July 2005 17:07 (UTC)
Spoken heading bug
Can anyone tell me why the screenshot above is doing this? It's happened on Wikipedia:No personal attacks, and I am running Windows XP, Mozilla Firefox 1.0.4, using default monobook skin. - Ta bu shi da yu 4 July 2005 02:25 (UTC)
- Same problem for me (slightly different position; it's exactly below "my contributions" and "log out"). Debian GNU/Linux, Mozilla Firefox 1.0.4, default monobook skin. You probably should ask on MediaWiki talk:Monobook.css, which is where a lot of the previous discussion about this problem is. --cesarb 4 July 2005 02:35 (UTC)
- Done. Anyone know of this issue? - Ta bu shi da yu 4 July 2005 02:48 (UTC)
Could it be because the voting notice is shifting the article title and text, but not the spoken article link, down a line? — Dan | Talk 4 July 2005 02:56 (UTC)
- No, the css is designed to work around that. It was working fine two days ago but started breaking for me at a time when neither the CSS code or the spoken template had been edited, so I don't know what has set it off. Joe D (t) 4 July 2005 11:17 (UTC)
Man, somebody must have fucked with something. Because this was perfect a few days ago. BLANKFAZE | (что??) 4 July 2005 13:54 (UTC)
- Update: I found the culprit. The last edit to the MediaWiki page, [2] 08:50, 1 July 2005 / Lowellian / (removing line that causes problems with header lines and infoboxes in IE; see talk)... I reinserted this line into my user CSS and the template box returned to its old position. This line was removed apparently because of a bug above. But I never noticed that bug so I guess I will just keep this line in my CSS. BLANKFAZE | (что??) 4 July 2005 13:57 (UTC)
- If you want to see the bug in action, go take a look at Wikipedia:Wikiportal/Brazil or Batman using Internet Explorer with the CSS line I removed still inserted. —Lowellian (talk) July 6, 2005 22:58 (UTC)
Can somebody just revert this back to the version [3] from the 26th? We can use a temporary fix to get around the sitenotice bug, the current css doesn't work at all. Joe D (t) 5 July 2005 15:39 (UTC)
Invalid CSS ("filter" declarations)
Monobook.css won't validate as CSS2 because of the following declarations. Are these MS-specific extensions, or CSS3 properties? If the former, is there any reason not to move them to the MS-specific style sheet? If the latter, why are we using them? —Michael Z. 2005-07-4 21:40 Z
/* Experiment: slightly fade inactive tabs */ #p-cactions a { filter: alpha(opacity=90); } #p-cactions a:hover, #p-cactions .selected a { filter: none; }
- filter is an Internet Explorer extension. --cesarb 4 July 2005 23:32 (UTC)
- I tracked down the addition. User:Tom- added this experiment in January. Can someone with MSIE/Windows confirm whether this experiment is successful or not? Furthermore, can someone move the code to the appropriate MSIE-specific style sheet(s)?
- After six months, I'd like to remove this code from monobook.css so it can validate as CSS2. —Michael Z. 2005-07-5 20:14 Z
It appears this is a deliberate attempt at bypassing the default style sheet. It is sometimes useful (see List of volcanoes), but these instances are rare. - Ta bu shi da yu 5 July 2005 03:57 (UTC)
Margin for .notice
The class for notices like template:mergeto (.notice) looks like this:
/* Style for "notices" */ .notice { text-align: justify; margin: 1em 0.5em; padding: 0.5em; }
Would anyone object to my making the horizontal margin 1em, so it doesn't look different from notices that use a colon for formatting? (E.g., template:merge, which is currently protected). —Michael Z. 2005-07-5 19:47 Z
- I support this. Changing it to "margin: 1em;" would be better. -- Netoholic @ 5 July 2005 19:57 (UTC)
Common CSS
I noticed it's common for the different skins to get out of sync (things that should be added to all of them are only added to Monobook.css, until someone else takes notice and updates the others). What would you think about creating a MediaWiki:Common.css and adding the following line to the top of all the skin stylesheets:
@import "/w/index.php?title=MediaWiki:Common.css&action=raw&ctype=text/css&smaxage=2678400";
This way, content styles (like for instance .notice) could be updated in a single location, and the skin-specific stylesheets would need to worry only about the user interface. Since it would be added to the top, the CSS cascade could be used to override the common style, if needed.
--cesarb 9 July 2005 19:16 (UTC)
- Since nobody objected, being bold and creating. --cesarb 16:34, 11 July 2005 (UTC)
- I have moved all the CSS which was common for the 4 skins I could find (where's MySkin's CSS?) to MediaWiki:Common.css. Now the CSS for the other three skins is empty except for the import of Common.css. I believe there's more to move there (and in fact I moved one of them, #disambig); the other skins seem to have been neglected for a long time. I have checked it all validates and works on Firefox, but I haven't tested on IE. --cesarb 17:18, 11 July 2005 (UTC)
- Myskin doesn't have CSS. That's the whole point of it. You supply your own. You can user myskin to make custom skins. BLANKFAZE | (что??) 17:51, 21 July 2005 (UTC)
What the heck happened to redlinks?!
The "new" look is stupid. Please change it back. - Ta bu shi da yu 09:29, 13 July 2005 (UTC)
commonPrint.css, and Common.css
The following came up on Template talk:Ref:
Can anyone tell me what's happening here? When I print the URL is expanding.... I thought we didn't want to do this. - Ta bu shi da yu 07:42, 15 July 2005 (UTC)
- On what page? Note that the last time I looked, it was called plainlinksneverexpand... Lupo 08:45, July 15, 2005 (UTC)
- Ok, got it. First, the class of the link has changed from ".urlexpansion" to ".external.autonumber", and second, someone has added the following to our common printing CSS:
- #content a.external.text:after, #content a.external.autonumber:after {
- /* Expand URLs for printing */
- content: " (" attr(href) ") ";
- }
- Someone should disable this for a.external.autonumber if it's within a SPAN of class ".plainlinksneverexpand". It should be done in commonPrint.css, which I don't know how to edit. Lupo 09:04, July 15, 2005 (UTC)
On another note: why does the import of Common.css have a maxage? Lupo 09:04, July 15, 2005 (UTC)
- It has the same maxage as the import of Monobook.css (in fact, I copy-and-pasted the line from the MediaWiki-generated stylesheet). I wanted to avoid any side-effect, so I imported it exactly the same way Monobook.css is imported. --cesarb 21:25, 27 July 2005 (UTC)
- Well I'm glad someone understands what went wrong, my CSS skills are little more than font styling... hopefully this gets fixed soon, it's preventing me from making PDFs... GarrettTalk 02:08, 17 July 2005 (UTC)
- This is evidently something we don't have access to. I have raised a bug asking for us to gain access to commonPrint.css so we can sort out these issues. - Ta bu shi da yu 04:18, 18 July 2005 (UTC)
- I've fixed this in MediaWiki:Common.css. Lupo 08:28, July 19, 2005 (UTC)
- This is evidently something we don't have access to. I have raised a bug asking for us to gain access to commonPrint.css so we can sort out these issues. - Ta bu shi da yu 04:18, 18 July 2005 (UTC)
borders around thumbs
On main.css, there are the following rules:
div.thumb { margin-bottom: 0.5em; border-style: solid; border-color: White; width: auto; } ... div.tright { clear: right; float: right; border-width: 0.5em 0 0.8em 1.4em; } div.tleft { float: left; margin-right:0.5em; border-width: 0.5em 1.4em 0.8em 0; }
Looks to me that borders are being misused, the effect intended is that one of margins. Here, on Monobook.css, you have
#content div.thumb { border-color: #F8FCFF; } ... .ns-0 * #content div.thumb { border-color: white; }
just to change the color of these borders, to match the page background (and this is more annoying because IE doesn't support transparent borders, and so, we can't use border-color: transparent
. Was there a good reason borders where used instead of margins? --Miles 15:33, July 16, 2005 (UTC)
![](http://upload.wikimedia.org/wikipedia/en/thumb/a/a9/Example.jpg/220px-Example.jpg)
- Miles, if you will notice I have added an example image and horizontal rule to illustrate the purpose of using a border instead of a margin. ...
- ... The margin will not prevent the horizontal rule from coming in contact with the image frame, but a border which matches the background does. —Mike 07:07, July 21, 2005 (UTC)
- Thanks. Now it makes perfect sense. --Miles 03:18, July 30, 2005 (UTC)
Redirects on Special:Allpages
I've added a class to all redirects on Special:Allpages called allpagesredirect, please style it somehow (maybe make it grayer). —Ævar Arnfjörð Bjarmason 13:39, 19 July 2005 (UTC)
- The change should be made on MediaWiki:Common.css. I tried out this styling, which I'll probably keep:
- .allpagesredirect { font-style: italic; margin-left: 1em; }
- -- Netoholic @ 14:10, 19 July 2005 (UTC)
Spoken
Can somebody revert the spoken code to:
#spoken { display: block !important; border-bottom-style: none; float: right; position: absolute; right: 2%; top: 0.6em; }
The current code doesn't work. Joe D (t) 13:50, 20 July 2005 (UTC)
Floating images
The div.tleft
class used for images that float to the left is missing a clear: left;
. This sometimes causes an image to be placed next to another float instead of below it. The div.tright
class properly does clear: right;
It should probably go into /skins-1.5/monobook/main.css, but if I'm not mistaken that file is distributed with the mediawiki software and won't change until mediawiki is upgraded to a new version. So putting it into this one would be a good workaround until then. --K. Sperling 20:40, July 28, 2005 (UTC)
Possible CSS problem with floating images
See the edit links on [4]. - Omegatron 19:54, July 29, 2005 (UTC)
- I presume (although the diff links have gone now that the page is no longer current) that you are referring to an edit link gone south. This is a common and probably unfixable fault with floating objects in CSS. [[smoddy]] 22:16, 29 July 2005 (UTC)
your wiki doen't validate
Errors URI : http://en.wikipedia.org/wiki/Main_Page Line: -1 unrecognized media screen,projection URI : http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400 Line: 151 Context : #p-cactions a Parse Error - opacity=90) Warnings URI : http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400 Line : 155 property filter does not exist for this profile, but is validated conforming to another profile
Anoniwiki 10:21, 21 August 2005 (UTC)
- I wonder which profile supported
filter
, which is an MS extension with an invalid or at least unspecified value syntax (CSS functions take comma separated parameters, but no assignments with the equals sign). That experiment, which is inappropriate in a production environment anyhow, should of course useopacity: 0.9
as soon as CSS 3: Color advanced to the next status, or one of the color notations with alpha value (e.g.rgba()
). Note that that Draft has serious yet unresolved issues. Christoph Päper 19:11, 21 August 2005 (UTC)
- I just came here to say the same thing. I don't know how important validating really is, but I think we should either remove the piece of IE-specific code, or make it work in all/most browsers. This, for example, should work in at least Gecko, IE and Safari:
#p-cactions a { opacity: 0.9; filter: alpha(opacity=90); } #p-cactions a:hover, #p-cactions .selected a { opacity: 1; filter: none; }
— Sverdrup 16:36, 22 August 2005 (UTC)
- I've removed the offending CSS (see #Invalid CSS ("filter" declarations) above). I don't know why media="screen,projection" is poo-pood by the validator; it looks right to me. —Michael Z. 2005-09-22 15:32 Z
Portal namespace
Should the background color of the new Portal namespace be the same light blue it currently is, or should it be changed to white (same as the articles and the Main Page)? Now that it's a separate namespace, it would be very easy to change the color, and it would better match the look of the Main Page. --cesarb 18:02, 28 August 2005 (UTC)
Add topical navigation menu(s) to every Wikipedia page
This is a proposal to address the difficulties many users experience when they try to thematically navigate Wikipedia after they leave the Main Page: add one (or add one and expand one) topical navigation menu to Mediawiki:Monobook.css. The elements would be those contained in Template:Categorybrowsebar located on the Main Page. In this template, the first line focuses on the main categories while the second line focuses on browse options. Adding the elements to this style sheet would allow Wikipedia to have a topical, top-level navigation scheme, based on the primary categorization scheme, that would help users move about logically and quickly from any page. Another benefit of this implementation would be that Template:Categorybrowsebar could be removed from a prominent position on the Main Page and several other high-level pages. — RDF talk 17:48, 12 September 2005 (UTC)
p.s. If this is the wrong place to make this proposal, please let me know where I should go. ;-) — RDF talk 19:14, 12 September 2005 (UTC)
One menu version
Here's a one-menu version (Template:Categorybrowsebaroneline) that could span across the top of a page.
Template:Categorybrowsebaroneline
Here's a script version of that template (complements of pile0nadestalk | contribs) developed for such a purpose. It includes my edits to make a one-line version.
<a href="/wiki/Category:Culture" title="Category:Culture">Culture</a> | <a href="/wiki/Category:Geography" title="Category:Geography">Geography</a> | <a href="/wiki/Category:History" title="Category:History">History</a> | <a href="/wiki/Category:Personal_life" title="Category:Personal life">Life</a> | <a href="/wiki/Category:Mathematics" title="Category:Mathematics">Mathematics</a> | <a href="/wiki/Category:Science" title="Category:Science">Science</a> | <a href="/wiki/Category:Human_societies" title="Category:Human societies">Society</a> | <a href="/wiki/Category:Technology" title="Category:Technology">Technology</a> | <a href="/wiki/Wikipedia:Browse" title="Wikipedia:Browse">Categories</a> | <a href="/wiki/Portal:Browse" title="Portal:Browse">Portals</a> | <a href="/wiki/Wikipedia:Browse_by_overview" title="Wikipedia:Browse by overview">Articles</a> | <a href="/wiki/Wikipedia:Quick_index" title="Wikipedia:Quick index">Alpha</a> | <a href="/wiki/Wikipedia:Category_schemes" title="Wikipedia:Category schemes">More</a>
'document.getElementById("content").insertBefore(div, document.getElementsByTagName("h1")[0]);
}
Two menu version
Use this (template:eight portals links) across the top of a page.
Add the browse options to the sidebar navigation box something like this.
navigation
- Main Page
- Community portal
- Curent events
- Recent changes
- Alphabetical index
- Ask a question
- Browse articles
- Browse categories
- Browse portals
- Other indexes
- Random article
- Help
- Contact us
- Donations
Navigationboxes not working anymore
The recent changes of the monobook seem to hide some navigational boxes completely - e.g. Template:Provinces of Thailand. The main difference between that one and those which still show is that the invisible include a id="toc". Yesterday they still showed, however due to the caching of the css I'm not sure which change actually was the "bad" one. Where is the problem - within the css or the template? andy 11:09, 27 September 2005 (UTC)
- That template is visible to me - I'm using IE6.0 at the moment. What's your browser? Worldtraveller 11:21, 27 September 2005 (UTC)
- Firefox 1.0.6 andy 11:22, 27 September 2005 (UTC)
- Strange, now they are back, and nothing was changed in the css. andy 16:08, 27 September 2005 (UTC)
underlined links?
Looking at m:Link style vote the decided policy seems to be underlining links even when the mouse is not over a link, however I see that this behaviour has been reverted by ABCD. The justification he invokes is "allow browser settings to propagate". But, as you can see in monobook/main.css on line 66:
a { text-decoration: none; ... }
This means that browser settings won't propagate, and that links will never be underlined, regardless of what the browser settings are. Note that this only occurs when not logged in (otherwise it depends only on the user's preferences), and that Firefox's Web Developer Toolbar confirms that this is indeed the reason why links are not underlined. Unless monobook/main.css can be modified to fix this, I believe this change should be reverted... Or maybe there was another discussion of this issue? (in which case m:Link style vote should be updated) --Ma Baker 02:08, 8 November 2005 (UTC)
Need diff colors that are compatible with color-blind people
Since a large portion of people are color blind in some sense, we should address this quickly:
(copied from User talk:Jimbo Wales)
- Hi Mr. Wales, or Jimbo, which ever you prefer.
- I'm just inquiring about a recent change in the edit thingy. When you enter into "History" of an article & then click on the "Compare Selected Changes" button, the changes were shown in dark red. But now they are hardly visible, & for an editor with colourblindness, it is quite hard to see what changes people have made to the article. Could you please supply me with an answer if this will be changed or remedied or if it will stay the same.
- I would have posted this on the appropiate page, but I do not know of one, so selected you because you are the "Main Man" on Wikipedia I suppose.
- Regards, Spawn Man 23:15, 7 December 2005 (UTC)
Apropos of this, would it be possible to fix it so that the background-color also changes, to allow alterations in white-space to be seen? HTH HAND —Phil | Talk 08:23, 2 February 2006 (UTC)
Site notice now to the right of page title
I was told that here is the place to say this, so sorry if it isn't. May I suggest the hearder be moved back to the top of the page where it used to be, rather than at the right of the page title. The first time I saw it like that I thought it was a bug; I really do think it looks terrible. If I'm understanding the code in the history correctly it's been changed and reverted, and it's only a test, but my view is don't keep it like this! Why was it moved to the right in the first place anyway? Raven4x4x 08:52, 23 December 2005 (UTC)
Margin around image box
In, Firefox, left-floated image boxes nearly overlap the text above. I suggest that a margin-top is added:
div.thumb {
margin-bottom: 0.5em;
margin-top: 0.5ex;
border-style: solid; border-color: White;
width: auto;
}
--84.194.112.7 17:57, 11 January 2006 (UTC)
Spoken
Can somebody revert the spoken code to:
#spoken { display: block !important; border-bottom-style: none; float: right; position: absolute; right: 2%; top: 0.6em; }
The current code doesn't work. Joe D (t) 13:50, 20 July 2005 (UTC)
- Requesting again, this never got done. Joe D (t) 02:05, 17 January 2006 (UTC)
- Would this code work when there are announcements in the heading, like during the recent fundraiser or with Jimbo's appeal for donations? ~MDD4696 05:15, 17 January 2006 (UTC)
- Usually. The modified code was supposed to make it change depending on the site notice, but merely broke it. A simple temporary fix is easily implemented while the site notice is enabled. Joe D (t) 05:36, 17 January 2006 (UTC)
- Would this code work when there are announcements in the heading, like during the recent fundraiser or with Jimbo's appeal for donations? ~MDD4696 05:15, 17 January 2006 (UTC)
talk page boxes ala the french wiki
/* Style pour les pages de discussion ; gestion de la coloration indentative */ .ns-1 dd, .ns-3 dd, .ns-5 dd, .ns-7 dd, .ns-9 dd, .ns-11 dd, .ns-13 dd,.ns-15 dd, .ns-101 dd, .ns-105 dd { margin: 0; padding: 0; } .ns-1 dl, .ns-3 dl, .ns-5 dl, .ns-7 dl, .ns-9 dl, .ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-105 dl { border-top: solid 1px #F0F080; border-left: solid 1px #F0F080; padding-top: 0.5em; padding-left: 0.5em; margin-left: 1em; } .ns-1 dl, .ns-3 dl, .ns-5 dl, .ns-7 dl, .ns-9 dl, .ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-105 dl { background-color: #FFFFE0; } .ns-1 dl dl, .ns-3 dl dl, .ns-5 dl dl, .ns-7 dl dl, .ns-9 dl dl, .ns-11 dl dl, .ns-13 dl dl, .ns-15 dl dl, .ns-101 dl dl, .ns-105 dl dl { background-color: #FFFFEE; } .ns-1 dl dl dl, .ns-3 dl dl dl, .ns-5 dl dl dl, .ns-7 dl dl dl, .ns-9 dl dl dl, .ns-11 dl dl dl, .ns-13 dl dl dl, .ns-15 dl dl dl, .ns-101 dl dl dl, .ns-105 dl dl dl { background-color: #FFFFE0; } .ns-1 dl dl dl dl, .ns-3 dl dl dl dl, .ns-5 dl dl dl dl, .ns-7 dl dl dl dl, .ns-9 dl dl dl dl, .ns-11 dl dl dl dl, .ns-13 dl dl dl dl, .ns-15 dl dl dl dl, .ns-101 dl dl dl dl, .ns-105 dl dl dl dl { background-color: #FFFFEE; } .ns-1 dl dl dl dl dl, .ns-3 dl dl dl dl dl, .ns-5 dl dl dl dl dl, .ns-7 dl dl dl dl dl, .ns-9 dl dl dl dl dl, .ns-11 dl dl dl dl dl, .ns-13 dl dl dl dl dl, .ns-15 dl dl dl dl dl, .ns-101 dl dl dl dl dl, .ns-105 dl dl dl dl dl { background-color: #FFFFE0; } .ns-1 dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl, .ns-5 dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl, .ns-9 dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl, .ns-13 dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl, .ns-101 dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl { background-color: #FFFFEE; } .ns-1 dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl, .ns-5 dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl, .ns-9 dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl, .ns-13 dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl, .ns-101 dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl { background-color: #FFFFE0; } .ns-1 dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl, .ns-5 dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl, .ns-9 dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl, .ns-13 dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl, .ns-101 dl dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl dl { background-color: #FFFFEE; } .ns-1 dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl, .ns-5 dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl, .ns-9 dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl, .ns-13 dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl, .ns-101 dl dl dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl dl dl { background-color: #FFFFE0; } .ns-1 dl dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl dl, .ns-5 dl dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl dl, .ns-9 dl dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl dl, .ns-13 dl dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl dl, .ns-101 dl dl dl dl dl dl dl dl dl dl, .ns-105 dl dl dl dl dl dl dl dl dl dl { background-color: #FFFFEE; }
With some colorchanges please. →AzaToth 00:49, 31 January 2006 (UTC)
- Oppose strongly. This is something users should put in their own stylesheets. I find it hideous (see for example fr:Discussion MediaWiki:Monobook.css) and the effort necessary for me to override this is daunting. Requests for major changes like this is why they should be discussed on the Village Pump first, not this obscure talk page. -- Netoholic @ 20:57, 1 February 2006 (UTC)
- I agree with Netoholic: no, thank you. —Michael Z. 2006-02-1 21:10 Z
- ObAOL: Me too. I was wondering: is there a simple mechanism whereby we could drop this into a standard place and allow users to include it into their personal CSS file? I know that you can do this with JS, but I'm not conversant enough with CSS to even start :-( If this were possible, we could have a "bank" of standard CSS chunks which people could use. HTH HAND —Phil | Talk 08:16, 2 February 2006 (UTC)
Consistent list alignment
[update: this affects only Monobook and Chick skins—I'm proposing fixing both. —Michael Z. 2006-02-01 23:57 Z]
Ordered and unordered lists have different left margins, which confuses the hierarchy of mixed lists. Ordered lists have a left-margin: 3.2em
applied, to allow three digits to appear without crowding. Unordered lists have left-margin: 1.5 em
, enough so that the left edge of the bullet is slightly inside the left edge of regular text.
The problem with this is that when mixed nested lists occur together, their hierarchy becomes confused, because ordered lists with single-digit numbers appear where a subordinate unordered list would appear:
- Default list format
- Unordered list item—level 1.
- Unordered list item—level 1.
- Unordered list item—level 2.
- Ordered list item—level 1.
- Ordered list item—level 1.
- Ordered list item—level 2.
- Ordered list item—level 1.
A real example is in Romanization of Ukrainian#Table of romanization systems. Look at the notes below the table, the third heading "Notes for the Ukrainian National system": Item nos. 1 and 2 appear to be subordinate to "Transliteration can be rendered in a simplified form", but they are actually not, and shouldn't be confused as part of that bullet point. Please note that this style sheet problem affects the perceived meaning of web pages. [I have a applied a workaround by manually typing HTML —Michael Z. 2006-02-1 22:02 Z] [removed "fix", because it breaks other skins —Michael Z. 2006-02-01 23:51 Z]
I propose adding a 3-em left margin to unordered lists: then their starting text would align correctly:
- Added 3-em left margin to ordered lists only
- Unordered list item—level 1.
- Unordered list item—level 1.
- Unordered list item—level 2.
- Ordered list item—level 1.
- Ordered list item—level 1.
- Ordered list item—level 2.
- Ordered list item—level 1.
- Ordered list item—level 1.
- Ordered list item—level 1.
This appears to display correctly in MSIE/Windows, Firefox, and Safari, using monobook.css. Any objections? —Michael Z. 2006-02-1 21:04 Z
- I'm worrying that by doing this change that we'll break articles that were made with these margins in mind... just the reverse case of your example. I know that the bullets are often used in tight spaces, like in Deus Ex's infobox. -- Netoholic @ 21:19, 1 February 2006 (UTC)
- Good point. Looking at that example, I notice that raw
<li>
tags were typed by an editor, and that<ul class="noindent">
was added surrounding them (by Tidy?). But I can't find.noindent
in any of the style sheets. We could addul.noindent { margin-left: 1.5em; }
to prevent messing with cases like these, but I can see this still being a problem in other cases. Perhaps all lists in tables should not have this rule applied:
- Good point. Looking at that example, I notice that raw
/* consistent margin with numbered lists */ ul { margin-left: 3.2em; } /* restore default value for raw list items and lists in tables */ ul.noindent, table ul { margin-left: 1.5em; }
- Quite. I'd suggest using your workaround to fix that one article, as I don't see a big justification for changing every bullet list everywhere. I was also thinking that bullets are used in discussions and votes quite often, and changing the indent could confuse the context (who someone was replying to). -- Netoholic @ 21:50, 1 February 2006 (UTC)
- Good point about discussions too, but although old discussion may be twiddled a bit, this fix would make it easier to create correctly nested lists in discussions, without repeatedly previewing.
It turns out that this problem is the result of a bug in the Monobook and Chick skins. All other skins align the lists correctly by default. This means that any "fixes" applied in the wikitext will break rendering in other skins. Since these two skins are "broken" in relation to all other skins as well as to browsers' default rendering, I'm re-proposing applying the fix to those two skins, so that lists will be rendered consistently (and correctly) across all the skins. —Michael Z. 2006-02-01 23:51 Z
- For the monobook skin, that change was applied by "gabrielwicke" over the course of a couple changes in April 2004. He added margin to the ol. I don't support adding more margin to ul's to compensate, due to the examples I showed you. Let's not get complicated. Contact him to see if he remembers any specific reason for the change. I'd rather see any non-project-specific alterations be made to the skins source code, not here. -- Netoholic @ 00:54, 2 February 2006 (UTC)
- That may be moot, as Gabriel hasn't edited English WP for three months. I've filed bug 4829 at Bugzilla.
- Still, it would be good to fix this. Another possibility is to reduce ol's margin-left to 1.5em, or even both of them to 1.0em, but change list-style-position to inside: this would mean that two- and three-digit numbers would have the decimal point aligned differently, but nested lists would work right, and both types of lists would sit closer to the left margin for the sake of lists in tables. —Michael Z. 2006-02-02 01:37 Z
- Surely this sort of thing should be in mediawiki:common.css so that all skins use it? Why not simply shift it in there? HTH HAND —Phil | Talk 08:20, 2 February 2006 (UTC)
- Still, it would be good to fix this. Another possibility is to reduce ol's margin-left to 1.5em, or even both of them to 1.0em, but change list-style-position to inside: this would mean that two- and three-digit numbers would have the decimal point aligned differently, but nested lists would work right, and both types of lists would sit closer to the left margin for the sake of lists in tables. —Michael Z. 2006-02-02 01:37 Z
- The problem is a difference in rendering the two different types of lists, in only the two skins Monobook and Chick. Code in Common.css modifies all skins, so that wouldn't be an appropriate place for it. We can apply an overriding declaration to Wikipedia's user-editable Monobook.css and Chick.css, but it would be better still to fix the code in the main Monobook and Chick style sheets which are part of the MediaWiki software.
- Sorry, must not be expressing myself clearly (as usual
). What I mean is that obviously if Monobook and Chick (where is that defined/documented BTW?) are doing something different, they are overriding something which all the other skins have in common. This common code should presumably be in common.css and we should simply remove the override which has been added to monobook.css and chick.css. Where is this common behaviour actually defined? HTH HAND —Phil | Talk 13:51, 2 February 2006 (UTC)
- I think there is no main "commmon" style sheet: CSS declarations in each skin override your browser's default rendering. (Common.css is merely a set of editor-accessible add-on styles that apply to all skins.) I've only looked at a couple of the other skins, but it looks like they are all relying on the browsers' default rendering of ordered and unordered lists, and not applying their own different format.
- So what you're suggesting would require removing declarations from the main software-included main Monobook style sheet to let the browser do its thing (not the editor-accessible add-on Monobook.css). To see what that would look like, I tried overriding Monobook's formatting by adding
margin-left:inherit
to a list on the page. That makes the list bullets and numbers overlap the left border in an ugly fashion (this test won't work in MSIE because it doesn't support the CSS 'inherit' value). So I think the Monobook declarations for lists will have to be changed, not removed—but this is no more difficult, and if the values match then the results will, too.
- So what you're suggesting would require removing declarations from the main software-included main Monobook style sheet to let the browser do its thing (not the editor-accessible add-on Monobook.css). To see what that would look like, I tried overriding Monobook's formatting by adding
- As I mentioned, an early version of Monobook applied margin-left:1.5em to both ordered and unordered lists, but the ordered list was later changed to prevent two-digit and three-digit list numbers from overlapping the left border, while unordered lists were not changed to be consistent. The Monobook CSS declarations for lists appear to have been copied into the Chick skin. This is now a rare but not insignificant problem in the way hierarchical lists convey information in those two skins. —Michael Z. 2006-02-02 16:18 Z
Regarding Netoholic's concern about lists in tight spaces, that is, lists in tables: ordered lists in tables currently have a too-big margin, anyway. We could make lists in tables consistent and more space-efficient than they are now by applying the following override. This is not complicated, and the results are predictable in different browsers. —Michael Z. 2006-02-02 16:41 Z
th ol, th ul, td ol, td ul { list-style-position: inside; margin-left: 0; padding-left: .5em; }
- We're not talking a change to some structure unique to Wikipedia, so this change should be proposed to the developers -- not changed here on the project-specific CSS. -- Netoholic @ 16:53, 2 February 2006 (UTC)
- With respects, there is no urgency. You have one example of where things dont work ideally, while the current arrangement has been in place for a long time. -- Netoholic @ 17:36, 2 February 2006 (UTC)
- Change it in your personal stylesheet, but there is too much potential for "surprise factor" and your method is not one I think works everywhere. Wikipedia will not collapse without this, and it's not even that helpful. -- Netoholic @ 05:20, 3 February 2006 (UTC)
While you are at it, I wondered whether you could also look at the indent of inserted by ":" (at the start of a line). I sometimes write things like
- Point one.
- Point two. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
- Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
- Point three.
I'd like the bit after the formula to line up with the bit before the formula. This can be achieved by using HTML tags:
- Point one.
- Point two. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
- Point three.
But that's not ideal either :( Is this also a CSS issue? -- Jitse Niesen (talk) 21:34, 2 February 2006 (UTC)
- ":" translates to the HTML tag <DD>, which, while it can be used to indent, is ultimately not the right way to indent. Can you wrap the <math> structure in a <DIV>? Give me a live example and I'll see if I can help. It's a corner-case, and changing all instances is unpredictable. -- Netoholic @ 05:20, 3 February 2006 (UTC)