mui
[Field][Root]: required attribute via FieldRootContext
Feature request
Summary
Support providing Field.Root with a required parameter that would be added to the FieldRootContext and be accessible to all Field components, specifically Field.Label and Field.Control. Field.Root currently supports passing disabled to the underlying Field Control, and required and disabled feel very similar.
This would allow custom Field.Label components to access the FieldRootContext to display a visual indicator in the label, indicating the field is required, such as an asterisk, e.g. Phone Number *. The Field.Control would also set this the required attribute if it's been set on the FieldRootContext.
Examples in other libraries
useFormControl in MUI supports accessing the required value. I wonder if there's a similarity there?
Motivation
I'm utilizing the Field components to build a HOC FieldControl. This component provides styling for the Field components. One thing that felt odd was in order to display a * symbol for a required field on the label, the consumer would need to adorn both the Field.Label and Field.Control with required.
The workaround would be to provide my own FieldControlContext with a required property. Since I own wrapped implementations of Input, Checkbox and other Field.Controls.
I can easily work around this without Base UI changes. However, in doing so it made me pause and wondered if this was something that should actually be included in the FieldRootContext.
Good find! We should add this as a test case based on the resolution.
This is a lexing issue. We treat text with a valid start character plus a valid continuing character as an identifier. And it seems that we treat variation selectors as continuing characters for identifiers[^1], which makes us lex this as an identifier (which errors since it's undefined).
Here's the relevant source code: https://github.com/typst/typst/blob/2a258a0c3849073c56a0559dbd67ee2effcd1031/crates/typst-syntax/src/lexer.rs#L639-L647 https://github.com/typst/typst/blob/2a258a0c3849073c56a0559dbd67ee2effcd1031/crates/typst-syntax/src/lexer.rs#L1079-L1089
A possible fix could be to assert that identifiers in math aren't single grapheme clusters, but I would want a second opinion before deciding on it.
[^1]: This assert succeeds: assert!(is_math_id_continue('\u{FE01}'))
A possible fix could be to assert that identifiers in math aren't single grapheme clusters, but I would want a second opinion before deciding on it.
I think this is quite reasonable, and would fit in with the changes to the GlyphFragment struct I made in #6336 (if/when that gets merged).
A related case: the single letter test also fails when using something like φ̅ (where a φ letter is followed by a combining overline).
A possible fix could be to assert that identifiers in math aren't single grapheme clusters
Do we do this in other places in the syntax? This feels a bit dangerous not only in terms of comparative performance when lexing identifiers, but also because, in theory, grapheme cluster splitting depends on the Unicode version and may change over time, if my memory serves me well, which could be a bit problematic for the syntax... but it's possible this is a dismissable concern (just wanted to bring it up).
A related case: the single letter test also fails when using something like φ̅ (where a φ letter is followed by a combining overline).
This is tracked in https://github.com/typst/typst/issues/1524.
in theory, grapheme cluster splitting depends on the Unicode version and may change over time, if my memory serves me well, which could be a bit problematic for the syntax... but it's possible this is a dismissable concern (just wanted to bring it up).
I think at least for this specific instance (calligraphic vs roundhand distinction), it is not likely that the clustering will ever change now that it has been adopted, though I think you were referring to the idea of applying this approach more generally, in which case I guess there is a small chance that breakages could occur. A possible solution I think could be to consider any updates to the Unicode version used in Typst to be a potentially breaking change. Consequently, updates to the Unicode version used in Typst could be sign-posted as a potentially breaking change (in the few if any instances where the update does change grapheme clustering)
