You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How to integrate the design library with the template system.
Similar to plugin UI, templates need local styles and scripts that work within any global stylesheet, and do not affect global styles. A template or component should only load assets as needed.
A set of templates could share common styles/scripts to export and import together. Some concepts/terms would be useful, like:
Sets of templates: packages, groups, categories
Sets of styles/scripts: assets, themes, libraries
More than that, we need a shared vocabulary and conceptual framework to define the features of the design library. The template system can then build corresponding interfaces with specific names for data types and functions.
The template editor environment will eventually have a kind of file-system interface, a tree view of folders and items.
Each item can represent any type of editable data, including "template" (set of HTML/CSS/JS, assets, fields/controls); actual or virtual files; or even elements of a design system.
For example, a set of related design tokens can be created and edited together, or sets of components, etc.
Any such folder of items and child folders can be exported and imported as a set.
That means such sets can have different names according to purpose, like a "palette" of colors; a "color library" of palettes; a "theme" of related style definitions, etc.
Ideally, the entire design system should be represented as data.
Design tokens and style data can be used from TypeScript/React, Sass, and HTML templates
Design systems can be edited with a visual user interface, such as settings form or builders
How to integrate the design library with the Fields module, a React-based form fields library. There are some components in common, like Checkbox and Switch.
In the template system, they will be used for WordPress content types and fields, custom post types and database tables, similar to Advanced Custom Fields.
Unifying all fields with the design system means incrementally updating existing styles to use a shared set of design tokens and primitives.
For example, replace literal value 8px with Sass variable $space-2, or #abcdef with $theme-primary-color.
The text was updated successfully, but these errors were encountered:
eliot-akira
changed the title
Integrate with Template System
Integrate with Template System and Builder
Sep 24, 2024
eliot-akira
changed the title
Integrate with Template System and Builder
Integrate with Template System and Block Builder
Sep 24, 2024
eliot-akira
changed the title
Integrate with Template System and Block Builder
Integrate with Template System, Fields, Block Builder
Sep 24, 2024
How to integrate the design library with the template system.
Similar to plugin UI, templates need local styles and scripts that work within any global stylesheet, and do not affect global styles. A template or component should only load assets as needed.
A set of templates could share common styles/scripts to export and import together. Some concepts/terms would be useful, like:
More than that, we need a shared vocabulary and conceptual framework to define the features of the design library. The template system can then build corresponding interfaces with specific names for data types and functions.
See Open UI's research on design systems and components:
https://open-ui.org/design-systems/
The template editor environment will eventually have a kind of file-system interface, a tree view of folders and items.
Each item can represent any type of editable data, including "template" (set of HTML/CSS/JS, assets, fields/controls); actual or virtual files; or even elements of a design system.
For example, a set of related design tokens can be created and edited together, or sets of components, etc.
Any such folder of items and child folders can be exported and imported as a set.
That means such sets can have different names according to purpose, like a "palette" of colors; a "color library" of palettes; a "theme" of related style definitions, etc.
Ideally, the entire design system should be represented as data.
Will be solved with:
How to integrate the design library with the Fields module, a React-based form fields library. There are some components in common, like Checkbox and Switch.
The fields are currently used by Tangible Blocks for block controls:
In the template system, they will be used for WordPress content types and fields, custom post types and database tables, similar to Advanced Custom Fields.
Unifying all fields with the design system means incrementally updating existing styles to use a shared set of design tokens and primitives.
For example, replace literal value
8px
with Sass variable$space-2
, or#abcdef
with$theme-primary-color
.The text was updated successfully, but these errors were encountered: