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?

This is something that would be utilized for overrides; not for full on styling the site. The one example where I could have used this was applying a colored filter to an image; it just isn't a great experience to manually enter a color. The lack of having this feature to provide these types of overrides has come up in several conversations with users. There's a lot of capabilities that will need to be built on top of this to fully leverage this but we'd always have to start somewhere. This would become a lot more useful once we also have 🐛 DX & authoring experience: for SDC+code components, the example is treated as the default, may not be desirable Active .

That said, the lack of thought for design tokens is something that concerns me a little bit. I was thinking that we may want to implement this with https://www.drupal.org/project/color_field → but it might be that we need something more bespoke in order to be able to utilize design tokens in there.

At first I was thinking that there wouldn't be harm in providing this as a stepping stone but it seems that adding support for design tokens could become more painful if we do this first. Removing this as a beta blocker for now.

On a second thought, I'd assume we'd have to implement something around the field storage for the design systems regardless because design tokens wouldn't be limited to colors. We would not want to implement this to each field type individually. But it might be that there's still enough unknowns to warrant not working on this. Providing a freeform color selection isn't that useful for many use cases; you'd want to limit the options. But you probably do not want to define those colors on component by component basis so we'd have to design how we'd want those color options to be defined.

Stepper we may want to actually design the widget more properly. It would be great to split that to its own issue so that we have dedicated issues for both.

the lack of thought for design tokens is something that concerns me a little bit

💯

Very grateful for @f.mazeikis raising #14 — I was kinda blindly executing in #13 and following orders 😶‍🌫️