https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Sally <sally.healey@cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sally.healey@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #2 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #0)

While in the OPAC we can assume that libraries have done heavy customizations to the color scheme, this might be easier, assuming that most libraries stick to our standard design/color scheme.

That's a good point! Most of my libraries don't style their staff interfaces, and the ones that do only do to a minor degree. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Jessie Zairo <jzairo@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jzairo@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m --- Comment #4 from Lisette Scheer <lisette@bywatersolutions.com> --- Bootstrap has a built in color modes/themes option now https://getbootstrap.com/docs/5.3/customize/color-modes/ It doesn't have a built in theme picker, but they do share some java script they use for the documentation. I see that the dark mode on their documentation/the built in is really nice. I'm not sure if it's one of the color palettes Alexander shared, but it's definitely a similar idea. It would also be easy to force light mode in printing We could potentially add a default dark theme and the switcher to the staff interface. It also documents how to add additional ones, which we could do if we wanted or if down the line we wanted to make a way for folks to add custom ones it could be an option. I'd love to be able to do this, especially since it has an option to follow the browser setting and do it automatically. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Owen Leonard from comment #5)

I did some tinkering with this last week. The color modes option is really only relevant for Bootstrap components, so whether or not we use those modes, a lot of custom CSS will have to be written. I'm not saying that to discourage anyone, but to say that we don't necessarily need to figure out the Bootstrap way of doing things.

On a different project, I've been converting a site from jQueryUI to Bootstrap 5, and I hear what you're saying here. We don't use Bootstrap components everywhere, and even if we did, we still customize the CSS beyond the default themes. (I've been working on figuring out how to take advantage of Bootstrap defaults while providing a minimal amount of custom styling on my other project. I'm loving using the CSS variables.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #7 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to David Cook from comment #2)

(In reply to Katrin Fischer from comment #0)

...

While in the OPAC we can assume that libraries have done heavy customizations to the color scheme, this might be easier, assuming that most libraries stick to our standard design/color scheme.

That's a good point! Most of my libraries don't style their staff interfaces, and the ones that do only do to a minor degree.

This was an assumption that is causing me a headache right now. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #8 from David Nind <david@davidnind.com> --- While I don't know how to do it and what is involved (and there is a lot of discussion on the internet about how and why), maybe we make sure Koha respects a person's system-wide choices, instead of more code to maintain (if that is possible). Whatever choice is made, please please make it optional and not turned on by default - I personally find dark mode websites VERY hard to read (I actively dislike them, and will only read if I really really have to, and have no other choice). I realise this is the opposite to others preferences 8-) It is also sometimes "sold" as an accessibility solution, which it can be in some situations. But more often than not, it is a matter of personal preference. Some links and articles that provide a (hopefully) balanced view: - Nielsen Norman Group article: Dark Mode: How Users Think About It and Issues to Avoid (2023) https://www.nngroup.com/articles/dark-mode-users-issues/ - Dark mode & accessibility myth (2024) https://stephaniewalter.design/blog/dark-mode-accessibility-myth-debunked/ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- David, you are not the only one - I know a lot of people would like to have a dark mode and that's perfectly fine and I would like for Koha to have the feature, but I am unlikely to be using it :) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37054 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com --- Comment #13 from Jonathan Druart <jonathan.druart@gmail.com> --- I was not aware of this bug. It looks like a duplicate of bug 31327, where a patch is waiting for feedback... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #15 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Christian Stelzenmüller from comment #14)

The other bug says "Add color scheme picker to the OPAC", but the patch was written for the staff interface it seems (i just tested in a sandbox, the staff interface is partially black). So i'm a little confused

Both discussion and identical: we want a dark-theme. No matter the interface, we need to discuss how to do and implement it. Yes the bug title is saying "OPAC", but the patch is only touching the staff interface. Yes it's confusing, sorry about that. I think the dark-them discussion should stay on a a single bug report, especially when 2 days ago we are talking here about prefers-color-scheme and the patch on the other bug used it 3 months ago... Good to see the discussion moving on though! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #17 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #16)

Agreed, good to see this moving. What about we merge the bugs and make one "Implement dark mode". Alternative: start a new omnibus and attach both.

We should also consider Bug 37054, it is similar. It would be better if we could make all of this work in conjunction with one another, and not compete. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- Just bumped into this one while doing some light/dark stuff in Bootstrap 5 on a different app... https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/light-dark -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |39495 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39495 [Bug 39495] [OMNIBUS] Staff Interface Theming -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Angela Berrett <angela.berrett@familysearch.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|angela.berrett@familysearch | |.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #22 from Sharon Dugdale <sharon.dugdale@cumbria.gov.uk> --- Following on from my previous comment, my colleague has discovered a website that has code added to allow dark mode (or migraine mode) to be activated using a toggle at the bottom of the screen: https://www.migrainedisorders.org/ I'm probably telling you something you are already aware of but I promised to pass on the information as he finds this makes a huge difference. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Anni Mäki-Mantila <anni.maki-mantila@turku.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anni.maki-mantila@turku.fi -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Fiona Borthwick <fiona.borthwick@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fiona.borthwick@openfifth.c | |o.uk -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #25 from Jonathan Druart <jonathan.druart@gmail.com> --- Please see comment #13: (In reply to Jonathan Druart from comment #13)

I was not aware of this bug. It looks like a duplicate of bug 31327, where a patch is waiting for feedback...

-- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #27 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- (In reply to Martin Renvoize (ashimema) from comment #26)

(In reply to Jonathan Druart from comment #25)

...

Please see comment #13:

(In reply to Jonathan Druart from comment #13)

...

I was not aware of this bug. It looks like a duplicate of bug 31327, where a patch is waiting for feedback...

Isn't 31327 the OPAC equivilent..?

Ha.. no.. it's a request for the OPAC, but looking at the patch you've actually done the staff client.. I completely missed that! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #28 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198388 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198388&action=edit Bug 38550: PoC Dark theme See https://getbootstrap.com/docs/5.3/customize/color-modes/ -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #30 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198390 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198390&action=edit Bug 38550: Replace hardcoded hex with surface tokens in staff-global The PoC patch swapped one hex literal (#E6E6E6) for a Sass variable that resolved at compile time, leaving every other panel in the staff client glued to a light value. This patch replaces the hex/Sass-var references in the high-traffic staff-global.scss components with the runtime --koha-* CSS custom properties introduced in the foundation commit, so they re-skin in dark mode without further changes. Components touched: * .patroninfo (sidebar patron summary) — surface-accent + on-surface * .sidebar_menu (admin/tools left nav) — surface-accent, surface-muted for nested ul / hover / active, on-surface for link text, muted text for the heading * .edit-patronimage (button on patron details) — surface-accent + border-strong + on-surface, with hover dropping to surface-muted * #search-facets (catalog search left rail) — surface-accent panel; the green h4 banner moves to brand-on so the white text stays an intentional choice rather than a coincidence * #browse-return-to-results (browse-shelf return link) — surface-accent * .empty (used in patron sidebar when no value is present) — on-surface-muted These are the components flagged in the dark-mode review as visible two-tone breakage points: light-grey islands stranded against dark chrome, or black text reading 2:1 on a dark surface. After this patch they all flip cleanly via the [data-bs-theme="dark"] toggle. The Sass variable $default-color-grey now has no callers in staff-global.scss; its definitions in _variables.scss and _variables-dark.scss are left in place for any third-party customisations that may reference them, and will be revisited in the cleanup patch. Test plan: 1) Apply patch, rebuild: yarn css:build 2) localStorage.setItem('theme','light'); reload — confirm patron sidebar (cgi-bin/koha/members/moremember.pl?…), admin sidebar (cgi-bin/koha/admin/admin-home.pl), search facets and browse- return panels look identical to pre-patch (no visual regression) 3) localStorage.setItem('theme','dark'); reload same pages — confirm each panel now shows a dark surface with legible text instead of the previous near-white island 4) On the patron page, hover/active states in the admin sidebar — confirm hover bg darkens (light) / lightens (dark) consistently 5) WCAG contrast check on each component in both modes — target 4.5:1 for body text, 3:1 for large text -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #32 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198392 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198392&action=edit Bug 38550: Token Vue SFC scoped styles Audits all Vue single-file components in the staff client whose scoped <style> blocks contain hardcoded hex colours, replacing them with the runtime --koha-* CSS custom properties. Vue scoped styles are emitted into the rendered CSS but with attribute-scoping selectors, so they participate in the [data-bs-theme="dark"] cascade exactly like the rest of the staff stylesheets — they just needed to actually use the tokens. Components touched: * LeftMenu.vue — disabled left-menu links use on-surface-muted, the active-disabled variant uses on-surface * SIP2/Main.vue — same disabled-link palette plus a left-border on the .current.disabled link routed through surface-accent * ModuleDashboard/ModuleDashboard.vue — the empty-placeholder uses surface-muted / on-surface-muted with a themed dotted border; the runtime drag-drop border (set via JS) uses var(--koha-border) * ModuleDashboard/WidgetDashboardWrapper.vue — .widget body and header surfaces with explicit on-surface text and themed dividers * ModuleDashboard/WidgetPickerWrapper.vue — picker .widget-header uses surface-muted with themed border * ModuleDashboard/Widgets/ERMCounts.vue — count-list pills use surface-accent with on-surface text; inactive-link uses on-surface-muted * ResourceFormSave.vue — the accordion-fieldset legend's resting border uses var(--koha-surface). The intentional Koha-green hover (#6faf44) and blue caret (#4c7aa8) are LEFT as hex literals — they are decorative brand accents, not surface colours, and are legible against both modes * ERM/UsageStatisticsReportsViewer.vue — the JS-set rowspan border uses var(--koha-border) instead of the hardcoded #BCBCBC The remaining Vue components scanned (ResourceShow, the ERM *-Widget/-LatestSUSHIJobs/-LicensesNeedingAction/-RunUsageReport, EHoldingsEBSCOPackageAgreements) flagged in the initial sweep turned out to contain only Vue template slot syntax (#default, actual hex colours — and are unaffected. Test plan: 1) Apply patch, rebuild Vue: yarn js:build 2) Light mode: load each touched view (Module dashboard incl. drag- drop reorder, SIP2 menu, the resource accordion, ERM counts widget, usage statistics reports). Confirm no visual regression 3) Dark mode: same views. Confirm: - Widget cards are dark surfaces with light text - Dashboard empty-drop placeholder reads as a dark dotted slot - Disabled left-menu links remain visibly muted but legible - ERM count pills are dark accent pills with legible text - Usage stats table rowspan border is visible against dark cells 4) Brand-coloured accents (the green legend hover and blue caret in ResourceFormSave) should look identical in both modes — they are decorative, not surface-derived -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #34 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198394 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198394&action=edit Bug 38550: Cypress smoke spec and stylelint hex guard Adds two guard rails so the dark-mode work doesn't regress and future contributions don't accidentally re-introduce hardcoded hex colours in tokenised areas. Cypress: t/cypress/integration/Theme_spec.ts * Verifies the FOUC-killer in doc-head-open.inc has set data-bs-theme synchronously by the time the page is interactive. * Round-trips each of "light" / "dark" / "auto" preferences through localStorage + reload and asserts the resolved theme on <html> matches. * Reads the actual computed --koha-surface and --koha-on-surface values in light vs dark mode and asserts they differ — i.e. the cascade really flips, not just the attribute. * Drives the dropdown UI: clicks Light / Dark and asserts aria-pressed moves between buttons and data-bs-theme follows. * Loads four representative pages (mainpage, patrons home, catalogue search, admin home) in each mode and asserts the attribute is correct on each. cy.screenshot() is wired but commented — uncomment once a snapshot plugin (e.g. cypress-image-snapshot) is added to make this a real visual regression suite. Stylelint: .stylelintrc.json overrides * New "color-no-hex" rule scoped to staff SCSS sources, with severity "warning" and a message pointing reviewers at _root.scss / --koha-* tokens. The rule does NOT fail builds — many existing files still contain hex tech debt — but every PR diff with a fresh hex literal in a tokenised file will get a visible warning in CI. * The currently-tokenised files (_mixins.scss is implicit by having no hex; this list covers files that intentionally hold the colour values) are allowed via override: _variables.scss, _variables-dark.scss, _root.scss, _flatpickr_vars.scss * The currently-still-dirty files are also listed in the same override so the rule stays quiet for them until they're audited: staff-global.scss, _tables.scss, _header.scss, _flatpickr.scss, _forms.scss, edifact_interchange.scss, installer.scss, calendar.scss, holds.scss, mainpage.scss As each file is migrated to tokens, its entry is deleted from this list and the rule begins guarding it. * OPAC SCSS (koha-tmpl/opac-tmpl/...) is intentionally OUT of scope: dark-mode work for the OPAC is a separate effort. Housekeeping: _root.scss reflowed to single-space declarations to satisfy the existing declaration-colon-space-after rule, and the leading multi-line block comments rewritten to drop the empty "//" continuation lines that scss/comment-no-empty flagged. Test plan: 1) Apply patch 2) Cypress: yarn cypress run --spec "t/cypress/integration/Theme_spec.ts" All assertions should pass against a freshly-built KTD instance. 3) Stylelint demo: echo '.foo { color: #BADA55; }' \ > koha-tmpl/intranet-tmpl/prog/css/src/_demo.scss npx stylelint koha-tmpl/intranet-tmpl/prog/css/src/_demo.scss Expect ⚠ (warning) for the hex literal pointing at _root.scss. 4) Stylelint clean files: npx stylelint koha-tmpl/intranet-tmpl/prog/css/src/_root.scss Expect no color-no-hex warnings. 5) When auditing one of the still-dirty files: remove its path from the second override block in .stylelintrc.json, run stylelint, fix any new warnings. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #36 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198396 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198396&action=edit Bug 38550: Token table status rows and DataTable chrome Finishes the table audit: every hex literal in _tables.scss is replaced with a token (Koha --koha-* surfaces or Bootstrap --bs-*-bg-subtle / --bs-*-text-emphasis status pairs), and three table Sass variables in _variables.scss that were shadowing themselves with literal-hex values are reverted to var()-based forms so they re-skin in dark mode. Sass variable redefinitions (_variables.scss): $table-border-color: #BCBCBC → var(--bs-border-color) $table-header-background: #FFF → var(--koha-surface-muted) $table-odd-row: #f3f4f4 → var(--koha-surface-muted) These three were defined twice in _variables.scss — once as var()-based forms higher up (matching Bootstrap defaults) and again ~1000 lines later as literal-hex overrides. The literal overrides won the cascade, so every <th>, every odd-stripe row and every cell border was pinned to the light-mode value. The new values mean the staff client's table grid flips in lockstep with the body bg. DataTables runtime token (_tables.scss top): Adds a [data-bs-theme="dark"] block that re-emits --dt-row-selected, --dt-row-selected-text and --dt-row-selected-link with dark-mode-friendly RGB triplets. DataTables consumes these via rgb()/rgba() to paint selected rows; previously the light-mode triplet stayed pinned in dark mode, producing pale-green selections on dark cells with black-on-near-black text. Status rows (semantic colours): Mapped to Bootstrap 5.3's *-bg-subtle / *-text-emphasis token pairs. They flip automatically — pale bg + dark text in light, dark bg + pale text in dark — and preserve each colour's semantic identity. .ok / .onissue / .odd.onissue / .selections-table:hover / td input.approve / .onissue:nth-child(odd) → warning-bg-subtle + warning-text-emphasis .reserved → success-bg-subtle + success-text-emphasis .transferred → info-bg-subtle + info-text-emphasis .warn → danger-bg-subtle + danger-text-emphasis The "loud" flag rows that should stand out — .highlighted-row, .warned-row, .high-warned-row, .selected-row — keep solid --bs-warning / --bs-danger / --bs-success backgrounds rather than the subtle variants, paired with their text-emphasis token so legibility holds in either mode. DataTable chrome: .dt-processing overlay → surface-overlay + on-surface .dt-buttons > .dt-button:hover → surface-muted + border-strong .dt-paging-button.current → on-surface-muted .dt-button-collection .buttons-columnVisibility:hover → surface-muted .buttons-csv/excel/html5/print → surface + on-surface :hover → surface-muted .dt-button-down-arrow → on-surface-muted .pager input[type="search"] → input-bg / input-color / input-border .filter_column input[type="text"] → on-surface-muted .table_controls border-top → border-muted caption → on-surface The brand-coloured icons inside DataTable export buttons (.buttons-html5/.buttons-print ::before) and the link-coloured .dt-paging-button + .dt-button-active::after still reference $background-color-primary / $green-text-color directly. They are brand identity, not surface colour, so they are deliberately left as constants. stylelint: _tables.scss is removed from the dirty-files override block in .stylelintrc.json. The color-no-hex rule now actively guards it, so any future hex literal regresses CI as a warning. Test plan: 1) Apply patch, rebuild: yarn css:build 2) Light mode — load: - the issues table on a patron page (rows with .onissue, .reserved, .transferred should still look pale yellow, pale green, pale blue; with dark text) - any DataTable with a paging footer; click a column to sort, hover a column-visibility button, click an export button - a circulation page that paints .warn rows - the selections-table on a virtual shelf (hover should highlight pale yellow) 3) Dark mode — same pages. Confirm: - status rows now use *dark* bg with pale text and remain visually distinct from each other - the active table-paging button stays muted - the export buttons inside the column-visibility menu have dark surfaces with legible text - DataTables row-select highlight is dark-olive, not pale green-on-dark 4) Spot-check WCAG contrast on each status row's text (Bootstrap 5.3's text-emphasis is tuned for AA on its bg-subtle pair). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #38 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198398 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198398&action=edit Bug 38550: Token .searchheader and sidebar .action fieldset Two more leftovers on the catalogue results / search pages were still pinned to light values: * .searchheader — the sticky toolbar that sits above search results (sort / actions / batch operations). It hardcoded background-color: #F3F4F4 and color: #696969, leaving a light-grey strip floating across an otherwise dark page. Now uses var(--koha-surface-muted) + on-surface-muted. * The `& + .action` rule paired with the search-facets sidebar in staff-global.scss: when an .action fieldset directly follows another fieldset (used for the apply-to-results buttons under the facet list), it explicitly re-painted itself white via background-color: #FFF, side-stepping the @mixin card exclusion that normally leaves .action transparent. Switched to var(--koha-surface) + var(--koha-on-surface) so the panel flips with the rest of the chrome. Test plan: 1) Apply patch, rebuild: yarn css:build 2) Light mode: visit /cgi-bin/koha/catalogue/search.pl?q=… — confirm the sticky header above the results table and the apply-to-results action card under the left facets look identical to pre-patch. 3) Dark mode: same page. Confirm both panels now use dark surfaces and read as a continuation of the page chrome, with their text legible against the new bg. 4) Spot-check the same .searchheader pattern on patrons-home results and the cataloguing addbooks search. Spot-check the .action fieldset on any sidebar that has an apply-button block. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #39 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- I grabbed Jonathans initial patch from bug 31327, rebadged it for this bug number (as this is the one focused on Staff client), tested and fixed all the obvious issues I found in the follow-ups. We'll need lots more testing here and agreement on the token replacements I've made. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #40 from Jonathan Druart <jonathan.druart@gmail.com> --- 1. /cgi-bin/koha/admin/preferences.pl https://snipboard.io/LtZ62B.jpg * I think green and blue are lacking contrast * Syspref's names shouldn't be black Coming from: label, .label { color: #000; Adjust of all #000 needed? 2. /cgi-bin/koha/circ/circulation-home.pl https://snipboard.io/1iy29X.jpg Should be styled like on the mainpage Coming from: .buttons-list li a { background-color: #E0E0E0; Should get background-color: var(--koha-surface-accent) 3. /cgi-bin/koha/members/member.pl?quicksearch=1&circsearch=1&searchmember=d * https://snipboard.io/K6QOvV.jpg Needs to review rules for .btn-default * https://snipboard.io/CXFqa1.jpg https://snipboard.io/i6eWZV.jpg DT's info are not visible enough 4. /cgi-bin/koha/catalogue/search.pl?q=d https://snipboard.io/W5lXyM.jpg Pagination buttons too bright .pagination { --bs-pagination-bg: #fff; 5. /cgi-bin/koha/erm/home https://snipboard.io/ujsCLK.jpg .widget[data-v-7709258a] { background-color: #fff; .widget-header[data-v-7709258a] { background-color: #f7f7f7; 6. /cgi-bin/koha/erm/agreements/add https://snipboard.io/8pHlNf.jpg Select2: form .v-select { background-color: white; I can retest as soon as those are fixed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198388|0 |1 is obsolete| | Attachment #198389|0 |1 is obsolete| | Attachment #198390|0 |1 is obsolete| | Attachment #198391|0 |1 is obsolete| | Attachment #198392|0 |1 is obsolete| | Attachment #198393|0 |1 is obsolete| | Attachment #198394|0 |1 is obsolete| | Attachment #198395|0 |1 is obsolete| | Attachment #198396|0 |1 is obsolete| | Attachment #198397|0 |1 is obsolete| | Attachment #198398|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #42 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200764 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200764&action=edit Bug 38550: Token foundation and FOUC fix The PoC patch hardcoded data-bs-theme="dark" on every <html> element and relied on switch-theme.js running on DOMContentLoaded to undo it for users who chose Light. That caused a flash of dark theme on every page load. It also shipped a dead `.element` demo rule copied from the Bootstrap docs, and pinned every fieldset / page-section / patroninfo panel to a hardcoded #FFF via @mixin card, leaving them unreachable from any future dark-mode work. This patch lays the foundation needed before the rest of the audit work can land: * A new _root.scss partial defines a small set of Koha CSS custom properties (--koha-surface, --koha-on-surface, --koha-border, …) for both light and dark, using Bootstrap 5.3's color-mode() mixin to emit the dark overrides on [data-bs-theme="dark"]. Component SCSS in subsequent patches references these tokens instead of hardcoded hex literals. * @mixin card now uses var(--koha-surface) / var(--koha-on-surface) so every fieldset, .page-section and .patroninfo-section flips with the theme without further changes. * doc-head-open.inc no longer hardcodes data-bs-theme="dark". An inline FOUC-killer script reads localStorage (or prefers-color-scheme as a fallback) and sets the attribute on <html> before first paint. The localStorage call is wrapped in try/catch so privacy/kiosk lockdowns degrade gracefully to light. * The dead `.element { ... }` block under @include color-mode(dark) in staff-global.scss is removed. Test plan: 1) Apply patch, rebuild CSS: yarn css:build 2) With a fresh browser profile (no localStorage), load the staff client. Confirm no flash of dark theme; the page renders light. 3) In devtools, run localStorage.setItem('theme','dark'); reload. Confirm page renders dark from the first paint (no flash). 4) localStorage.setItem('theme','light'); reload. Confirm light. 5) localStorage.removeItem('theme'); set OS to dark mode, reload. Confirm page renders dark via prefers-color-scheme. 6) Inspect any fieldset / .page-section: in dark mode it should now pick up var(--koha-surface) (#1E1E1E) instead of #FFF. 7) grep the compiled CSS for [data-bs-theme=dark] — Koha tokens should appear under it alongside Bootstrap's own dark overrides. This patch is intentionally infrastructure-only. The bulk of the hardcoded hex literals across staff-global.scss, _forms.scss, _tables.scss, _toolbar.scss, _header.scss, mainpage.scss and the Vue SFCs is addressed in follow-up patches in this series. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #44 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200766 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200766&action=edit Bug 38550: Token forms, tables, toolbar, header and news Extends the dark-mode coverage from staff-global.scss to the rest of the global staff-client SCSS partials. After this patch every form field, table cell, toolbar button, search-bar autocomplete panel and home-page news block flips correctly between light and dark via the [data-bs-theme="dark"] toggle, instead of staying glued to white. Token additions (_root.scss): * --koha-input-bg / --koha-input-color / --koha-input-border / --koha-input-bg-disabled. The custom (.fg-row) form widgets use a dedicated palette: in dark mode the input sits one elevation step lighter than its containing card so empty fields read as fields, and the readonly icon retains contrast. Components touched: * _forms.scss - fieldset legend uses --koha-on-surface-muted (was #696969) - .fg-row btn-default border, text inputs/select, readonly inputs, textareas and file inputs all use the new --koha-input-* tokens - the <table>.unselected fallback bg is var(--koha-surface) * _tables.scss - default <td> bg + colour use --koha-surface / --koha-on-surface so the body of every datatable flips with the theme - .dt-button caption colours, sort-arrow placeholder, dtrg-group grouping rows, .group rows and tr.expired / tr.highlight all use surface / on-surface tokens with a strong border for separators - status-meaning row/cell colours (paid, overdue, selected, info) are intentionally left untouched in this patch — they need a semantic-tokens pass with the Bootstrap *-bg-subtle family * _toolbar.scss - #toolbar / .btn-toolbar bg uses --koha-surface-muted; the inner .btn-default text and hover state use on-surface-muted with surface-accent for the hover bg - dropdown items inside the toolbar drop their hardcoded "black" text colour for --koha-on-surface * _header.scss - the autocomplete .form-content panel and .form-extra-content drop-down both use --koha-surface-overlay for their bg, with on-surface text and a themed divider between fields - the active breadcrumb link replaces dimgray with --koha-on-surface-muted - text colours that sit on the (constant) brand-green nav are deliberately left as "white" / "$green-text-color" * mainpage.scss - .newsitem uses --koha-surface / --koha-border-muted with explicit on-surface text. The pre-existing opacity: .75 has been removed: on a dark page background it produced grey-on-grey body text failing AA, and on light it offered no real visual benefit - .newsfooter uses --koha-on-surface-subtle - .biglinks-list .icon_general uses surface-accent / on-surface in its rest state and brand / brand-on on hover, with the inner .fa-stack-1x dropping to on-surface-muted Test plan: 1) Apply patch, rebuild: yarn css:build 2) Light mode (localStorage.setItem('theme','light')) — load the home page, a patron form (members/memberentrygen.pl), the catalogue search results page and the admin home page. Confirm each looks identical to pre-patch (regression check) 3) Dark mode (localStorage.setItem('theme','dark')) — same pages. Confirm: - News blocks are dark surfaces with light text (no white islands) - Form fieldsets, legends and inputs all read as cohesive dark - Datatables: header / body / hover / grouping all themed - Toolbar above a results table is dark with legible button text - Header search autocomplete drop-down is a dark overlay - Big icon links on the home page use the dark accent surface 4) WCAG contrast spot-check: legend text, .newsfooter, .icon_general stack icon, breadcrumb-active. Aim for 4.5:1 body / 3:1 large. 5) The status-meaning colours (overdue red, paid green, selected yellow) are intentionally NOT yet themed — they will be addressed with the Bootstrap *-bg-subtle mapping in a follow-up. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #46 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200768 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200768&action=edit Bug 38550: Replace toggle buttons with Light/Dark/Auto dropdown The PoC patch's two btn-dark buttons in the navbar had several problems: in dark mode the .btn-dark colour rendered them invisible against the .bg-dark navbar; they offered no "follow system" option even though the JS already supported one; aria-pressed wasn't initialised in markup so screen readers had no toggle state until DOMContentLoaded ran; and the click handlers threw on browsers where localStorage access is blocked (privacy mode, kiosk lockdowns), silently breaking the toggle. This patch replaces the two buttons with a single dropdown in the user-menu area styled to match the existing #debug-controls-dropdown pattern, and rewrites switch-theme.js to be hardened, accessible and "auto"-aware. Markup changes (header.inc): * New #bd-theme nav-item dropdown: a sun / moon / half-circle icon toggle (matching the resolved theme) opens a Light / Dark / Auto menu. Each option uses a Font Awesome icon, a label and a trailing checkmark that's hidden by default and revealed only on the option whose aria-pressed is "true". * Default markup state is aria-pressed="true" on Auto, so screen readers and the visual checkmark are coherent on first paint even if JS hasn't run yet — switch-theme.js then corrects this to match the persisted preference once the DOM is ready. * The toggle's aria-label is updated on each change to read e.g. "Toggle colour theme (current: dark)". Style changes (_header.scss): * #bd-theme .theme-active-marker visibility flips from hidden to visible based on the parent button's aria-pressed state. Using visibility (not display) preserves the dropdown's row layout. Behavioural changes (switch-theme.js): * localStorage reads/writes are wrapped in try/catch. When storage is unavailable, the toggle still works for the current page; reloading just resets to system-preferred. * Three preferences are now distinct: "light", "dark", "auto". resolveTheme(preference) returns the *resolved* theme actually applied to <html>, while the dropdown shows the *preference*. * "Auto" really tracks the OS: matchMedia('(prefers-color-scheme: dark)') has a change listener that re-applies the resolved theme whenever the preference is "auto" (or no preference is stored). * showActiveTheme() updates aria-pressed, the .active class, the toggle's icon (sun / moon / half-circle) and the toggle's aria-label every time. Also focuses the toggle after a click so keyboard users land back on the switcher. * Initial application of data-bs-theme remains the responsibility of the inline FOUC-killer in doc-head-open.inc — this script no longer touches the attribute on script load, only on user clicks and on system-preference changes when in "auto". Test plan: 1) Apply patch, rebuild: yarn css:build 2) Fresh browser profile (no localStorage, OS in light mode): - Reload — page renders light, dropdown shows half-circle icon, "Auto" option has the checkmark - Switch OS to dark mode (without reloading) — page flips to dark, half-circle icon stays (preference is still "auto") 3) Click "Light" — page flips to light, sun icon shown, "Light" option marked. Reload — preference persists. 4) Click "Dark" — page flips to dark, moon icon shown, "Dark" option marked. Reload — preference persists. 5) Click "Auto" again — preference resets, half-circle icon shown, resolved theme follows OS. 6) Open devtools, simulate localStorage being blocked (Safari "Block all cookies" or Firefox strict mode). Reload — no JS errors; toggle still works for the session; reload reverts to system preference. Confirm in console no "SecurityError". 7) Keyboard navigation: tab to the dropdown toggle, Enter opens the menu, arrow keys move between options, Enter activates, focus returns to the toggle after activation. 8) Screen reader (NVDA / VoiceOver): on opening the menu, each option is announced with its label and pressed state. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #48 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200770 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200770&action=edit Bug 38550: Fix nav-tabs active and tab-content panel in dark mode Two pieces of tab styling were still pinned to white and didn't flip with the colour-mode toggle: 1) The active tab itself. _variables.scss overrode Bootstrap's defaults for $nav-tabs-link-active-bg and $nav-tabs-link-active-border-color from var(--bs-body-bg) to a literal $white. The original Bootstrap-style values were even left as a comment beside the override. With this in place the .nav-tabs .nav-link.active button stayed solid white in dark mode, producing a glaring white pill on top of the dark page chrome and a white sliver where the active tab's border meets the panel. Reverting both Sass variables to var(--#{$prefix}body-bg) makes the active tab's bg/border resolve through Bootstrap's own dark override of --bs-body-bg, so the active tab now reads as a continuation of the panel underneath in either mode. 2) The .tab-content panel. staff-global.scss hardcoded background-color: #FFF on the wrapper that holds every tab-pane. In dark mode this stayed white, dwarfing the active tab and turning all body text black on white inside the panel. Switched to var(--koha-surface) / var(--koha-on-surface) so the panel matches the rest of the tokenised surfaces. The Koha-specific .nav-tabs .nav-link override (brand-green pill for *inactive* tabs with white text) is intentionally left alone: it's the staff client's signature tab look, and brand green + white still reads cleanly in either mode. Test plan: 1) Apply patch, rebuild: yarn css:build 2) In light mode, open any tabbed view (a patron details page, the catalogue detail / authority / acquisitions screens). Tabs should look identical to pre-patch — green inactive pills, white active pill, white panel. 3) Switch to dark mode. The active tab should now render dark and merge into the dark .tab-content panel. The inactive tabs stay green (intentional). The panel itself should be the same shade as other dark cards / fieldsets on the page. 4) Spot-check pages that mount tab badges (e.g. patron checkout counts) — the green/white inactive tabs and their badges continue to read in both modes. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #50 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200772 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200772&action=edit Bug 38550: Token #searchresults panel and results summary The catalogue results page (#searchresults) was still pinned to a solid white panel via background-color: #FFFFFF on the wrapper itself, with several text colours hardcoded inside it. In dark mode this rendered as a glaring white block dropped into the otherwise-dark page chrome with the rest of the staff client flowing around it. Touched in staff-global.scss: * #searchresults — panel bg → var(--koha-surface), with explicit --koha-on-surface for body text on it * #searchresults h3 — heading colour → on-surface-muted (matches the muted-heading convention used elsewhere) * #searchresults td ul li — bullet-list item text → on-surface * #searchresults span.status — the "not available / lost / etc." red status line → var(--bs-danger-text-emphasis), so it stays semantically red but with AA-legible contrast against the panel in either mode (dark red on dark bg in the previous literal #900 was unreadable) * .results_summary — the header summary block above each search result page → on-surface, with .label on-surface-muted The .edi-search-results block in edifact_interchange.scss is a separate, EDI-only browser overlay and is intentionally left out of this commit; it lives in its own dirty-file entry in the stylelint override and will be addressed alongside the rest of edifact_interchange.scss. Test plan: 1) Apply patch, rebuild: yarn css:build 2) Light mode: visit /cgi-bin/koha/catalogue/search.pl?q=… or any module that mounts #searchresults (acquisitions parcels, authority lookup, cataloguing addbooks). Confirm the panel looks identical to pre-patch. 3) Dark mode: same pages. Confirm: - the search-results panel is now a dark surface flowing into the page chrome - heading + bullet item text remains readable - "Not available" / "Lost" status lines still read as red but in dark-mode-tuned shade (Bootstrap's danger-text- emphasis), not the unreadable dark-red literal - .results_summary text and field labels above the table are legible in both modes -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #52 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200774 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200774&action=edit Bug 38550: Fix dark-mode colour contrast (black-on-dark, light islands) Several staff-interface components bypassed the --koha-* runtime theme tokens and hardcoded colour literals, so they did not flip when data-bs-theme="dark" is set. This produced black text on dark surfaces, bright "light island" backgrounds, and dark green/red text that fell below WCAG AA on dark surfaces. Because elements with no explicit colour inherit Bootstrap's --bs-body-color (which auto-flips to light in dark mode), a hardcoded light background with no explicit dark text rendered as light-on-light, and hardcoded dark colours rendered as dark-on-dark. This patch migrates the offending literals to var(--koha-*) tokens. Each token's light value equals the previous literal, so light mode is unchanged; only the dark value is tuned for AA contrast. - _root.scss: add --koha-link, --koha-link-hover, --koha-text-success and --koha-text-danger tokens (light greens/reds lifted to #6FBF73 / #FF6B66 on dark, ~7.3:1 / ~5.9:1), plus dark overrides for Bootstrap --bs-pagination-* and a dark re-skin of .btn-default. - staff-global.scss: migrate black text on flipping surfaces (.label, modal/dropdown/panel headers, table-footer totals, labeledMARC, autocomplete, tooltips, i18n menu, superlibrarian hint, subtle badges), light-island backgrounds (buttons-list, results wrappers, fieldset standard/contrast, panels, toptabs, MARC preview, footer, permission tree) and green/red text literals to tokens. - _tables.scss, _header.scss: green text and a white hover background to tokens. - vue.css, SIP2/Main.vue, ILL/Main.vue: tokenise v-select control background/border and theme the vue-select dropdown (--vs-*). Semantic highlights that carry their own fixed light background plus dark text (.term, gold approve buttons, .ac-library chips, .alert-warning strong) are intentionally left unchanged, as they read correctly in both themes. To test: 1. Enable dark mode in the staff interface (data-bs-theme="dark"). 2. Confirm AA contrast on: admin/preferences.pl (syspref labels and sidebar links), circ/circulation-home.pl (module buttons), members/member.pl search (.btn-default, DataTables info), catalogue/search.pl (pagination), erm/home (widgets) and erm/agreements/add (v-select). 3. Toggle back to light mode and confirm no visual change. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Sponsorship status|Seeking sponsor |Sponsored Comma delimited| |West Sussex County Council list of Sponsors| |<https://www.westsussex.gov | |.uk/>, OpenFifth | |<https://openfifth.co.uk/> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |RESOLVED Resolution|--- |DUPLICATE --- Comment #54 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- *** This bug has been marked as a duplicate of bug 39495 *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 --- Comment #55 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- I decided the bug was already getting a bit of a monster so I've split it and migrated the parts into clearer focused bugs. (so far adding up to the same hole) Please look at bug 42902 to apply the full set as a whole comparing to here.. The split I came up with following the work we did here. * Bug 42898 - Dark-mode foundation and theme switcher for the staff interface Add's the switcher logic and a foundation of css to get the general look OK, but it's by no means a full theme; It's designed as the foundational bug - Please focus on testing the switching functionality there - Light mode (default), Dark mode and Automatic (system) * Bug 42899 - Dark mode for core staff interface chrome Updates CSS to variables more consistently.. this is the one that really tries to get the general staff client UI consistent in Dark Mode * Bug 42900 - Dark mode for tables and status rows Lots of issues were found with tables and dark mode.. I've collected those into a patch here.. there's other DataTables work in the tree so I thought splitting it out was sensible to allow rebasing against those as they make their way in. * Bug 42901 - Dark mode for Vue components in the staff interface Vue handles css differently in many places.. so this also made sense as it's own focused bug. So, in short.. I'd like to push forward with the foundation bug and then add the others on top as and when they pass QA -- You are receiving this mail because: You are watching all bug changes.