Skip to content

Use PrimaryColor for floating watermark on TextBox #427

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

sn4k3
Copy link
Contributor

@sn4k3 sn4k3 commented Mar 15, 2025

Current style:

image

This PR:

image

Avalonia fluent theme follows same applying the primary color to floating watermark:

image

@kikipoulet
Copy link
Owner

Indeed, floating watermark wasn't styled at all, I didn't know it exists.

However, the current styling show problems, primarly because of the box size variation when starting to type that is not acceptable, because the textbox control remains an input control. So I have this proposition to handle the floating style :

floating

@sn4k3
Copy link
Contributor Author

sn4k3 commented Mar 17, 2025

Yes, avalonia hides floating watermark if the input is null. This shouldn't be the default at all, it should allow us to configure the default behaviour: HideIfEmpty or AlwaysShow.
Your concept kinda improves the current situation, however I still think is not the best approach, because of design...
Lets say you have a form in a 2x2 grid

Username | Password
Name | LastName (Optional)

As you type in the watermarks are going into labels, meaning now username have a label but all others don't, until you fill them.
Now Lastname is optional, I will not put my last name, in terms of design you have a "broken" view (Not consistent), because 3 fields now have labels and the optional fields won't get one. In terms of reading a form and locating labels that should be in same position and visible.

My suggestion: Leave floating watermark as it is, fix styling, and maybe remove the null-hide condition.
Additionally write an extension eg theme:TextBoxExtensions.Label to prepend a label (always visible) as like your example. (string Label, enum Position[Left,Top,Right,Bottom], Default:Top)
This give us two features and styles instead of one.

This route also allows to have a label and a different watermark something like this:

Location:
[ City, Country ]

While your concept lock us into use watermark only for label.

@kikipoulet
Copy link
Owner

We don't want to handle labels in the textbox style, it's the dev responsability to handle it as he wants, using a stackpanel and textblock for example.

I merged my concept because I had simplified the style tree, so it's a better starting point anyway. I'm not against thinking about a style like this :

{EAD44819-5738-4664-8EF6-ECFC6A429414}

But we need a better concept, especially about height variation. The last option is to force a bigger height on the floating textboxes but it will be ugly too. We need something better.

@sn4k3
Copy link
Contributor Author

sn4k3 commented Mar 29, 2025

We don't want to handle labels in the textbox style, it's the dev responsability to handle it as he wants, using a stackpanel and textblock for example.

I agree, however your solution does look like a label. If labels could be handed by extension, the only wise strategy was to stack vertically, as the horizontally will not align with multiple inputs.

But we need a better concept, especially about height variation. The last option is to force a bigger height on the floating textboxes but it will be ugly too. We need something better.

IMO I think we should stick with avalonia concept of floatingWatermark but instead of hide when Text is null/empty, it's always visible, this will solve the dynamic height problem. In my mind doesn't make sense to hide it when text is empty because we are losing information in those case.
Your concept can be easy replicated by a stackpanel, making a "label" but a floating watermark like avalonia does inline is not easy without re-template, that's why I think is wiser to stick with the original concept.

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