[color-scale] New `selectable` prop

[DmitrySharabin]

Proposed by @LeaVerou. Lea, could you please elaborate on how this prop should be used and in what use cases?

[LeaVerou]

This would make color swatches focusable and selectable, either by clicking or with the keyboard (and would give them appropriate ARIA semantics). When a swatch is selected, it would fire a suitable event.

My use case was that I want an editable color scale that the user can add colors to, but also select the colors and have them reflected in a <color-picker> for editing, rather than having to enter color codes. Other use cases could be using the color scale as a predefined palette in a color picker, things like that.

[sidewayss]

From a "classic" UI perspective, the swatches would be like radio buttons (single select) or checkboxes (multi-select, if you allow it).

You might also need a selected or selectedSwatch property too. Plural if you allow multi-select.

[LeaVerou]

From a "classic" UI perspective, the swatches would be like radio buttons (single select) or checkboxes (multi-select, if you allow it).

You might also need a selected or selectedSwatch property too. Plural if you allow multi-select.

All good points. The HTML way to specify multiple selection is a multiple attribute, though not sure this makes sense for color-scale.

As I said in another issue, given how much extra code it took to make <color-scale> editable, I’m inclined to split the two and have <color-scale-interactive> (name ideas welcome) that supports editability and/or selection and inherits from <color-scale>.

[sidewayss]

The HTML way to specify multiple selection is a multiple attribute, though not sure this makes sense for color-scale.

Are you sure you want to support multiple selection? Not many use cases for picking multiple colors at once, and here you have the additional limit that they're all in the same scale. I don't know how much multi-select might complicate this implementation. Multi-select adds the functionality of deselecting items. That lets the user leave nothing selected, which single-select effectively prohibits if you have a default selection, or after the user has selected an item. Scrolling means the user can't see everything that's selected at once unless there's a consolidated list of selected items alongside. Some UIs force you to use the shift and ctrl keys to multi-select, others don't. Et cetera. Multi-select tends to be a pain for everyone, programmer and user. But if you need it, you need it.

<color-scale-interactive> (name ideas welcome)

I keep mistakenly thinking it's <color-series> instead of <color-scale>, and you haven't used that name yet. You might also consider an abbreviation for "interactive". Maybe just the letter "i", as in <color-scale-i> (and iPad)? I'm not a fan of long names. Does the name have to include "color-scale"? I can see how it might be confusing not to include it.

[LeaVerou]

Perhaps the interactive versions of things could be <tagname-input> e.g. <color-scale-input>, <color-swatch-input> etc. 🤔

[DmitrySharabin]

Perhaps the interactive versions of things could be <tagname-input> e.g. <color-scale-input>, <color-swatch-input> etc. 🤔

I think it makes sense. As an alternative, <tagname-live>? <color-swatch-live>, <color-scale-live>?

[sidewayss]

live sounds exciting! I like it. input could well be the best choice all around, but it makes me think of HTML <input> specifically, and if you're only using it as part of a picker there's no inputting involved. I'm still stuck on abbreviations, so here are two iffy possibilities: io (input-output) and rw (read-write).

[LeaVerou]

I like the conciseness of "live", but I think it's a bit too vague to communicate purpose here.

but it makes me think of HTML <input> specifically

I think that's a feature, not a bug.

and if you're only using it as part of a picker there's no inputting involved.

There is — just not directly by the user.