Editor panel visual system

Requested design

Use the supplied settings screenshot as the visual reference: a floating surface with a large radius, light neutral tint, fine dividers, plain expandable rows, white fields and two-column action tiles. Retain Wookcom blue for actions. Organize site settings as Project, Appearance, Administration and additional tools. Use the existing site metadata, theme and editor settings; no mock switches.

Typography decision

Control values, buttons and primary labels: 1rem (16px with the browser default).
Help, metadata and section overlines: .875rem (14px).
Panel title: 1.25rem (20px).
Line heights: 1.35–1.55; labels wrap instead of being truncated.
Standard fields: at least 44px high. Icon actions: 36px desktop and 44px on narrow viewports. Close controls: 32px.

These sizes are Wookcom design decisions, not a universal standard for website builders. IBM Carbon documents 14px productive and 16px expressive base sizes. The larger 16px option addresses the user's readability requirement. WCAG does not prescribe one default font size. WCAG 2.2 requires text scaling to 200% without loss of content/functionality, normal-text contrast of at least 4.5:1, and pointer targets of at least 24×24 CSS pixels subject to listed exceptions. Passing automated checks does not establish complete WCAG conformity.

Sources consulted (2026-10-25)

Webflow's documentation groups element styling into dedicated layout, typography and other property sections. It does not specify Wookcom's font sizes or certify this implementation.

Implementation and scope

The final shared CSS import defines editor chrome tokens and overrides the compact legacy skins. The section-properties component no longer reimports the old global stylesheet after lazy loading. Modifier controls use shared responsive classes rather than fixed inline 52px numeric fields or inline two-column selectors. One scroll area retains access to long configurations. Mobile docking fits the viewport; design tabs remain in one horizontally scrollable row.

All selectors are scoped to editor application-ui, right-panel or property-panel. Authored text and published widget styles are unchanged. The Appearance shortcuts update theme.primaryColor with native color bindings and editorSettings.showGrid; project naming continues to write existing metadata. The separate admin app shares the visual hierarchy and has its own theme preference. The sales app is unaffected.

Verification

Browser checks cover shared visual appearance, visible text sizes, accessibility checks, 320/375/768/1440px viewports, viewport containment, expandable panels, working grid switch, authored-font isolation, text-size scaling, live property updates, panel dragging, palette persistence, templates and library navigation. Production release also requires a successful build and bundle budget check.

Test network isolation

Editor unit tests reject external fetch, XHR and Node sockets. CI additionally runs them in a separate Linux network namespace with only loopback enabled, so fixture data cannot reach Firebase production even if a mock is missing. The browser panel checks abort every request outside localhost. The developer environment does not grant permission to create a network namespace; the complete suite is therefore verified in isolated CI. Other existing Firestore integration checks continue to use the configured emulators.

Global UX follow-up

The constructor and admin now expose an explicit local light/dark preference. Editor colors are limited to named chrome roots; authored content remains governed by its site theme. Neutral surfaces replace large saturated blue blocks. Groups have bordered boundaries, heading dividers and an explicit open state; design tabs stay on one horizontal row. Modifier headers keep dedicated move and close targets outside the scrollable body. Scrollbar thumbs are translucent and revealed near scrollable edges, keyboard focus, or touch/forced-color use.

Color fields accept supported hexadecimal/RGB alpha formats and transparent backgrounds. Opacity changes the color only. Native button backgrounds can be linked to the site's CSS primary-color variable, and the Settings action can explicitly apply that binding to existing native buttons. Changing a brand color preserves independent custom colors. Browser checks verify persisted transparency, live binding, dark-mode isolation, readable numeric alpha and saved background palettes. Legacy CSS color values are preserved without being added to a restricted recent-color palette.

Retired external component assets and dead UI modules are documented in docs/custom-component-migration.md; stored custom markup has a single compatibility adapter. Required source-license notices remain.

Follow-up corrections

Expanded settings and language sections have 16px body insets. Color fields are flat, with one clickable alpha swatch; layer names receive their full row and action controls a separate row. Link underline options are below their color controls. The object toolbar and library/template chrome use the chosen theme. Long panels adjust their scrolling body height while dragged so the grip follows viewport pointer coordinates.

Publication validation accepts the editor's saved previousWidth bounds with strict finite numeric validation. Promotions use a separate owner-configured button and read-only public API; only Publicar starts publication. The promotion dialog isolates editor keyboard shortcuts.