-
Notifications
You must be signed in to change notification settings - Fork 702
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TextBox/RichEditBox Shouldn't Force Light Theme on Focus #142
Comments
Agreed that these controls don't do a great job of supporting lightweight styling and require re-templating for app authors to make modifications to their appearance. This issue is similar to an internal bug I had opened. |
You could add properties/brushes for If the Fluent teams still believe Dark Theme needs to have Dark text on Light background, then this would be applied by those brushes, and can be easily overridden in XAML Styles by developers. |
I think by default, user input controls like TextBox should not force light theme when dark mode is enabled. In many apps, it looks jarring and quite inconsistent for this control to light up white when focus is invoked. |
I seem to recall reading some place a few years ago that this limitation has something to do with the caret itself. The caret color does not respect the foreground brush and therefore cannot change from the system 'black'. This is why when editing text everything switches to light mode. If that is true, I think it's time to get this fixed. WPF caret color followed the foreground brush and it should do so in UWP as well. Bottom line I agree that dark mode text input needs to keep the dark mode look -- dark text box background with light text and caret. Switching to light theme for text input is really a strange design decision. Edit: I should also add that WinUI 3 is likely the best opportunity to make a change like this. Everyone is going to be going through and making updates at least to namespaces so some breaking changes are to be expected. Not sure when such an opportunity will present itself again. |
I totally agree that the TextBox and RichEditBox should not force light theme on focus. In addition to breaking the overall design of an app and disturbing the overall look of an app, having it "switch" themes introduces the following problem: When we have a RichEditBox with text that is created with RTF, changing the color of those letters will not be restored when the user leaves and reenters the RichEditBox. tl;dr: The current behavior of TextBox and RichEditBox does not blend in very well and is counterproductive with RTF text as it overwrites styling made by user if the developer does not provide (a lengthy) workaround. |
Any updates on this? It would be a great one to do with WinUI 3.0 |
No updates yet. This is one that I don't believe requires WinUI 3.0 (it seems like the default template could be changed to work better with the lightweight styling, and many of those templates are already in WinUI 2.x). But timing-wise for us it does, as our hands are quite busy with WinUI 3.0.
The goal with WinUI 3.0 is to have the fewest possible breaking changes possible, so that the move from inbox XAML to WinUI 3.0 is smooth. Later we can explore breaking changes with future versions, but we want to avoid the slippery slop of bundling breaking changes with that first version udpate. |
@jevansaks , @ranjeshj , @chrisglein If this an change that the WinUI team approves, I would be happy to try to make a PR for this! |
I mentioned earlier:
Have you checked this? If the caret color cannot be changed you won't be able to fix this with styling. |
Neat 😎 Would love to get feedback from @chigy about the change @chingucoding is proposing above. |
@YuliKl and @chingucoding , |
@YuliKl and @chingucoding , We typically recommend using dark theme controls over images so the control appears more clearer over multiple colors, etc. This will mean that the text field over image would be black if that guidance would have been followed. Something that need to be thought through. @chingucoding , would you mind creating some prototype gif where this is done over image? |
Sure! |
@chigy Have you had time to check with design whether we want the proposed design instead of the current? 😅 Edit: Also there currently are multiple Microsoft apps using a retemplated version with dark background on hover. |
@chingucoding , yes as a matter of fact. That said, please don't add the vertical line you added. That's not part of the design. |
Thanks for the update @chigy ! Is this proposal a change the WinUI team would like to do now, or something that should be done later? If this is something that would be fine to do now, I would love to implement this! |
@chingucoding please go ahead and fix this soon 😀 |
The Rest and Hover states for the TextBox uses semi-transparent backgrounds, with it going 100% opaque on Focus/Typing states |
Yes @mdtauk , good catch! The preview was just to demonstrate that it was possible, and how a dark caret would look on an image. The opaqueness of the "unfocused" will (of course) not change. |
🎉This issue was addressed in #2046, which has now been successfully released as Handy links: |
Describe the bug
Both
TextBox
andRichEditText
include a visual state like this:This interferes with lightweight styling, most notably when trying to theme the editor to remain dark in a dark theme.
Steps to reproduce the bug
x:Class
to match your project)Expected behavior
I expect the TextBox to use
SystemBaseHighColor
from the dark theme, but it resolves to the Light theme instead. Even worse,TextControlBackgroundFocused
resolves to dark because its theme isn't changed in theStyle
.Screenshots
Screenshot showing the dark text (with some text selected in order to show that text exists)
The text was updated successfully, but these errors were encountered: