Feature Recommendation: Stylebook Classes Tab Redesign

OVERVIEW

I LOVE Greenshift and Greenlight, but the current Classes tab in the Stylebook, in my opinion, needs a lot of work to be useful. It surfaces global component classes through large card previews. While functional, this approach makes it difficult to scan a growing class library, and there is no way to view or directly edit the underlying CSS which is something developers, like myself, expect as a baseline. This recommendation proposes four improvements that bring the “Classes” tab closer to how pro developers actually think about and work with stylesheets.

PROPOSED CHANGES

1. Simplified Class List (Mockup 1 Here)

Replace the current block-based layout with a compact flat list. Each row displays the class name and its type (e.g. “Regular”, “H1”, “A”), with a remove action. This reduces visual noise and makes it faster to scan and locate a specific class, especially as a project grows.

2. Click-to-Edit with Component Preview (Mockup 2 Here)

Clicking a class in the list opens the existing sidebar editor (no change to the editing experience), but also loads a live preview of a component using that class in the main content area. This gives developers immediate visual feedback while tweaking styles, without having to navigate to a page where the class is in use.

3. Show CSS Code Per Class (Can be seen in mockup 1 Here)

Each class row gets a “Show CSS” toggle, consistent with the existing Local Styles behavior. Expanding it reveals the raw generated CSS for that class in a read-only or editable textarea. This alone closes the biggest transparency gap — developers can see exactly what CSS is being produced.

4. Edit All Classes as CSS (Mockup 3 Here)

A top-level “Edit as CSS” mode exposes all global classes as a single flat stylesheet. The element-type categorization (Regular, H1, H2, A, Section, etc.) would be collapsed. The editor would simply be a stylesheet where each class is a standard CSS rule block.

Adding a new rule in this view registers it as a new global class. Deleting a rule removes it. The editor should validate class names against existing registered classes and warn on conflicts. I would imagine there may need to be additional error-checking on save to make sure that the changes are compatible with Greenshift’s/Greenlight’s block editor controls.

Note on element-type bucketing: Greenlight does not enforce which element types a class can be applied to, which means the existing categorization is purely organizational. Collapsing it in the CSS view eliminates unnecessary cognitive overhead and matches how developers think about a stylesheet.

IMPLEMENTATION NOTES

• The “Edit as CSS” view does not need to replace the visual sidebar editor. Both can coexist. The CSS view is an alternative entry point for developers who prefer working directly in code.
• The Show CSS toggle in item 3 could share the same code path as the “Edit as CSS” view, just scoped to a single class. This already exists for Local classes under the “Show as CSS” option.
• If a class is edited via the CSS view, the visual sidebar should reflect the updated values on next open, assuming the property maps to a supported control.
• New classes added via the CSS editor would need a default element type assigned (e.g. “Regular”) since the underlying data model presumably requires one. This could be automatic or prompted with a simple dropdown on save.

SUMMARY

The four changes work together to make the Classes tab feel less like a page builder tool and more like a proper design system interface. Developers get visibility into generated CSS, faster navigation through a flat list, live previews while editing, and the option to work directly in a stylesheet when that’s the faster path.