eliot-akira
commented
7 months ago @juliacanzani @nicolas-jaussaud
There are many aspects we could discuss about the architecture and features of the Design module. The current initial project setup is just a rough draft, and anything can be changed or removed. A few thoughts I had while preparing..
The article proposing standardized design tokens in WordPress is good reference. It takes lessons from the trends of atomic CSS and Tailwind, in particular the use of utility classes, variables, and naming conventions. This approach fits well with my own Sass practices across various projects over the years, and from what I've seen in open-source projects - including the Bayside Features example.
One thing about that example, at least for my own use case, is that it outputs a stylesheet with many unused CSS variables. WordPress core does this now too. Personally I'd rather use Sass variables, which disappear after compilation if they're not used. Ideally, I'd love it if the Design module supported this approach. And other ways to load features selectively.
About having a settings panel to manage colours and other aspects of UI styling - in order to achieve this, the CSS/Sass variables need to be dynamically generated from the settings.
With the current project setup, the final CSS bundle is built by Tangible Roller, the same way other Tangible plugins and modules do. It might be more flexible to use the new CSS engine (TangibleInc/template-system#101), which can dynamically compile things in the browser, for example when saving within such an admin settings panel. That way, the CSS bundle can be regenerated when someone changes the variables.
An interesting aspect of the current setup is that it uses wp-now to quickly start a local WordPress site for development and testing.
Unlike wp-env, which is what WordPress/Gutenberg projects use - and what we've been using for plugin testing, wp-now does not require installing Docker. It runs on PHP-WASM from the WordPress Playground project, so it only requires a JavaScript runtime such as Node. I like that it's self-contained and much quicker to get started. If this approach works well, I'll incorporate it more into our workflow, plugin/module setup, testing, etc.
About encapsulating our plugins' styles - in addition to prefixing classes and variables, which will protect users' styles from our own, we need a way to selectively reset styles, to have a consistent starting point for styling. This will ensure that elements are styled properly in any context, such as the WordPress admin screen, page builders, frontend themes.
I've included a reset stylesheet based on Tailwind's. As you can see from the HTML5 test page, it's quite a strong reset compared to other popular solutions like normalize.css, so we'll likely need to adjust it for our purposes.
From experience I know we need a strong reset like this, to protect against overly eager CSS styles, for example Beaver Builder's crazy selector like .fl-builder * > *. This is a common problem with CSS as a language, the "cascading" aspect, related to the problem of inheritance in object-oriented programming; in contrast, using a reset + utility classes ensures that effects are atomic and isolated.
For now, the Design module is described as providing "building blocks for creating design systems". But aside from general-purpose building blocks, we'll be creating a specific design system for Tangible plugins. So eventually we'll need to draw the line, to separate the base layer with generic parts that users can import to create their own design systems.
About "making it easier for users to restyle" - I love that aspect of libraries like React Aria, the usefulness of "headless" templates that are completely unstyled, with accessible patterns and structures to build your own styled components.
juliacanzani
Create a frontend style framework with the goal of:
This could be implemented as an NPM module
PostCSS plugins that could help us with prefixing: postcss-prefixer, postcss-variables-prefixer, postcss-simple-vars
Early version of the framework in use in a functionality plugin for a client here
Component-ize the styles so that they can be selectively loaded as they're needed: buttons, tables, tag pills etc.
Pair this with a React component framework eventually
(Description based on TangibleInc/framework#1)