A couple of interesting components have emerged from the Typography Tool prototypes:
#65

(GIF: Demo'ing the PresetInput)

The UnitInput and PresetInput (which uses UnitInput under the hood).

We're not sure if they are the correct/final designs (as far as UI, UX, and interactions are concerned), but they're incredibly promising!

There were several breakthroughs in prototyping and designing this component!

Link to Demo
https://g2-components.xyz/iframe.html?id=designtools-typographytools--plus-minus-inline-truncate&viewMode=story

Note: These components aren't perfect... However, they work well enough to help test out and validate UI/interaction ideas.

🚗 Powerfully Compact

This single input does a lot! It's really interesting to see a bunch of features (below) compacted into a single multi-purpose interface. Especially if this interface is to be used in many many places (as Design Tools evolve and improve)

Features include:

• Unit parsing
• Unit selection
• Preset selection
• Typeahead: Autofill for preset
• Typeahead: Autofill for units
• Drag to change
• Step "jumping" (when holding shift)

Figuring out how to even construct this UI and handle the events has been an interesting challenge!

✅ CSS Prop Validation

Fun UI aside, we think this is one of the biggest insights! We figured out a way to validate if a value works for a specific CSS property.

Value validation (and reset handling) will be incredibly important in the Design Tool layer, especially as more controls get added that (ultimately) render out CSS style properties.

For example, let's say we want check for the height CSS property.

It can accept a wide range of very similar values:

10px, auto, 5vh, 0, etc...

The tricky thing with values like 0 is that it could be a number (0) or a string ("0").

As you can see... lots of variations.

To throw wrench (🔧 ) into everything... negative values are acceptable CSS values... but not for height.

(omg... what about things like calc? Maybe we can ignore calc for now... but still!)

This validation technique takes care of it in a reliable way, using the browsers CSS's engine under the hood.
Not quite CSS Typed Object Model... but close (and compatible with browsers).

This has been built into UnitInput, with a component API that looks like this:

<UnitInput value={value} onChange={handleOnChange} cssProp="height" />

Passing in the (camelCased) cssProp adds the validation step for you! ❤️

⏪ Change, Reset, and Overall Value Handling

At the moment, value serialization + reset handling is quite tricky in Gutenberg. It is often hard-coded ad-hoc logic, which is difficult to repurpose. We're starting to move some of this into the component/design tool layer, which is great.

I believe this should be the direction we should be going in 🙌 .

That means the low level components (like a base TextInput) must have support for multi-state changes (like reseting a value) in addition to providing the ability to adjust the value (like 10 to 10px) as it is "processed" for that final onChange send-off.

After that, larger components (like UnitControl) and Design Tools can create, enhance, and extend functionality on top.

Ultimately, this would mean that a lot of the common fiddly (very fiddly) logic will be abstracted away into the components/tools layer, allowing for Gutenberg Block components (e.g. core/cover) to be MUCH more streamlined - allowing for a greater focus on rendering into the page/site, rather than managing attribute changes.