Namespaces
Variants
Views
Actions

MediaWiki talk:Common.css

From cppreference.com

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 dcl list * and ddcl list * 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)

Contents

 [hide

[edit] latest changes broke mfrac on Chrome

Latest changes broke mfrac in Google Chrome. 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)

[edit] 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)

[edit] Inappropriate line break after a span.t-c.

For me (Firefox 60.0.2 on Linux) cpp/language/escape#Notes renders with a line break between a span.t-c and a closing parenthesis. (Manually changing display of the span.t-c from inline-block to just inline fixes the problem.) (What's the reason for setting display of t-c to inline-block 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 inline-block doesn't cause line breaks --Ybab321 (talk) 03:27, 15 April 2020 (PDT)
I believe {{c}} 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 {{c}} test: throw
123;
. That was a multiline {{c}} 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 {{c}}s either, it's just my understanding of inline-block (and for completeness sake, here's the inline version):
Here's a multiline {{c}} test: throw
123;
. That was a multiline {{c}} test.
--Ybab321 (talk) 01:34, 16 April 2020 (PDT)

[edit] Forcing the width of pre and .mw-geshi to a fixed value has drawbacks.

What is the rationale for setting the width of pre and .mw-geshi to 55em? That seems rather arbitrary and has at least two negative consequences:

  1. The listing in cpp/language/initialization#Deferred dynamic 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.

Radix (talk) 11:40, 26 April 2020 (PDT)

[edit] Why style .t-rev cell borders instead of .t-rev row borders?

Why do

.t-rev > td:nth-child(1) {
    border: 1px solid silver;
    border-right: none;
}
 
.t-rev > td:nth-child(2) {
    border: 1px solid silver;
    border-left: none;
}

instead of just

.t-rev {
    border: 1px solid silver;
}

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

[edit] FIX last lines, please (patch is inside)

Several last lines in this MediaWiki:Common.css need to be updated (for reason described here) to properly process the first 7 "exposition-only" elements in the kw-list-cpp.

So, replace please these 12 lines (note - only 6 ids: kw100...kw105):

/* ======================================================================
   SYNTAX HIGHLIGHTING HACKERY
 ------------------------------------------------------------------------
*/
.mw-geshi.cpp .kw100, .mw-geshi .cpp .kw100,   /* boolean-testable */
.mw-geshi.cpp .kw101, .mw-geshi .cpp .kw101,   /* no-throw-forward-iterator */
.mw-geshi.cpp .kw102, .mw-geshi .cpp .kw102,   /* no-throw-forward-range */
.mw-geshi.cpp .kw103, .mw-geshi .cpp .kw103,   /* no-throw-input-iterator */
.mw-geshi.cpp .kw104, .mw-geshi .cpp .kw104,   /* no-throw-input-range */
.mw-geshi.cpp .kw105, .mw-geshi .cpp .kw105 {  /* no-throw-sentinel-for */
    font-style: italic;
}

with the following 13 lines (note - 7 ids, kw100...kw106):

/* ======================================================================
   SYNTAX HIGHLIGHTING HACKERY
 ------------------------------------------------------------------------
*/
.mw-geshi.cpp .kw100, .mw-geshi .cpp .kw100,   /* container-compatible-range */
.mw-geshi.cpp .kw101, .mw-geshi .cpp .kw101,   /* boolean-testable */
.mw-geshi.cpp .kw102, .mw-geshi .cpp .kw102,   /* no-throw-forward-iterator */
.mw-geshi.cpp .kw103, .mw-geshi .cpp .kw103,   /* no-throw-forward-range */
.mw-geshi.cpp .kw104, .mw-geshi .cpp .kw104,   /* no-throw-input-iterator */
.mw-geshi.cpp .kw105, .mw-geshi .cpp .kw105,   /* no-throw-input-range */
.mw-geshi.cpp .kw106, .mw-geshi .cpp .kw106 {  /* no-throw-sentinel-for */
    font-style: italic;
}
 [ExpandThis is the excerpt from kw-list-cpp with "exposition-only" names
container-compatible-range => cpp/ranges/to
boolean-testable => cpp/concepts/boolean-testable
no-throw-forward-iterator => cpp/memory/ranges/nothrow_concepts
no-throw-forward-range => cpp/memory/ranges/nothrow_concepts
no-throw-input-iterator => cpp/memory/ranges/nothrow_concepts
no-throw-input-range => cpp/memory/ranges/nothrow_concepts
no-throw-sentinel-for => cpp/memory/ranges/nothrow_concepts

--Space Mission (talk) 14:11, 28 September 2023 (PDT)