should radio fields show tags that are set to an "invalid" value?

[tyrasd]

For checkbox fields, we do show the value of the respective tag in the case where it does not fit to one of the defined values (typically yes or no). This is useful for tags where there are special values that are interpreted basically the same as yes, but have a slightly different meaning like covered=arcade

Similarly, this can help for cases where the tag has a typo, or otherwise invalid/outdated value:

---

For radio fields, however, the behaviour is different: when a non-matching value is present, the field is rendered as if the tag was not present at all. In the screenshot below assume the feature is tagged with a hypothetical tag lifeguard=outpost, but it would also look like this for a tag with a typo lifeguard=Tower.

There should be at least a visual representation that the tag is present, but does not match the expected values (e.g. as a grayed out state and a corresponding tooltip / hover text).

Alternatively, we could do this like the check fields: Just add the unexpected value as a temporary option, like in this mock-up:

[tordans]

Alternatively, we could do this like the check fields: Just add the unexpected value as a temporary option, like in this mock-up:

I think this is the best option. IMO the fact that we render whatever is there in those cases is important and should be the same for radio fields as for the other fields.

For all those, we could look into how to better explain that this is a raw tag vs. something from the preset. For the dropdowns we change to the monospace font and change the color; maybe we can adopt this style here? But just changing font type (and color) might not be enough. The quote also help but are very subtle as well. Maybe we should be more verbose and add a outpost (custom value) pill kind of label next to the text in addition to the font change?

In any case, we can treat the how as a separate topic/PR from the "if" and for the if I am all for showing it…

[matkoniecz]

Just add the unexpected value as a temporary option, like in this mock-up:

+1 to that, not perfect but if we have unknown value we cannot handle it significantly better

[matkoniecz]

BTW, this feature got more important as result of openstreetmap/id-tagging-schema#2081 and more such changes being planned.