Add length constraint fields to Text property editor

[JeroenDeDauw]

Add minLength and maxLength fields to TextAttributesEditor with natural language UI
("between X and Y characters") and validation:

• Positive integers >= 1 only
• minLength cannot exceed maxLength
• Invalid values are not emitted to parent

Also fixes Text.createPropertyDefinitionFromJson to include minLength/maxLength.

Manually tested in browser. All code changes thoroughly reviewed by Jeroen and Claude

Co-Authored-By: Claude Opus 4.5 noreply@anthropic.com

[JeroenDeDauw]

Deliberate deviation from UI approach in the numberattributeseditor. To try out if this works better. Original one for numbers:

Now we have essentially the same attributes for text field length, but different UI approach:

This shows they logically go together, esp nice for when validation fails with the min being higher than the max.

@alistair3149 @malberts what do you think of this approach? We could use the same one for numberattributeseditor min and max.

I did a bunch of refining already. Known thing not optimized: small screen sizes.

[JeroenDeDauw]

Done just before full context window :)

[alistair3149]

I like the idea of allowing the user to define the text length constraint, though I am unsure about the UI.
Other than the responsiveness concern, inlining inputs in a sentence have a few issues:

• The input elements can be anywhere in the sentence, due to how different languages work. We can't ensure that it will look good visually.
• When the sentence is wrapped, the spacing between the lines will look weird because there will be excessive spacing between the text because the input elements are taller.

I would suggest using a two column input field instead, it is more common UI pattern and does not have the same i18n concern.

Alternatively, if we plan to add more constraints or make them extensible in the future, having a condition builder UI might be more extensible. Here's an example from Cloudflare:

[JeroenDeDauw]

I would suggest using a two column input field instead, it is more common UI pattern and does not have the same i18n concern.

Do you mean two rows, like we have for min and max of number properties? If not, can you link or screenshot an example?

We might allow more complex constraints via another mechanism at a later point, no need to care about this now.

[malberts]

Some additional concerns:

• (Future) Accessibility. Not sure how screen readers handle this.
• Boundary ambiguity. Might or might not be worse in other languages. "Minimum" and "Maximum" are explicit. In some contexts "between" excludes boundaries (20<x<100).

---

If we're going with a natural language approach, perhaps it would look better if the inputs do not look like typical input boxes stuck in between text.

(Just a rough GIMP edit.)

The "input" should resize according to the number, and be smaller when it's empty.

But then this looks out of place with the rest of the forms.

I assume the natural language approach is not to try to save space.

---

Are there nice examples of UIs doing this?

I might just be old school, but I think I prefer a form with a regular/consistent label+input structure.

[JeroenDeDauw]

Observation: there might not be a single approach without a list of downsides. We also do not need to find the perfect one.

So, we identified a bunch of downsides for the approach in this PR. Are there approaches that have a more appealing set of tradeoffs?

In particular, the original approach, which we have still in use at the number type, does not have a clear spot to show the "min should be lower than max" error, nor does it visually group these fields in any way to suggest there is a relation between them. This might still be overall better than the approach in this PR. Is that what you think?

[alistair3149]

Do you mean two rows, like we have for min and max of number properties? If not, can you link or screenshot an example?

If we're going with a natural language approach, perhaps it would look better if the inputs do not look like typical input boxes stuck in between text.

With the natural language approach, we cannot tell for certain where the input field will end up in for different languages. If the language have a long prefix in the sentence, then the input field might be pushed to second or third line of the text.

[JeroenDeDauw]

Looks good to me

If the rest of the code looks fine, we could merge this and follow up with moving the UI elements

[alistair3149]

The code looks good to me, we can follow up with the UI later like @JeroenDeDauw mentioned.