fix: normalize <select> rendering for consistent appearance across we…#26
fix: normalize <select> rendering for consistent appearance across we…#26Orchardxyz wants to merge 1 commit intoRealZST:mainfrom
Conversation
|
Thanks for the PR! I tried to reproduce the "Before" rendering on my Mac, but my pre-PR 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) |
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>
|
Thanks for catching this. Tried your patch locally first — the bug is real, but the className changes in Opened #32 with a smaller approach: just drop the Closing in favor of #32. If you still see any issues, feel free to open a new PR or issue. Thanks again |
Summary
The select styling on desktop is inconsistent with the web mode.
Changes
Before
After