MediaWiki talk:Common.css
Meta | Wikibooks | Wikiquote | Wikisource | Wiktionary | Deutsch | Français | Nederlands
 | This is the common CSS for all the skins. Use it only for styling things within the content area (stub notices, message boxes, spoiler/disambiguation messages, etc).
The following stylesheets call this one:
|
Make poem tag indented
{{editprotected}}
I would appreciate the following addition to this page:
div.poem {
margin-left:2em;
}
This would make all <poem>s indented,
like this.
This way,
:Line 1 :Line 2 :Line 3
can be replaced with
<poem> Line 1 Line 2 Line 3 </poem>
with no differences. Perhaps white-space: pre; should also be added, since poems often manipulate whitespace. (Any other suggestions or corrections would be good.) GracenotesT § 19:19, 15 May 2007 (UTC)
- I'm not convinced this is a good idea; it's possible that some poems are indented at the moment through near-necessity, not for stylistic reasons. Wouldn't
<div style="margin-left:2em;"> <poem> Line 1 Line 2 Line 3 </poem> </div>
- make a better replacement, not involving any changes to common.css? That way, the poem could be styled as required in the actual article (such as preing the whitespace). --ais523 12:41, 16 May 2007 (UTC)
- The only thing is, if the poem extension is going to be more widespread than it already is, it’s best to make sure that entia non sunt multiplicanda praeter necessitatem. Maybe the class should be called div.poemindent? GracenotesT § 17:17, 16 May 2007 (UTC)
Shouldn't it be inside a blockquote? — Omegatron 13:26, 16 May 2007 (UTC)
- I've disabled the editprotected request while discussion continues. Please re-enable it once there's consensus. Cheers. --MZMcBride 20:24, 16 May 2007 (UTC)
Blockquotes may work, but there's still the white space issue. Taking cascading into account, its notable elements of style are "line-height: inherit; margin:0.4em 0pt 0.5em; font-size:93.75%;". If a class (called, for example, blockpoem) had the style "margin-left: 2em; font-size:93.75%; white-space: pre;" the following would work:
<poem class="blockpoem"> Line 1 Line 2 </poem>
This is quite simple and easy-to-use, and mass-alterable (the whole point of style sheets). GracenotesT § 01:18, 17 May 2007 (UTC)
- I meant that blockquote should be used regardless of formatting since a poem is, semantically, a blockquote. Right? — Omegatron 14:09, 17 May 2007 (UTC)
- The ideal way to fix that would be to alter the poem extension, an easy task in theory. But then there's the whitespace, and simplicity. GracenotesT § 14:29, 17 May 2007 (UTC)
scroll bars for pre tags
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:
Listifying special page transclusions
moved from MediaWiki talk:Monobook.css, where I placed it by mistake --ais523 16:15, 17 May 2007 (UTC) {{editprotected}}
I was trying to use a transclusion of a special page:
This comes out as a table, which can be ugly or not fit in in the relevant context. I would like to add the following to this page:
.listify td {display:list-item}
.listify tr {display:block}
.listify table {display:block}
This would mean that
<ul class="listify">
{{Special:Prefixindex/Transclude}}
</ul>
would come out as a list instead in CSS-compliant browsers like Firefox. (It has no effect at all in IE 6, so it degrades gracefully.) Would anyone object to this being added to the site-wide CSS (it's a bit of a niche thing; I'm using the transclusion to put lists of past AfDs on renominated AfDs, to make them easier to track, but it can be a bit ugly (see User:ais523/Sandbox), and the same could be done for RfAs)? Putting {{editprotected}} up because this needs a second opinion, even though I'm an admin. --ais523 15:04, 17 May 2007 (UTC)
- 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)
- 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)
Done. Cheers. --MZMcBride 22:10, 18 May 2007 (UTC)- Eh, it doesn't appear to work in IE. I may be wrong. GracenotesT § 13:57, 22 May 2007 (UTC)
- 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)
Example:
Of course, probably the software should arrange them like that to start with. —Simetrical (talk • contribs) 02:35, 25 May 2007 (UTC)
- 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)
Italicize redirects in category
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)
- Finally! —Ruud 19:28, 17 May 2007 (UTC)
- By all means, add it :D Surely no one shall protest. GracenotesT § 19:32, 17 May 2007 (UTC)
- Done. —Ruud 19:36, 17 May 2007 (UTC)
- By all means, add it :D Surely no one shall protest. GracenotesT § 19:32, 17 May 2007 (UTC)
Well, it looks like some people have protested: Wikipedia:Village Pump (technical)#Redirects in categories. It seems to be partially about the style and partially about redirects even being in categories. Mike Dillon 03:54, 25 May 2007 (UTC)
white backgrounds
Can these be removed, please--at least for the "simple" stylesheet? I try to remove white backgrounds wherever possible, which is why I use the "simple" stylesheet in MediaWiki prefs (so the web browser-specified page background is used instead), but most MediaWiki tables tend to have annoying white backgrounds which are overbearing, glaring, and even painful to look at (considering most of my backgrounds are neutral grey). --Єερ² (τ|c) 12:48, 20 May 2007 (UTC)
We'd have to do
table {
background-color: transparent;
}
(inherit would possible work; I'm not sure.)
this would override the first of following from main.css:
table {
background-color:white;
color:black;
font-size:100%;
}
I've really wanted this for some time, and think it would be great if it were implemented :) Pretty sure it's been suggested before, if not here. GracenotesT § 18:14, 20 May 2007 (UTC)
- Is this possible via a user-customizable stylesheet as a subpage of the userpage? ∞ΣɛÞ² (τ|c) 18:53, 20 May 2007 (UTC)
- Well, yes, but this is a mass inconvenience :) or at least a mass irritation. You would add the former code to this page (from what you've told me) to see transparent tables. GracenotesT § 19:09, 20 May 2007 (UTC)
- Doesn't work. :( I may have to put the whole CSS file there and then just remove all the white backgrounds. ∞ΣɛÞ² (τ|c) 21:00, 20 May 2007 (UTC)
- You put in the wrong one :( try replacing what you have with:
table {
background-color: inherit;
}
- Inherit, I've concluded, is more cascading-ish. GracenotesT § 21:18, 20 May 2007 (UTC)
- I put in the one you said--the first one (well, you were vague--you just said "the former one", which isn't even the one you just mentioned now). Anyway, it still doesn't work. "Inherit" retains the same background; it doesn't do anything. Just to be sure you understand what I mean, I want the white backgrounds on tables (such as on WP:PARA to not be white but be the same default background color as my web browser (which is Firefox set to "use system colors", of which, in WinXP, is set so that the "window" item's "color 1" in Control Panel > Appearance > Advanced is set to RGB 128,130,140 (hex/HTML #80828c, a neutral blue-grey). Dig? ∞ΣɛÞ² (τ|c) 22:47, 20 May 2007 (UTC)
- I was previously somewhat confused about what you were asking, and now I'm stupefied. I thought you were talking about tables, since that issue has been brought up before, but I guess not... if you want a background color in tables of #80828c, your background-color should be set to #80828c in your user CSS style sheet. I still feel as though I'm out of the loop, so do you want a CSS change for everyone, or only for yourself? Are there any particular elements you want to alter? GracenotesT § 22:55, 20 May 2007 (UTC)
- I put in the one you said--the first one (well, you were vague--you just said "the former one", which isn't even the one you just mentioned now). Anyway, it still doesn't work. "Inherit" retains the same background; it doesn't do anything. Just to be sure you understand what I mean, I want the white backgrounds on tables (such as on WP:PARA to not be white but be the same default background color as my web browser (which is Firefox set to "use system colors", of which, in WinXP, is set so that the "window" item's "color 1" in Control Panel > Appearance > Advanced is set to RGB 128,130,140 (hex/HTML #80828c, a neutral blue-grey). Dig? ∞ΣɛÞ² (τ|c) 22:47, 20 May 2007 (UTC)
- I am talking about tables. Anyway, I figured it out; I had to specify the correct table elements (see User:Eep²/simple.css). I still think it should be that way for everyone with the "simple" skin but this'll work for me at least. Thanks for your help. ∞ΣɛÞ² (τ|c) 23:10, 20 May 2007 (UTC)
- Ah, glad you got it to work. GracenotesT § 23:15, 20 May 2007 (UTC)
- I am talking about tables. Anyway, I figured it out; I had to specify the correct table elements (see User:Eep²/simple.css). I still think it should be that way for everyone with the "simple" skin but this'll work for me at least. Thanks for your help. ∞ΣɛÞ² (τ|c) 23:10, 20 May 2007 (UTC)
style for IEC/traditional notation
In order to offer a template that would allow user-defined preference regardgin the style of display of IEC/traditional notation Could the following be included ?
span.kib:after { content:" KB (KiB)"; display:inline; }
span.mib:after { content:" MB (MiB)"; display:inline; }
span.gib:after { content:" GB (GiB)"; display:inline; }
span.tib:after { content:" TB (TiB)"; display:inline; }
The rational is detailed at Wikipedia talk:Manual of Style (dates and numbers)#Template with CSS proposition This will allow the use of Template:KiB for instance, that in turn would be a way to avoid editor's argument regarding which style to use. the default style is compliant with the current WP:MOSNUM, but most importantly, one can easily chose a 'pure' IEC style or a 'pure' traditional style without having to mass edit. Another benefit is that, if and when IEC notation become in widespread use, we can change the default style in this central ___location. - Shmget 17:12, 25 May 2007 (UTC)
- This will cause the articles to have lost information if they are read without our CSS (e.g. on a mirror). I don't think this will work. An alternative would be to use a span with a CSS class around the abbreviation itself and let users use their personal JavaScript to switch out the text for themselves. This wouldn't require any site-wide styling or scripting, but it would also not avoid style arguments. Mike Dillon 18:14, 25 May 2007 (UTC)
- I see. Yep that is a problem. Can you point me to an example of the solution you suggest (I'm not asking you to code it for me, just a place where similar technique are used so I can study and adapt them). I do beleive that if there is a user-level custom solution that would render void most of the dispute. Shmget 18:42, 25 May 2007 (UTC)
- I not sure I understand the argument that a change shouldn't be made because it will cause mirrors not to work. Every style used in Common.css (obviously) won't apply to other sites that don't load the CSS, including things like "wikitable". Additionally, I'm not sure it's a good idea to base decisions on whether or not another site may copy this one. These comments aren't intended to attack or be rude, I'm just not sure I understand the logic in stopping a proposed change to appease other sites. Any thoughts? Cheers. --MZMcBride 19:16, 25 May 2007 (UTC)
- It's not just mirrors. There are plenty of tools (even some browsers, esp. text-based ones) that interpret HTML and do not honor CSS. For the most part, the users of those tools can expect that they will have different formatting, but that the text itself will read correctly. If CSS is used to add text, with the "content:" attribute, those assumptions no longer hold true, and the users of those tools will have problems. The conclusion, therefore, is that solutions that use "content:" are probably not a god idea to deploy. jhawkinson 20:21, 25 May 2007 (UTC)
- As jhawkinson, not all CSS poses this sort of problem. Only CSS that does things like hide or add content in ways that the display will be actually broken if they don't happen. If something doesn't use "content" or is missing the rule, you end up with an unqualified number instead of a value with units. Mike Dillon 21:29, 25 May 2007 (UTC)
- Well, the approach I'm suggesting would do the following:
- Make a template like {{KiB}}, but have the content be:
{{{1}}} <span class="kib">{{{2|KB (KiB)}}}</span>
- Call it like so:
{{KiB|1234}}or{{KiB|1234|KB}}, which would display as "1234 KB (KiB)"" or "1234 KB" respectively - In the JavaScript, use
getElementsByClassName(document, "span", "kib")to find the spans containing the units - Use JavaScript to replace the inner text of the span with whatever the user wants to see
- Make a template like {{KiB}}, but have the content be:
- Let me know if you have any questions. I don't mind writing up the code if people want to use this approach. Mike Dillon 21:37, 25 May 2007 (UTC)
- You solution achieve what I have in mind : a centralize way so that the notation could reflect the style consensus, including change in that consensus if that occurs, and still the freedom to individual reader, editor, not to be force to abide with that consensus without creating endless warring.
- I have changed the Template according to your suggestion. I will try my luck with javascript (I tend to be allergic to java, but I'll try to get over it :-) ), you are most welcome to beat me to if if you are so inclined. I don't know if this method will be accepted and therefore used by 'people', but it would be easier to make a case with a working prototype... - Shmget 22:43, 25 May 2007 (UTC)
- Actually, User:Mike Dillon, your solution is even better that what I had in mind, since it would also allow to stick to the consensus of the existing page - as per current WP:MOSNUM - by specifying explicitely a parameter 2, while still clarifying that KB are 'binary' in the 'source' (the page would show {{MiB|16|MB}} - which make it clear that the editor know that they are binary) and allow any user to switch to pure IEC if they feel so inclined (and recriprocally allowing any user to switch to full traditional if he is allergic the IEC notation) and finally for editor that don't care, they can delegate the presentation to the WP:MOSNUM whose recommanded notation of the time would be reflected in the template's default. I really don't see any downside to this - Shmget 23:04, 25 May 2007 (UTC)
- Well, the approach I'm suggesting would do the following:
- I'd actually say that the template should conform the consensus if the second parameter is not passed. It isn't actually clear to me what the consensus is, but the templates should be set up in such a way that following consensus is the default option. Mike Dillon 01:16, 26 May 2007 (UTC)
- I agree. I tried to write the template based on what I understand being the 'current consensus', even though that is being debated... I would gladly change the template to reflect what-ever consensus emerge. The point of the template being to allow qualified exception (by over-riding the default an editor make a conscious choice, that should probably not be reverted too lightly) and by allowing user with very strong opinion on the matter to have it their way without engaging in edit-war. Shmget 02:00, 28 May 2007 (UTC)
- I'd actually say that the template should conform the consensus if the second parameter is not passed. It isn't actually clear to me what the consensus is, but the templates should be set up in such a way that following consensus is the default option. Mike Dillon 01:16, 26 May 2007 (UTC)
Here's an implementation: User:Mike Dillon/Scripts/byteQuantities.js. It is used like so in monobook.js:
var byteSuffixes = {
"kib": "KiB",
"mib": "MiB",
"gib": "GiB",
"tib": "TiB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');
I think it will actually work in other skins too. Let me know if you need it to work differently. Mike Dillon 01:12, 26 May 2007 (UTC)
- Thanks a lot. I haven't tried it with other skins yet, but I don't wee why it would make any difference (unless they actually already use 'kib/mib/gib/tib' as class of span.
- I agree that the template should agree with the consensus if the second parameter is not passed, which I believe they do. But WP:MOSNUM also say right now, that on established page, one should stick with the consensus of THAT page and not change style for the sake of changing style. Using the second parameter will allow page about legacy hardware, for instance - to keep their default consensual style, while making clear - in the source of the page - that the use of KB is no accident and that it is known to have it's usual binary meaning and also allow any given user to see it with it's favorite notation, without having to edit the page, using the script you wrote.
- Thanks Again for the help - Shmget 02:18, 26 May 2007 (UTC)
- The only difference in behavior between skins would be the part used to find the relevant spans to change. In Monobook, it finds all spans inside the "bodyContent" node; in other skins, it finds all spans inside the whole document. I think the code should work correctly in both cases, unless one of the skins is using "kib", "mib", "gib", or "tib" as a class in the non-article portion of the page. Mike Dillon 14:43, 27 May 2007 (UTC)
- this is this part right?
var body = document.getElementById("bodyContent") || document;I was wondering, is there an iterator for the 'components/modes' of a document ? a way to get the root node and then traverse the tree from there ? -- Shmget 22:15, 27 May 2007 (UTC)- I'm not sure what you're asking exactly, but
documentis the root DOM node. The reason that code first tries to find the element with the "bodyContent" id is that that's the top-level element of user-controllable content in the default Monobook skin. In Monobook, it is pretty much guaranteed that "bodyContent" will only have HTML derived from the article text, so we can be assured that even if the interface itself used those classes, they would be ignored. In the case of other skins, we simply traverse all children of the root node, so we could end up seeing an element with "kib", "mib", "gib", or "tib" if the skin used them outside of the article content. I'm pretty sure that no skins actually use those classes, so it's pretty much a moot point. Mike Dillon 01:42, 28 May 2007 (UTC)- Thanks for the precisions. I guess my question boil down to: How do you iterate the whole collection of sub-node without going to GetByxxxx(). Let's say, for the sake of the discussion that I want to create a function that count the number of instance of each class used in a document... -- Shmget 02:00, 28 May 2007 (UTC)
- The
getElementsByClassName()function is provided by the Mediawiki software in the wikibits.js file. It relies on thegetElementsByTagName()DOM function and filters the return value to be a JavaScript Array with only the nodes that have the right class name. If you wanted to do it yourself, you'd have to do a traversal starting fromdocumentusing thechildNodesproperty (which implements DOMHTMLCollectioninterface). All DOMElementnodes have a childNodes collection, but not DOM Text nodes, so you'd have to skip non-elements. If you don't want to recreate the wheel, you'd just use the.lengthproperty on the Array returned fromgetElementsByClassName(). If you have more questions, go ahead and ask on my talk page since this is getting a little off topic for this page. Mike Dillon 02:32, 28 May 2007 (UTC)
- The
- Thanks for the precisions. I guess my question boil down to: How do you iterate the whole collection of sub-node without going to GetByxxxx(). Let's say, for the sake of the discussion that I want to create a function that count the number of instance of each class used in a document... -- Shmget 02:00, 28 May 2007 (UTC)
- I'm not sure what you're asking exactly, but
- this is this part right?
- The only difference in behavior between skins would be the part used to find the relevant spans to change. In Monobook, it finds all spans inside the "bodyContent" node; in other skins, it finds all spans inside the whole document. I think the code should work correctly in both cases, unless one of the skins is using "kib", "mib", "gib", or "tib" as a class in the non-article portion of the page. Mike Dillon 14:43, 27 May 2007 (UTC)
.infobox.geography .mergedrow
{{editprotected}} 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)
- 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)
- 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)
- 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)
- 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)
- 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)
Why limit small message boxes to talk header coloring?
Small messageboxes would 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)
- Any objections or problems found with the code? —Centrx→talk • 18:47, 31 May 2007 (UTC)
Non-bold text in table captions?
I wanted to add some non-bold text to a table caption, and was forced to use
<span style="font-weight: normal">nonbold text</span>
Should there be a class for such things?jhawkinson 21:45, 31 May 2007 (UTC)
- 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)