TheGame icon indicating copy to clipboard operation
TheGame copied to clipboard

Allow new work to use HTML / CSS modules rather than Chakra UI

Open dysbulic opened this issue 2 years ago • 7 comments

What would you like to be added?

I've been doing a couple sites starting from scratch & I like plain HTML plus PostCSS processed CSS modules about twenty times more than Chakra.

I propose that new work be allowed to develop in vanilla HTML / CSS and we can progress toward v2 of the design system using those technologies rather than Chakra.

Why is this needed?

HTML is the work of thousands of hours of some of the most talented developers in the world to produce a set of tags that succinctly and expressively describe the structure of documents. Having to translate everything into Chakra-speak prevents us from leveraging that work.

Not to mention that browsers are advancing rapidly & new tags / styles are gaining significant support almost monthly.

I like the "separation of concerns" philosophy where the tags of the page describe the logical structure of the document while the styling covers appearance. CSS modules as well as PostCSS features like nested selectors help users target and reuse styles significantly.

dysbulic avatar Jan 17 '23 21:01 dysbulic

A counterpoint:

Apology
I am not totally sure how React sites deal with CSS (a big styles.css file that covers the whole site, or generated [inlined?] styles that are for a specific page only?).

Declaration
I use (and prefer) vanilla CSS / SCSS / semantic HTML on my personal sites.

The actual counterpoint
Chakra is a reasonably solid design system, it's easy to learn, and the documentation is plentiful and useful.

Would a MetaGame design system be as easy for new Builders to pick up on and use? (especially w/r/t documentation)

HHH-GH avatar Jan 20 '23 03:01 HHH-GH

I am not totally sure how React sites deal with CSS (a big styles.css file that covers the whole site, or generated [inlined?] styles that are for a specific page only?).

With CSS modules you would have a CSS file with contents like:

.table {
  border-collapse: collapse;
}

Then in your JSX file you'd have:

import styles from '../styles/table.module.css`

Then in the scope where you want the styles applied:

<table className={styles.table}/>

The import will generate a unique class name for the given style.

I use (and prefer) vanilla CSS / SCSS / semantic HTML on my personal sites.

I'd really like to be deepening my understanding of HTML as I do this work. I've been learning ARIA and how to structure documents for assistive technologies. I can't leverage any of that through Chakra.

PostCSS is like SASS, but it transpiles emerging CSS standards to something accessible to more browsers.

Chakra is a reasonably solid design system, it's easy to learn, and the documentation is plentiful and useful.

Would a MetaGame design system be as easy for new Builders to pick up on and use? (especially w/r/t documentation)

We're using very little of Chakra as a design system aside from the units. Most of our coloring and styling is custom.

Ideally the bulk of components would be in design system to display data structures built in the app.

What I'm still uncertain about is how to support flexible theming. My current guess is a combination of CSS variables & dynamically importing stylesheets.

dysbulic avatar Jan 24 '23 05:01 dysbulic

I'd be up for trying it out.

My current flow is SCSS files for separate components that are imported into a main.scss file, which is used to produce a minified version of everything. (In some setups I've got PostCSS in there to add in prefixes and what-not for older browsers)

For theming and spacing units there are SCSS variables and loops to output class names.

If I get what you mean here, instead of ending up with all the CSS in one file the different components are imported in each page as needed, and each page would have its own CSS file?

HHH-GH avatar Jan 25 '23 04:01 HHH-GH

My current flow is SCSS files for separate components that are imported into a main.scss file, which is used to produce a minified version of everything.

Yeah, so it'd be that except CSS modules. The main extension I like is nested selectors. level4 looks like a promising collection of plugins.

For theming and spacing units there are SCSS variables and loops to output class names.

CSS has variables, but not loops. I get where they could be handy. At the least, we could use advanced-variables.

If I get what you mean here, instead of ending up with all the CSS in one file the different components are imported in each page as needed, and each page would have its own CSS file?

I'm still contemplating what the files layout should look like. In general, I do one module per component. I think there should be color and spacing variable definitions though. Maybe steal some ideas from Tailwind and leverage composition to combine styles within the CSS structure, so there's less importing in the HTML.

I think there's room for a custom function, maybe accessed via a hook, for managing styles. Did you happen to catch my comment on the initial unstyled page we're seeing currently? One of the big goals would be to avoid that.

dysbulic avatar Jan 25 '23 06:01 dysbulic

The nested selectors and advanced-variables stuff look like they would cover the loops/vars of SCSS.

What I'm seeing with the unstyled page there is that the main styles are being loaded via js so they don't block the render of the page (and so there's something on the screen as soon as possible), but the problem is that the something-on-the-screen-more-quickly is mostly unstyled, which means that regularly-loaded render-blocking CSS files are actually what we want?

The page I linked there looks like it shows a method to inline the critical styles for each page (as part of the build), which I think would solve the problem. Will try it out when I get some free time.

HHH-GH avatar Jan 25 '23 11:01 HHH-GH

There's also the fact that CSS-in-JS components like Chakra aren't going to work with the new Next server components. The components need to be streamed, and Chakra needs to insert something in the head (the style) and body (the compponent) at the same time which breaks those streams.

dysbulic avatar Jan 31 '23 04:01 dysbulic

This has been open for a year, and unfortunately the issue here is Chakra is so embedded it would take months to swap it out completely. If we are to change the development standards it would need to be enforced on the Review level.

Additionally CSS itself is a nightmare to maintain and manage, modules help but add a lot of files to the already big bundle.

We could use Tailwind, as it's similar enough to Chakra that our devs can easily pick it up.

Thoughts @dysbulic, additionally this should be a contribution guide as opposed to a Github Issue

0xSero avatar Jan 01 '24 11:01 0xSero