Vis kilden til Moduldiskusjon:Sidebar

{{copied|from=Module:Sidebar|from_oldid=816157517|to=:incubator:Module:Wp/nod/Sidebar|to_diff=4304026}}
{{to do |inner=
* [[/Archive 5#Nomobile use]]
* [[/Archive 5#Make tables into divs instead|#Make tables into divs instead]]
* [[/Archive 5#Width auto and similar sidebars]]
}}
{{Archives}}{{User:MiszaBot/config
| maxarchivesize      = 100K
| minthreadsleft      = 4
| minthreadstoarchive = 1
| counter             = 7
| algo                = old(90d)
| archive             = Module talk:Sidebar/Archive %(counter)d
}}
{{Lua 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. [[User:Noleander|Noleander]] ([[User talk: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 [[Module talk:Sidebar/Archive 7#Title always link-blue?|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 [[Special:Diff/1234103998|was made in 2024]] by @[[User:Jdlrobson|Jdlrobson]] (@[[User:Jon (WMF)|Jon (WMF)]]), with an edit summary saying it was in response to [[mw:Reading/Web/Accessibility_for_reading/Reporting/en.wikipedia.org/Archive_1#%E2%9C%85Fall_of_Constantinople_dark_mode_error|this dark mode error report]]. I've checked [[Template:History of the Byzantine Empire sidebar|the template mentioned in the report]], which now seems to be working fine in dark mode even when you disable the CSS rule. @[[User:Jdlrobson|Jdlrobson]]: would you object to this CSS rule being removed, to allow the title to appear as expected? --<span style="text-shadow:grey 0.15em 0.15em 0.1em">[[User:Yodin|Yodin]]</span><span style="text-shadow:grey 0.25em 0.25em 0.12em"><sup>[[User talk:Yodin|T]]</sup></span> 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. [[User:Jon (WMF)|Jon (WMF)]] ([[User talk: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. --<span style="text-shadow:grey 0.15em 0.15em 0.1em">[[User:Yodin|Yodin]]</span><span style="text-shadow:grey 0.25em 0.25em 0.12em"><sup>[[User talk:Yodin|T]]</sup></span> 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:
:::<syntaxhighlight lang="css">
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 */
</syntaxhighlight>
:::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:
:::<syntaxhighlight lang="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;
}
</syntaxhighlight>
:::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. --[[User:GKNishimoto|GKNishimoto]] ([[User talk:GKNishimoto|talk]]) 01:52, 29 May 2026 (UTC)
::::Thanks for this, I hadn't got around to looking into it. Option B sounds good! --<span style="text-shadow:grey 0.15em 0.15em 0.1em">[[User:Yodin|Yodin]]</span><span style="text-shadow:grey 0.25em 0.25em 0.12em"><sup>[[User talk:Yodin|T]]</sup></span> 10:15, 29 May 2026 (UTC)
:::::I've done some further testing on this, and we need to be careful: the proposed fix using only `.sidebar-title-with-pretitle` will leave standard sidebars unpatched. 
:::::If a sidebar template doesn't employ a pre-title, the MediaWiki parser outputs the class `.sidebar-title` instead. To completely eradicate the "always blue link" bug across all sidebar variations, we must duplicate the `inherit !important` logic for both classes.
:::::Here is the fully inclusive fix that should be applied to both dark mode blocks (clientpref-night and clientpref-os):
:::::<syntaxhighlight lang="css">
/* 1. For standard bars without inline backgrounds: inherits the theme's proper text color */
html.skin-theme-clientpref-night .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title a,
html.skin-theme-clientpref-night .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title-with-pretitle a {
     color: inherit !important;
}
</syntaxhighlight>
:::::This ensures that regardless of whether a template uses a subtitle or a standard title, self-links and visited/unvisited titles will respect the core dark mode skin typography just like light mode does. -- [[User:GKNishimoto|GKNishimoto]] ([[User talk:GKNishimoto|talk]]) 00:38, 15 June 2026 (UTC)
::::::Thank you for continuing to work on this GKNishimoto. @[[User:Jon (WMF)|Jon (WMF)]] any chance you could take a quick look at this ([[#Template-protected edit request on 15 June 2026|full edit request in the section below]]) so that it gets the consensus needed to be implemented? Also pinging @[[User:DaZyzzogetonsGotDaLastWord|DaZyzzogetonsGotDaLastWord]] and @[[User:Redrose64|Redrose64]] who took part in the discussion last year. Thanks! --<span style="text-shadow:grey 0.15em 0.15em 0.1em">[[User:Yodin|Yodin]]</span><span style="text-shadow:grey 0.25em 0.25em 0.12em"><sup>[[User talk:Yodin|T]]</sup></span> 09:34, 15 June 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!

[[User:GKNishimoto|GKNishimoto]] ([[User talk: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 <code>string</code> library would give us a clear performance boost in terms of CPU efficiency on enwiki, keeping <code>mw.ustring</code> 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 <code>mw.ustring</code> 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 <code>trimAndAddAutomaticNewline</code>), 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.
:[[User:GKNishimoto|GKNishimoto]] ([[User talk:GKNishimoto|talk]]) 11:34, 29 May 2026 (UTC)

== Template-protected edit request on 15 June 2026 ==

{{Edit template-protected|Module:Sidebar/styles.css|answered=yes}}
'''Fix sidebar title color and accessibility in dark mode for all sidebar types'''

Based on the consensus for "Option B" in the discussion above, I request a comprehensive update to the dark mode CSS blocks. The current rules force links inside sidebar titles to stay link-blue (<code>var(--color-progressive)</code>) regardless of the link state (including self-links on the subject page). 

Additionally, this updated request expands the fix to cover standard sidebars using <code>.sidebar-title</code> (not just those with pre-titles), and safeguards accessibility against legacy inline background styles.

'''Specific code change:'''

Find:
<syntaxhighlight lang="css">
@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;
    }
}
</syntaxhighlight>

Replace with:
<syntaxhighlight lang="css">
@media screen {
    /* 1. For standard bars without inline backgrounds: inherits proper dark mode text color */
    html.skin-theme-clientpref-night .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title,
    html.skin-theme-clientpref-night .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title-with-pretitle {
        background: transparent !important;
    }
    html.skin-theme-clientpref-night .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title a,
    html.skin-theme-clientpref-night .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title-with-pretitle a {
        color: inherit !important;
    }

    /* 2. Automated fallback: For sidebars carrying hardcoded/inline light backgrounds, forces safe dark background and white text */
    html.skin-theme-clientpref-night .sidebar[style*="background"] .sidebar-title,
    html.skin-theme-clientpref-night .sidebar[style*="background-color"] .sidebar-title,
    html.skin-theme-clientpref-night .sidebar[style*="background"] .sidebar-title-with-pretitle,
    html.skin-theme-clientpref-night .sidebar[style*="background-color"] .sidebar-title-with-pretitle,
    html.skin-theme-clientpref-night .sidebar [style*="background"],
    html.skin-theme-clientpref-night .sidebar [style*="background-color"] {
        background-color: var(--background-color-neutral-subtle, #202122) !important;
        background: var(--background-color-neutral-subtle, #202122) !important;
    }
    html.skin-theme-clientpref-night .sidebar[style*="background"] .sidebar-title a,
    html.skin-theme-clientpref-night .sidebar[style*="background-color"] .sidebar-title a,
    html.skin-theme-clientpref-night .sidebar[style*="background"] .sidebar-title-with-pretitle a,
    html.skin-theme-clientpref-night .sidebar[style*="background-color"] .sidebar-title-with-pretitle a,
    html.skin-theme-clientpref-night .sidebar .sidebar-heading,
    html.skin-theme-clientpref-night .sidebar .sidebar-list-title {
        color: #ffffff !important;
    }
}

@media screen and (prefers-color-scheme: dark) {
    /* 1. For standard bars without inline backgrounds */
    html.skin-theme-clientpref-os .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title,
    html.skin-theme-clientpref-os .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title-with-pretitle {
        background: transparent !important;
    }
    html.skin-theme-clientpref-os .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title a,
    html.skin-theme-clientpref-os .sidebar:not( .notheme ):not([style*="background"]):not([style*="background-color"]) .sidebar-title-with-pretitle a {
        color: inherit !important;
    }

    /* 2. Automated fallback */
    html.skin-theme-clientpref-os .sidebar[style*="background"] .sidebar-title,
    html.skin-theme-clientpref-os .sidebar[style*="background-color"] .sidebar-title,
    html.skin-theme-clientpref-os .sidebar[style*="background"] .sidebar-title-with-pretitle,
    html.skin-theme-clientpref-os .sidebar[style*="background-color"] .sidebar-title-with-pretitle,
    html.skin-theme-clientpref-os .sidebar [style*="background"],
    html.skin-theme-clientpref-os .sidebar [style*="background-color"] {
        background-color: var(--background-color-neutral-subtle, #202122) !important;
        background: var(--background-color-neutral-subtle, #202122) !important;
    }
    html.skin-theme-clientpref-os .sidebar[style*="background"] .sidebar-title a,
    html.skin-theme-clientpref-os .sidebar[style*="background-color"] .sidebar-title a,
    html.skin-theme-clientpref-os .sidebar[style*="background"] .sidebar-title-with-pretitle a,
    html.skin-theme-clientpref-os .sidebar[style*="background-color"] .sidebar-title-with-pretitle a,
    html.skin-theme-clientpref-os .sidebar .sidebar-heading,
    html.skin-theme-clientpref-os .sidebar .sidebar-list-title {
        color: #ffffff !important;
    }
}
</syntaxhighlight>

'''Rationale:''' 
# '''Completeness:''' The original patch only targeted <code>.sidebar-title-with-pretitle</code>. When a template does not use a pre-title, the MediaWiki parser generates <code>.sidebar-title</code> instead. This new code patches both classes simultaneously.
# '''Contrast & Accessibility Safeguard:''' Simply changing the text color to <code>inherit</code> introduces accessibility problems on older articles/templates that still rely on hardcoded inline light backgrounds (e.g., <code>style="background:#A3BFB1;"</code>). Over a light background, <code>inherit</code> turns text white/light gray in dark mode, making it invisible. 
This updated logic utilizes attribute selectors (<code>[style*="background"]</code>) to capture those legacy edge-cases, dynamically overriding the inline style to a safe dark canvas (<code>#202122</code>) and forcing white text for absolute contrast. For regular templates without inline styling, it smoothly switches to <code>inherit</code> as intended. --[[User:GKNishimoto|GKNishimoto]] ([[User talk:GKNishimoto|talk]])
:{{question}}<!-- Template:ETp --> @[[User:GKNishimoto |GKNishimoto]], Do you have cases you can point wrt to problems with the current CSS setup? [[User:Sohom Datta|<b class="skin-invert" style="color:#795cb2; display: inline-block; transform: rotate(0.3deg)">Sohom</b>]] ([[User talk:Sohom Datta|<span class="skin-invert" style="color: #36c;">talk</span>]]) 06:59, 6 July 2026 (UTC)

:@[[User:Sohom Datta|Sohom Datta]], after taking a step back and reviewing the entire context, I've decided to cancel this edit request. 
:To be completely honest, I got a bit caught up in the technical challenge of handling the legacy inline backgrounds via CSS, but looking at the bigger picture, the proposed fix ('color: inherit !important') is essentially just trading one forced behavior for another (six of one, half a dozen of the other). 
:While it fixes the aesthetics of the title on its own subject page, it completely wipes out the distinct link states that Yodin originally mentioned (the native browser handling of visited vs. unvisited links). A global CSS module isn't the right place to hardcode this, as it overrules the MediaWiki parser's native intelligence regarding '.mw-selflink' and link states. 
:Since this requires a more architectural fix rather than just patch-work on this specific stylesheet, I am marking this request as answered/cancelled. Thanks for taking the time to look into it! --[[User:GKNishimoto|GKNishimoto]] ([[User talk:GKNishimoto|talk]]) 11:12, 6 July 2026 (UTC)