Module talk:Sidebar

Alternative text for image

I added a brief instruction on how to provide alternative text for the sidebar image, as is required for WP:ALT. This is not an obscure detail: I had no idea how to do it 10 months ago, and I posted a query here in this Talk page, and got an answer. Then the same question came up yesterday in an FAC review. There may be lots of editors that have tried to help blind users by adding alt text to sidebar images, and gave up. The mechanism is not at all obvious, even to experienced editors, because many expect the "alt" attribute to be a sibling of the "image" attribute So, I added instructions. I inserted the instructions within the "image" attribute explanation. Noleander (talk) 15:17, 10 March 2026 (UTC)

Dark mode: title always blue

In dark mode, the title is always blue, as if it was an unvisited wikilink (regardless of if the reader has visited the page or not), even when on the title's subject page (e.g. Rhetoric). Light mode is completely unaffected by this, with the title appearing as expected. I noticed that this had been raised before, and the relevant CSS rule identified, but it wasn't fixed at the time as it wasn't clear why the rule existed. As this discussion points out, the CSS change was made in 2024 by @Jdlrobson (@Jon (WMF)), with an edit summary saying it was in response to this dark mode error report. I've checked the template mentioned in the report, which now seems to be working fine in dark mode even when you disable the CSS rule. @Jdlrobson: would you object to this CSS rule being removed, to allow the title to appear as expected? --Yodin^T 15:30, 23 April 2026 (UTC)

I don't know this template too well, so defer to the people that do.

From what I can see, as long as the background is guaranteed to be transparent, it should probably be fine removing the rule for .sidebar:not(.notheme) .sidebar-title-with-pretitle a

If the background has a color, this could be more of a problem.

Hope this is helpful. Jon (WMF) (talk) 19:37, 24 April 2026 (UTC)

Thanks for looking into this. Unless anyone else knows the best way to handle this, I'll try to find a fix. --Yodin^T 16:02, 25 April 2026 (UTC)

I took a look at the module's 'styles.css' and found the exact rules causing this behavior under the night/dark media queries:

html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-title-with-pretitle a {
     color: var( --color-progressive ) !important;
}
/* And the equivalent rule for skin-theme-clientpref-os */

The aggressive use of '!important' forces the anchor to stay link-blue regardless of the link state, completely overriding the browser's native handling of visited links or self-links on the subject page.

Since the background is forced to 'transparent !important' right above this rule, we can safely fix this by either dropping the '!important' and targetting unvisited links, or changing the value to 'inherit'.

Proposed fix for both dark mode blocks in the CSS:

/* Option A: Allow default states but keep blue for unvisited entries */
html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-title-with-pretitle a:not(:visited) {
     color: var( --color-progressive );
}
/* Option B: Let the anchor simply inherit the title's proper text color */
html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-title-with-pretitle a {
     color: inherit !important;
}

Option B is probably the cleanest drop-in solution since it renders self-links as regular bold title text, exactly as it behaves in light mode. --GKNishimoto (talk) 01:52, 29 May 2026 (UTC)

Thanks for this, I hadn't got around to looking into it. Option B sounds good! --Yodin^T 10:15, 29 May 2026 (UTC)

Proposed performance optimization: Replacing remaining mw.ustring functions with native string library

Hi everyone,

While reviewing the module's code, I noticed that an excellent performance optimization was previously implemented in the 'move_hiding_templatestyles' function by switching from 'mw.ustring' to the native Lua 'string.gmatch' and 'string.gsub' functions.

However, several other functions in this module are still heavily relying on 'mw.ustring' for processing text patterns that are strictly ASCII (such as internal configuration patterns, HTML/CSS class names, and argument keys). Since 'mw.ustring' adds overhead by routing requests through PHP, replacing it with the native 'string' library where multibyte character support isn't needed will yield better CPU efficiency given the high volume of transclusions this module handles.

I propose updating the following functions to use native Lua string methods:

• 'categorizeTemplatesWithInlineStyles': Change 'mw.ustring' to 'string.find'. (line #23)
• 'trimAndAddAutomaticNewline': Change 'mw.ustring.gsub' and 'mw.ustring.find' to 'string.gsub' and 'string.find'. (lines #36 and #37)
• 'detectChild': Change 'mw.ustring.find' to 'string.find'. (line #48)
• 'has_list_class': Change both instances of 'mw.ustring.find' to 'string.find'. (lines #74 and #76)

Since the template parameters and basic syntax checkers ('^[#*:;]', '^{|', 'class', etc.) strictly look for basic ASCII characters, this is a completely safe drop-in optimization.

I would appreciate it if an editor or interface administrator could look into this. We can implement and thoroughly test these changes in the module's sandbox first to ensure everything works flawlessly before patching the live module. Let me know what you think!

GKNishimoto (talk) 01:39, 29 May 2026 (UTC)

Update: After reflecting further on this and reviewing the cross-wiki ecosystem, I realize there is a broader architectural layer to consider here.

While switching to the native string library would give us a clear performance boost in terms of CPU efficiency on enwiki, keeping mw.ustring in these specific functions might very well be an intentional design choice for cross-wiki compatibility. Since enwiki acts as the upstream source for many other language Wikipedias, modules are frequently imported into wikis that utilize multibyte UTF-8 characters for argument keys, custom CSS classes, or specific page titles.

In this sense, preserving mw.ustring works as a safeguard to ensure the module doesn't break upon export, even if it introduces a small overhead for strictly ASCII environments like ours.

I still believe it's worth evaluating if we can safely optimize certain strictly core-syntax functions (such as the wikitext list syntax checkers in trimAndAddAutomaticNewline), but I completely understand if the consensus is to prioritize global portability and robust internationalization over micro-optimizations. I'd love to hear the interface administrators' thoughts on where we should draw the line between performance and cross-wiki safety here.

GKNishimoto (talk) 11:34, 29 May 2026 (UTC)

Template-protected edit request on 29 May 2026

Fix sidebar title color in dark mode

In short, replace var( --color-progressive ) with inherit on lines #183 and #194.

Based on the consensus reached in the discussion above, I request an update to the dark mode CSS blocks to fix the issue where sidebar titles with self-links are forced to remain link-blue.

Please replace the aggressive progressive color rule with 'color: inherit !important' for both the 'skin-theme-clientpref-night' and 'skin-theme-clientpref-os' blocks.

Specific code change:

Find:

@media screen {
    html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-list-title,
    html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-title-with-pretitle {
      background: transparent !important;
    }

    html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-title-with-pretitle a {
         color: var( --color-progressive ) !important;
    }
}

@media screen and (prefers-color-scheme: dark) {
    html.skin-theme-clientpref-os .sidebar:not( .notheme ) .sidebar-list-title,
    html.skin-theme-clientpref-os .sidebar:not( .notheme ) .sidebar-title-with-pretitle {
        background: transparent !important;
    }
    
    html.skin-theme-clientpref-os .sidebar:not( .notheme ) .sidebar-title-with-pretitle a {
        color: var( --color-progressive ) !important;
    }
}

Replace with:

@media screen {
    html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-list-title,
    html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-title-with-pretitle {
      background: transparent !important;
    }

    html.skin-theme-clientpref-night .sidebar:not( .notheme ) .sidebar-title-with-pretitle a {
         color: inherit !important;
    }
}

@media screen and (prefers-color-scheme: dark) {
    html.skin-theme-clientpref-os .sidebar:not( .notheme ) .sidebar-list-title,
    html.skin-theme-clientpref-os .sidebar:not( .notheme ) .sidebar-title-with-pretitle {
        background: transparent !important;
    }
    
    html.skin-theme-clientpref-os .sidebar:not( .notheme ) .sidebar-title-with-pretitle a {
        color: inherit !important;
    }
}

Rationale: This implements "Option B" from the discussion. It allows the anchor to correctly inherit the title's proper text color (white/light gray) in dark mode, matching the expected behavior of light mode where self-links don't render as unvisited blue links. This is safe as long as the background remains transparent (which is already enforced by the preceding CSS rule). GKNishimoto (talk) 12:18, 29 May 2026 (UTC)