Guild Wars 2 Wiki talk:Projects/CSS documentation

Nav subheaders

I wonder if we could get subheader colours for navigation templates (especially for the skin Monobook) based on the table subheader colour scheme (see Guild Wars 2 Wiki:Color schemes#Table colors). This would avoid inline style background colour definition and thus the navs would also be usable properly in the darkmode skin Vector. See also point two in Guild Wars 2 Wiki:Projects/CSS documentation#Notes.

For example, in a lore navigation template we could use the class="subheader lore" with the following definition:

<!-- MONOBOOK -->
div.nav .subheader.lore {
  background-color: #E6B3E6;
  border-color: #B88FB8;
}
<!-- VECTOR -->
div.nav .subheader {
  background-color: #40434A;
  border-color: #5A5C5E;
}

Requested .subheader classes

• Profession
  • .guardian
  • .revenant
  • .warrior
  • .engineer
  • .ranger
  • .thief
  • .elementalist
  • .mesmer
  • .necromancer
• Race
  • .asura
  • .charr
  • .human
  • .norn
  • .sylvari
• Other
  • .npc
  • .pve
  • .equip
  • .skin
  • .mech1
  • .mech2
  • .location
  • .lore
  • .promo
  • .quest
  • .condition
  • .hom
  • .crafting
  • .recipe
  • generic: defaulting to the generic table colour scheme

CSS code

div.nav .subheader.guardian {
  background-color: #B9E0EC;
  border-color: #94B3BD;
}

div.nav .subheader.revenant {
  background-color: #E3B4AA;
  border-color: #BFA8A0;
}

div.nav .subheader.warrior {
  background-color: #FFE8B3;
  border-color: #CCBA8F;
}

div.nav .subheader.engineer {
  background-color: #E8BC84;
  border-color: #BA966A;
}

div.nav .subheader.ranger {
  background-color: #C7EFA2;
  border-color: #9FBF82;
}

div.nav .subheader.thief {
  background-color: #DEC6C9;
  border-color: #B29EA1;
}

div.nav .subheader.elementalist {
  background-color: #FBC5C3;
  border-color: #C99E9C;
}

div.nav .subheader.mesmer {
  background-color: #DBBCEA;
  border-color: #AF96BB;
}

div.nav .subheader.necromancer {
  background-color: #A9D3B7;
  border-color: #87A992;
}



div.nav .subheader.asura {
  background-color: #D1BDF8;
  border-color: #A797C6;
}

div.nav .subheader.charr {
  background-color: #FFBCC3;
  border-color: #CC969C;
}

div.nav .subheader.human {
  background-color: #FFF2B3;
  border-color: #CCC28F;
}

div.nav .subheader.norn {
  background-color: #BADDFF;
  border-color: #95B1CC;
}

div.nav .subheader.sylvari {
  background-color: #B0F3B2;
  border-color: #8DC28E;
}



div.nav .subheader.npc {
  background-color: #B3E699;
  border-color: #8FB87A;
}

div.nav .subheader.pve {
  background-color: #FFE6B3;
  border-color: #CCB88F;
}

div.nav .subheader.equip {
  background-color: #FFCCB3;
  border-color: #CCA38F;
}

div.nav .subheader.skin {
  background-color: #FFD4DF;
  border-color: #B3A1A5;
}

div.nav .subheader.mech1 {
  background-color: #B3CCE6;
  border-color: #8FA3B8;
}

div.nav .subheader.mech2 {
  background-color: #99E6E6;
  border-color: #7AB8B8;
}

div.nav .subheader.lore {
  background-color: #E6B3E6;
  border-color: #B88FB8;
}

div.nav .subheader.location {
  background-color: #CCB3E6;
  border-color: #A38FB8;
}

div.nav .subheader.promo {
  background-color: #CCE699;
  border-color: #A3B87A;
}

div.nav .subheader.condition {
  background-color: #A8D3A8;
  border-color: #86A986;
}

div.nav .subheader.hom,
div.nav .subheader.crafting,
div.nav .subheader.recipe {
  background-color: #E6CCB3;
  border-color: #B8A38F;
}



div.nav .subheader {
  background-color: #CCC;
  border-color: #AAA;
}

Is this too much or an actually useful addition? P.S. I'm not sure if the class should be called subheader corresponding to the table or subheading corresponding to the already existing nav class heading. --Tolkyria (talk) 22:28, 2 July 2021 (UTC)

I'm not averse to adding some more color rules. I think "subheading" is already so infrequently used for tables that we could use subheading again for navs without any great issues. -Chieftain Alex 18:08, 6 July 2021 (UTC)

Okay, thanks. In return we could get rid of the rarely used nav classes "hom" (used in HoM rewards nav only, replace it with e.g. "equip" or "recipe") and "condition" (haven't found any nav using it so far) if we want. --Tolkyria (talk) 19:58, 6 July 2021 (UTC)

The nav border color seems to override the generic "subheading" color. Maybe we have to add the class "any" or "generic" to properly trigger it. --Tolkyria (talk) 22:52, 6 July 2021 (UTC)

Ugh tables in navs... picking up the parent nav's class not the inside table. -Chieftain Alex 23:37, 6 July 2021 (UTC)

Been a while since I looked at this. Removed condition and hom nav classes as suggested.

For the border color issue, I've made a copy of the Professions nav here. Was the issue that the vertical border at the right-hand side of the first cell always uses the nav border colour? -Chieftain Alex 20:31, 22 September 2021 (UTC)

Should be fixed. -Chieftain Alex 20:53, 22 September 2021 (UTC)

Thanks! --Tolkyria (talk) 12:40, 27 September 2021 (UTC)

/template misc

Any reason for the different visual appearence from /template misc? Namely, monobook applies full border around darkfill and lightfill (actually it applies the border to the top class, e.g. wiki-help or wiki-projects) and vector applies full border only around darkfill.

For example:

• Monobook: Guild Wars 2 Wiki:About and Guild Wars 2 Wiki:Projects/CSS documentation
• Vector: Guild Wars 2 Wiki:About and Guild Wars 2 Wiki:Projects/CSS documentation

--Tolkyria (talk) 08:15, 26 July 2021 (UTC)

I thought the monobook layout was ugly and didn't really want to replicate it in dark, and figured people would object if I changed monobook. -Chieftain Alex 19:13, 26 July 2021 (UTC)

Okay. --Tolkyria (talk) 20:07, 26 July 2021 (UTC)

Advanced search

The class div.mw-advancedSearch-fieldContainer { padding-right: 180px; } is kinda wierd, introducing a pretty huge space between the search headers/boxes and the right border, letting them end somewhere in the middle; it also reduces the namespace dropdown bar length, avoiding to take the full width.

By the way, wikipedia and mediawiki seems to use { max-width: 50em; } as total width for their search boxes. --Tolkyria (talk) 18:12, 9 September 2021 (UTC)

The 180px padding on the right is to avoid clipping with the results counter, e.g. <div class="results-info" data-mw-num-results-offset="0" data-mw-num-results-total="1563">Results <strong>1 – 20</strong> of <strong>1,563</strong></div>

I've gone with a full width search bar because we have an enormous number of namespaces searched in by default. Actually on second thoughts that might be a migrated set of preferences for my account where i search in every namespace by default. -Chieftain Alex 19:29, 9 September 2021 (UTC)

If I'm correct the 180px padding to avoid clipping with reluts-info isn't done by div.mw-advancedSearch-fieldContainer, which is responsible for the padding in the inner box. There it adds a padding to the right box border (which in my opinion is unnecessary, why leave this space empty), thus my initial suggestion to set div.mw-advancedSearch-fieldContainer to 0 (or actually remove it from the class list in common.css).

To be precise, I would remove the two classes div.mw-advancedSearch-namespace-selection and div.mw-advancedSearch-fieldContainer to get rid of the unnecessary inner box padding which - if I'm correct - doesn't affect the result counter.

Please try, for demonstration purposes setting it to 0px instead of removing it:

@media screen and (min-width: 1000px) {
  div.mw-advancedSearch-expandablePane-options,   /* upper box "outside" padding */
  div.mw-advancedSearch-expandablePane-namespaces /* lower box "outside" padding */{
      padding-right: 180px;
  }
}

@media screen and (min-width: 1000px) {
  div.mw-advancedSearch-namespace-selection /* upper box "inside" padding */,
  div.mw-advancedSearch-fieldContainer      /* lower box "inside" padding */{
      padding-right: 0px;
  }
}

--Tolkyria (talk) 21:25, 9 September 2021 (UTC)

If i may add something with regards to the text size of the i icon popups: The selector in the rule to make the text smaller (.mw-special-Search .oo-ui-popupWidget { font-size: 80%; }) also selects the alert and notification popups in the menu bar in the top right while on Special:Search. It would be great if the later two would retain their sizes even while on Special:Search. Nightsky (talk) 22:04, 9 September 2021 (UTC)

And if i may suggest another thing with regards to the possitions of the down arrows not being centered, .mw-advancedSearch-container span .oo-ui-indicator-down { margin-top: 0; } would be great to have so that they are. Nightsky (talk) 18:19, 12 September 2021 (UTC)

I'm annoying again: Why does the search window look so nice and compact in your preview when it looks like this on a wide screen? Can't we reduce the width a bit and get rid of the right padding in the two boxes? --Tolkyria (talk) 18:11, 22 September 2021 (UTC)

Yes you two are an eternal thorn in my side aren't you... unfortunately you are both a necessary evil and unparallelled in finding bugs of all sorts which I miss. You know full well that the search window looked like that on my preview because my window size was small.

Going back to the top:

• I started off having to pump up the width because our font sizes are different to core MW. This is required to make the field inputs line up with the elements (59%).
• I hadn't understood Nightsky's comment but I now do. As an explanation, the tooltips upon pressing [i] beside the fields are generated outside the main page structure with no ideal way of targeting them for advanced search only. Due to our font sizes being different to core MW they appear freakishly large without this. I have however identified some CSS which works. (The correct fix would probably be to resize ALL notifications and remove any existing rules I changed on the alterts/notifications dropdown area, but I cba right now).
• Making the advanced search box fullscreen made sense for me due to my search preference to search in all namespaces. It seems you two don't like that and I'm willing to put that bit back in my own custom css (alongside my fullscreen search results in coloured boxes).
• The other remaining css rule for advanced search that I will leave is fixing border positions on the second dropdown box.
• Arrow position is a good call, i've added that now.

-Chieftain Alex 19:49, 22 September 2021 (UTC)

While I think that the wiki taught me to see large empty whitespace usages (in my opinion unwanted) in any form (vertical/horizontal), I don't really have an idea how to fix those when it comes to CSS, so your edits much appreciated, thanks!

I noticed that the search results takes now an own line, instead of floating right. I think this is caused by #mw-search-top-table div.oo-ui-actionFieldLayout { float: none; } and .results-info { margin-top: 1em; }. --Tolkyria (talk) 12:40, 27 September 2021 (UTC)