Skip to content

fix: normalize <select> rendering for consistent appearance across we…#26

Closed
Orchardxyz wants to merge 1 commit intoRealZST:mainfrom
Orchardxyz:fix/consistent-appearance-select
Closed

fix: normalize <select> rendering for consistent appearance across we…#26
Orchardxyz wants to merge 1 commit intoRealZST:mainfrom
Orchardxyz:fix/consistent-appearance-select

Conversation

@Orchardxyz
Copy link
Copy Markdown
Contributor

Summary

The select styling on desktop is inconsistent with the web mode.

Changes

Before

image

After

image

@RealZST
Copy link
Copy Markdown
Owner

RealZST commented Apr 29, 2026

Thanks for the PR!

I tried to reproduce the "Before" rendering on my Mac, but my pre-PR <select> already looks pretty close to your "After".

Could you share your macOS version? Just want to understand whether this is a code issue or a system-level rendering difference.

Thanks again

@Orchardxyz
Copy link
Copy Markdown
Contributor Author

Thanks for the PR!

I tried to reproduce the "Before" rendering on my Mac, but my pre-PR <select> already looks pretty close to your "After".

Could you share your macOS version? Just want to understand whether this is a code issue or a system-level rendering difference.

Thanks again

@RealZST My environment: macOS 15.6 (Apple M4, 16GB RAM)
This issue only happens on desktop, not on web.

@RealZST RealZST closed this in #32 May 1, 2026
RealZST added a commit that referenced this pull request May 1, 2026
Native macOS Aqua chrome renders <select> as heavy 3D-style buttons in
WKWebView on macOS 15.x Sequoia, clashing with the rest of the flat UI
(see #26 for screenshots). Newer macOS releases ship a flatter native
chrome, but we can't rely on the user's OS version.

Drop the `!isDesktop()` gate from `webSelectStyle` and `isWeb` so the
normalized chrome (appearance: none + custom SVG arrow + matching border
/ padding) applies on desktop too. Add `WebkitAppearance: "none"` next
to `appearance: "none"` as a defensive belt-and-suspenders for any
older WebKit that doesn't honor unprefixed (Safari 15.4+ supports
unprefixed; this is purely defensive).

Verified visually in Tauri dev on macOS 26.4 — desktop renders identical
to web. Original report from @Orchardxyz on macOS 15.6.

Closes #26

Co-authored-by: Orchard <orchardyz@outlook.com>
@RealZST
Copy link
Copy Markdown
Owner

RealZST commented May 1, 2026

Thanks for catching this.

Tried your patch locally first — the bug is real, but the className changes in extension-filters.tsx caused new visual issues on my Mac (macOS 26.4), where the native chrome is already flat.

Opened #32 with a smaller approach: just drop the !isDesktop() gate in src/lib/web-select.ts.

Closing in favor of #32. If you still see any issues, feel free to open a new PR or issue.

Thanks again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants