Of course, after than, whatever you’ve just plugged into it, will most likely not work
502 Bad Gateway
504 Gateway Timeout
X-Forwarded-For
The solution is probably somewhere deep in the bowels of whatever you’re trying to make work
It will look obvious once you’ve figured out, that’s why it wasn’t mentioned next to the bunch of instruction you pasted into your console to install the thing
Just another day walking in the forest of papercuts
Cause that’s what I intuitively expected, because in the tools that I use daily, that how it is there. Here are some examples of other administrative web interfaces that use grey to show you the implicit default that I happen to have running and could find in like 3 minutes. So much for your overconfident “always”:
Note: I’m not talking about a form to fill in your name with “john doe” or whatever, and even that I can’t even remember seeing either. Cause it just says “Name:” and nobody needs an example.
Those TrueNAS fields seem gray because they’re disabled (since it’s inherited), not because those are defaults.
inherited versus default, that is kind of splitting hair when we’re talking about user interface.
Here the gray means “this is what it’s going to be if you don’t write something else here”
Disagree. When it’s inherited, the gray value is not applied, because it’s defined somewhere else. It’s not a default in this case.
For the web, there’s no reason to make them faded out / grey if they’re default values.
Those fields can just be pre-populated with those default values, which is unambiguous and get sent with the other user-edited fields.
Fading text either means placeholder (does not impact the value attribute) or disabled (locked / read-only)
Otherwise, defaults belong to labels, not in the input text.
Being shown what’s the default isn’t the same as having it actually in the field. For example the default might change, then these values would change with the default. There are also cases where they are inherited or something similar, where the upstream value isn’t as fixed as defaults normally are. So there is a functional difference to showing you a greyed out default and actually having that default be in the field.
Especially for things that essentially are a web interface for a config file where the config file gets larger with values that aren’t needed (this includes both NPM and Proxmox, as examples). Instead of like 3-4 lines it could now be like 20. It also becomes unclear when looking at the values later if they were actually set to that value intentionally or if it just happens to be the default that got filled in because some UI was used that filled all fields with their default values.
Showing the default outside in a label or as a tooltip-hover is an option, but has implications for the space needed and readability. And this way is actually much clearer if you want to look over a config and you need for example the default port or something, it’s in the exact place you expect it, shown in grey to make it clear that it wasn’t set intentionally but that it’s just the default. In some UIs there’s room for defaults, in some not. I personally vastly prefer them to be shown like this, as you might have guessed already.
That’s getting into application state management and heavily dependent on what kind of form it is.
What I wrote above reflects what web forms usually follow, and they don’t use faded values for defaults, because in the context of a form, defaults are just values that were pre-populated and get no special styling.
I think you keep missing my point. This isn’t about a “usual web form”. You aren’t entering your address or something. You’re configuring a service or server. Those are very different worlds. I understand that those kinds of forms where you enter your address (or whatever) wouldn’t ever have a default in there. In that context a default doesn’t make any sense (default name, default street, default city?). And even in the cases where it might, it would be - as you pointed out - unexpected for the kinds of users that usually fill out “web forms”.
When you’re configuring a server/service, that’s a very different world. Many fields could have defaults, and you wouldn’t want to hard-code those into your config. That is what this is. It’s essentially a web interface for a config file, which often has default values for any field you don’t specify for a variety of reasons. Defaults DO have special meaning here. That’s the whole point I’m trying to make! In that world it very much makes sense. The best way to show it is obviously a matter of personal taste, I actually like (and prefer) the greyed out way for reason I mentioned above.