CSS Strategy #7
Replies: 4 comments 1 reply
-
|
With the spirt of the project to keep things as close to the standards as possible, I would vote for |
Beta Was this translation helpful? Give feedback.
-
|
Well, at the end of the day the complexity for the convenience of either solution has to come from somewhere. While PostCSS + Tailwind is effectively an optimizing compiler just working on narrowing a massive CSS file (all the Tailwind classes) based on matching on class names in input files, CSS Modules requires a bit more work / orchestration under the hood. As CSS Modules is just a specification (with an implementation for webpack and PostCSS) the general gist as I understand it, is that an implementation would need to handle the following:
So basically given something like this import styles from './header.module.css';
export default class Header extends HTMLElement {
connectedCallback() {
this.innerHTML = `
<header>
<h1 class="${styles.heading}">Welcome to Greenwood!</h1>
</header>
`;
}
}
customElements.define('app-header', Header);.heading {
color: blue;
text-align: center;
}The outcome / output would look something like this when it is all said and done:
That said, I've created a draft PR ( #11 ) to start playing around with it and made some decent progress after only hacking on it for a few hours, so definitely take a look and see what you think. So far this has involved leveraging three ASTs / APIs for parsing content including html-parser, css-tree, and acorn (+ acorn-walk), which are technically already deps of Either way, this will definitely be a plugin so if users feel they are OK with opting into that overhead for that workflow they can, which is more or less the same investment as using our PostCSS plugin + Tailwind, so low friction whichever path you take. 🤞 Will plan to review / demo during our next weekly meeting. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps this could more align with the vanilla or CSS Modules approaches, but it might be cool to leverage Open Props as our (sub) atomic utility library? |
Beta Was this translation helpful? Give feedback.
-
|
Final strategy documented here - ProjectEvergreen/greenwood#1234 |
Beta Was this translation helpful? Give feedback.
-
|
Ok, we're locked in, here goes nothing! 🤞 |
Beta Was this translation helpful? Give feedback.
-
Overview
Would like to explore possible CSS strategies for the new site, with a few options off the top of my head, assuming light DOM rendering
Some specific goals / requirements I care about are:
<style>blocks, as this can interrupt HTML parsing and lead to greater FOUCCSS Modules
There currently isn't a mechanism for CSS Modules with Greenwood, but I would certainly be open to developing it, as I like the authoring experience of vanilla CSS, but with binding / co-location to its usage.
Tailwind
I've used Tailwind with a couple projects and works really well with Light DOM, statically pre-rendered custom elements. Greenwood already has support for PostCSS so this is definitely a good option as well.
Vanilla CSS
This option could be ok, but the part I'm concenred about is co-location, as the options would have to be:
The problem with the second option, is if we have something like this
Which would leave a bunch of
<style>tags throughout the HTML, which wouldn't be as performant, and would cause constant reflows / repaints on load as the HTML parser keeps hitting these tags, and could lead to a greater impact of FOUC.Beta Was this translation helpful? Give feedback.
All reactions