eliot-akira
commented
8 months ago Thanks @juliacanzani - Great, we can get started on planning and implementation.
(Looks like the bayside-features repo on Bitbucket is not accessible to me, the link returns 404 not found. EDIT: Nevermind, I was logged out, I see it now.)
The feature sounds well-suited for this new Framework module, which is meant to be included in all Tangible plugins eventually. But we can also create a new repository for it instead, to make it easier to work on.
Recently I prepared a tool called git-subrepo that finally achieves what I wanted with the code organization of modules shared across plugins. Any module can be developed in its own repository, synced to/from a parent module, and can contain child modules.
It should help with managing parallel/collaborative development, and keeping issues and pull requests organized for each module separately, instead of all in one place like Gutenberg which has dozens of modules (each published as its own NPM package).
One thing I'd love to figure out together is how to set it up so that it's easy to develop and contribute, not only for devs but all team members. Having a Git repo is one of the few requirements - it can be edited directly on GitHub or using a GUI app, but that can still get technical, like resolving possible merge conflicts.
Another aspect is the compilation and bundling of CSS/Sass and JS. That step requires installing Node.js and running the build command in the terminal.
These complexities limit who can contribute to development, and create a divide between devs and designers so that every change requires a request and response, instead of a designer just making changes as they see fit - that immediacy ("without mediation") and tight feedback loop allows for much greater momentum. I wonder how we can reduce the friction and learning curve.
Yes, automatically prefixing CSS classes and variables would be valuable for encapsulated styles that work on any site without conflict. Using PostCSS means we'll definitely need a build step. Maybe we can try with plain CSS + PostCSS plugins, which can achieve most of what Sass can do.
component-ize the styles so that they can be selectively loaded
Great idea, I'd love that. I've been thinking something similar for the Tangible Fields module, to allow loading only the field types as needed, instead of all fields' scripts in a single big bundle like ACF does. It would be easier to do this if we design it like that from the start. We'll probably prepare a "core" bundle with common/shared styles that all components can depend on.
settings panel to manage colours and other aspects
Right, this is getting close to what we've been discussing for the Template System. It can store such style variables (palettes, themes) as JSON, and generate CSS/Sass variables for use in templates. Ideally we can save duplicated effort by designing common features as a Style Engine.
We can get some ideas from Gutenberg, where they're working on a Style Engine to be merged into core.
- Gutenberg: Style Engine
- Block editor styles: initiatives and goals
- WordPress/gutenberg#42028
Maybe the simplest way to get started on this is to create a new repository with a minimum setup to bundle CSS/JS, test it on a static page and/or run it as its own plugin. When it's ready, it can be easily included as a module in the Framework.
How about we call it a Design System module, where we will eventually develop all the features for a "design system builder"?
juliacanzani
I've been tinkering with an idea to create a frontend style framework with the goal of:
@nicolas-jaussaud and I have chatted about it a bit, he thought it would be cool if this could be implemented as an NPM module, and had some suggestions for postcss plugins that could help us with prefixing: https://www.npmjs.com/package/postcss-prefixer, https://github.com/ryuran/postcss-variables-prefixer, https://github.com/postcss/postcss-simple-vars
You can see an example of an early version of the framework in use in a functionality plugin for a client here.
I think we will want to component-ize the styles so that they can be selectively loaded as they're needed: buttons, tables, tag pills etc. and it could make sense to pair this with a React component framework eventually.
I can also think of some interesting potential enhancements: perhaps colour palette shades could be programmatically generated from a base colour, or users could opt out of parts of the framework and use functional/layout styling only.
Let me know your thoughts @eliot-akira!