Setting text-prefix-based AccessKeys as the default behavior may lead to unexpected results for users who are unaware of this feature.

[harry-xi]

The current design relies on character prefix recognition for AccessKey, and the Content method has a default value of accessKey = true. If an unaware user passes user-input text directly to the Content method, this could lead to a bug in certain edge cases, and it would be difficult for the user to detect this bug through testing.

[al6uiz]

Thanks for the feedback.

This behavior is intentional and documented.

Content(string text, bool accessKey = true) is a convenience overload for text captions. Its XML documentation explicitly states that accessKey defaults to true, and that _ prefixes mark access-key characters.

This default is based on common desktop GUI conventions. In labels, buttons, menus, check boxes, and similar static captions, _ is more commonly used for access keys than as a literal character.

This is also consistent with WPF and Avalonia. In default templates for controls such as Button and CheckBox, string content is commonly presented through a ContentPresenter with RecognizesAccessKey enabled, so access-key parsing is the default behavior for those caption-style controls. If a different behavior is required, it can be overridden in the control template by changing ContentPresenter.RecognizesAccessKey.

MewUI also provides overloads for this distinction:

• Content(Element content) for explicitly supplied content elements
• Content(string text, bool accessKey = true) for text captions with access-key support

it would be difficult for the user to detect this bug through testing.

I do not think the possibility that a caller may be unaware of a documented parameter is enough reason to change the default. The behavior is explicit in the overload signature and XML documentation, and the API provides a direct opt-out path for literal text:

Content(text, accessKey: false)

Alternatively, callers can provide an explicit content element instead.

This may be a matter of API design preference, but for MewUI the current default is a valid choice based on the intended use of this overload and common desktop GUI caption conventions.

If there are concrete cases where literal underscore text is commonly used in the Content property of these controls, I am open to reviewing them. Otherwise, I would keep the current default.

[harry-xi]

I don’t think there’s anything wrong with this design; I’m just concerned about whether the documentation is clear enough. There’s really no need for us to make any changes for this extremely rare edge case.