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.
[x] #9
See Open UI's research on design systems and components:
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
Import/exported from design tools
Will be solved with:
[ ] #6
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.
[ ] #8
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.
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
8pxwith Sass variable$space-2, or#abcdefwith$theme-primary-color.