Support other format for string and integer: color and range

+1 for this! These are common and important fields in the context of a page builder.

I edited the code example for the color format, where the default colors palette should probably be an enum and not several default values.

Also not sure which data format would be the best adapted for named steps in a range.
Enum won't bet enough, we need key/value options.

<label for="tempB">Choose a comfortable temperature:</label><br />
<input type="range" id="tempB" name="temp" list="values" />

<datalist id="values">
  <option value="0" label="very cold!"></option>
  <option value="25" label="cool"></option>
  <option value="50" label="medium"></option>
  <option value="75" label="getting warm!"></option>
  <option value="100" label="hot!"></option>
</datalist>

Working on it.

Given https://git.drupalcode.org/project/experience_builder/-/merge_requests/9..., I'm hoping @larowlan can point us in the right direction — I'm currently flailing to find what I'd swear is a subclass of \JsonSchema\Constraints\FormatConstraint being added by him to XB!

You're off to a great start here! :D

Asked a few questions, and asked @larowlan to provide you with a crucial pointer, because while this may be what is a reasonable expectation from a HTML POV, neither "color" nor "range" are part of the JSON Schema spec. That makes the SDC integration nontrivial.

(Added this to 📌 [SPIKE] Comprehensive plan for integrating with SDC Active . Tangentially related: ✨ Enable contrib to register `pattern` and `$ref` shape matches for prop shapes Active .)

This definitely still needs test coverage.

Yes it would be great if @larowlan can point how to approach for the SDC integration by customizing the validation logic.

Let's get this moving forward again — sorry for the long silence here 😅

@heyyo is right in #4, where he wrote:

Enum won't bet enough, we need key/value options.

… but fortunately that literally just landed in the past 12 hours in Drupal core 11.2: ✨ Enum vales do not have translatable labels Active . Core change record: https://www.drupal.org/node/3519574 → .

And we're making XB leap ahead of core in 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active .

The scope here is not clear: all we have as expected scope is @lauriii's enthusiasm in #2 😅

+1 for this! These are common and important fields in the context of a page builder.

First step is to clarify that.

What's interesting is that this issue seems to start not from prop shapes (types of data), but from HTML5-native input widgets: input[type=color] and input[type=range].

The requirements/product expectations are very unclear here. Rewrote the issue summary to get clarity. This needs input from @lauriii before this is actionable — the broadest vs narrowest interpretations represent very different amounts of work.

I'm slightly concerned implementing capability of things like HTML5 native widgets before we have component variants, templates, styleguides and themes - the "styling/theming" part of XB ready. There's risk of setting the expectation and practice of having html/styling stored alongside the content at the individual Component instances on Nodes.

While I agree that we should support this eventually, I question whether this is a beta/stable blocker or even a priority for this time?