MediaWiki talk:Common.css

I think that CSS to increase visibility of header for class would help newer readers. The header is relative important information but it is using 0.8em size only. Good solution might be using bold text like:

.ddcl-list-header-col1 { font-size: 1em; } .ddcl-list-header-col1 tt { font-weight: bold; font-size: 1.15em; }

At least to me that configuration looked a bit better when testing using firebug.


 * In my opinion emphasizing header file wouldn't be a good idea. Header file is undoubtedly an important bit of information, however most of the time it is not the thing people come to a page looking for, especially since that information is usually also present at the parent page and/or can be derived from the library/class name. Thus I think for most users the proposed change would have distracting effect. Additionally, we would lose consistency across and  items, since we can't apply a similar change for the former group of templates because the effect of distracting would be much stronger there. So for now I'll leave the CSS as is, unless there are more users who would like to see this implemented. Anyways, thanks for suggestion.P12 13:33, 17 September 2011 (PDT)

latest changes broke mfrac on Chrome
Latest changes. Looks good in msie though. --Cubbi 13:54, 28 September 2011 (PDT)
 * Have you purged the cache? You might be using the old CSS. If not, which version are you using? Might be a bug in Chrome, since mfrac also works on version 13.0.782.215 of Chrome and Firefox 7.P12 01:24, 29 September 2011 (PDT)
 * Huh, odd, I was sure I cleared it a bunch of times. Did it again today just once, and it worked perfectly fine. Sorry for alarming. --Cubbi 06:28, 29 September 2011 (PDT)

Hide the Category box at the bottom of each page?
Now that we have TODOs causing Category boxes to appear at the bottom of a lot of pages, how about hiding that box with e.g. ".catlinks { display: none; }" (as per this link)? I feel that the information added is redundant (we can already see the TODOs listed on the page) and makes pages look a little cluttered. --Nate 14:26, 7 May 2012 (PDT)


 * I agree. I hesitated a bit because I thought that there might be some cases where these links are useful. I failed to think of even one such case, so it seems it's certainly worth hiding them. -- P12 15:07, 7 May 2012 (PDT)

Inappropriate line break after a .
For me (Firefox 60.0.2 on Linux) cpp/language/escape renders with a line break between a and a closing parenthesis. (Manually changing of the  from  to just  fixes the problem.) (What's the reason for setting  of  to  anyway?) -- Radix (talk) 15:10, 14 April 2020 (PDT)
 * Keeps the contents of the span together in the event that a span contains multiple lines. P.S. there is no line break over here (Chrome/81), and AFAIK doesn't cause line breaks --Ybab321 (talk) 03:27, 15 April 2020 (PDT)
 * I believe is supposed to be used for inline snippets of code, so there should be no multiline spans. Otherwise they would like this:

 Here's a multiline test:. That was a multiline test.
 * — Radix (talk) 15:20, 15 April 2020 (PDT)
 * (In Firefox 75.0 on Windows 10 I have the opposite problem — there is a line break between the opening parenthesis and the span.) — Radix (talk) 14:56, 15 April 2020 (PDT)
 * I'm not aware of any multiline s either, it's just my understanding of  (and for completeness sake, here's the  version):

 Here's a multiline test:   throw 123 ;  . That was a multiline  test.
 * --Ybab321 (talk) 01:34, 16 April 2020 (PDT)

Forcing the width of and  to a fixed value has drawbacks.
What is the rationale for setting the width of and  to 55em? That seems rather arbitrary and has at least two negative consequences: — Radix (talk) 11:40, 26 April 2020 (PDT)
 * 1) The listing in cpp/language/initialization would look better if it was split into three columns of a table with header cells stating the filenames. Currently attempting to do so results in a table too wide because each of its columns is forced to have width 55em.
 * 2) When styled with Vector skin, the width of the page content is not fixed. Therefore the width of listings should probably not be fixed either.

Why style cell borders instead of  row borders?
Why do

instead of just

? — Radix (talk) 15:39, 26 April 2020 (PDT)