I’m curious, why is that?
jonas_h
hauleth
You can use :user-invalid then. Doesn’t really matter, I was talking about idea rather than particular implementation there. Main thing here is that it forces you to use aria-invalid attribute instead of custom class, which will help with a11y, and will leave classes and stuff for sensible data.
4
shahryarjb
Because there are many components about +90 components and it needs huge time and efforts to convert all of them to Pure Css!! and we are just 2 persons that are working on the them 
2
seeplusplus
At the risk of being off-topic, I’d be curious to know what your setup looks like using Rsbuild. On a personal note, I was trying to fork the esbuild package to turn it into something that could run/manage rsbuild installations. Would this be something you would find valuable?
1
kokolegorille
My config looks like this…
I deactivate hmr and livereload because Phoenix does that instead
import { defineConfig } from "@rsbuild/core";
import { pluginReact } from "@rsbuild/plugin-react";
import { pluginSass } from "@rsbuild/plugin-sass"
const path = require("path")
const isDev = process.env.NODE_ENV === "development";
export default defineConfig(({env, command}) => {
console.log("rsbuild CMD: ", command, " ENV: ", env, " ISDEV: ", isDev)
return {
dev: {
hmr: false,
liveReload: false,
},
source: {
entry: {
app: "./js/app.js",
},
},
tools: {
htmlPlugin: false,
},
output: {
filename: {
js: "[name].js",
css: "[name].css",
},
distPath: {
root: path.join(__dirname, "../priv/static"),
js: "js",
css: "css",
font: "fonts",
image: "images",
},
cleanDistPath: true,
charset: "utf8",
copy: [{
from: "./static",
to: path.join(__dirname, "../priv/static")
}],
externals: {
jwplayer: "jwplayer"
},
},
plugins: [
pluginReact(),
pluginSass(),
],
}
})
4
kokolegorille
BTW I do not have a lot of dev dependencies, only
"devDependencies": {
"@rsbuild/core": "^1.5.2",
"@rsbuild/plugin-react": "^1.4.0",
"@rsbuild/plugin-sass": "^1.4.0"
}
Having an esbuild package, is a way to fix the version…
In the past sass broke a Phoenix version. Nothing to do with Phoenix, nor Webpack… it was sass and because of this a lot of time has been spent for nothing
I am not sure a rsbuild package is required, I usually do npm i -D and use the current version of the dev dependencies
2
garrison
I’ve written about this before on here, but I don’t use Tailwind. I wrote a small library that extracts style tags from HEEx components, scopes them in the HEEx (by adding an attribute), and then scopes all of the selectors and compiles them into an output CSS file.
I wrote this code ages ago and it remains by far the most utility I have ever managed to extract from one stupid hack. It’s literally just a mediocre CSS parser/generator (which I desperately need to rewrite from scratch) and a macro/compiler that hijacks the HEEx and rewrites it with a stupid regex because I was too lazy to parse the HTML.
And yet, despite that, it’s been essentially the perfect solution. Here is what some of the components look like. I use nothing but vanilla CSS (with a shorthand $variable syntax because I am not writing var(--variable) 10,000 times). I can always use the latest CSS features and never have to worry about framework churn.
But I also inherit all of the best parts of Tailwind. Styles are co-located and scoped to their components. Dead styles are easily eliminated due to the co-location. Composability is not an issue due to scoping. There is no jumping around, and no worrying about name collisions.
The final advantage of Tailwind, perhaps the biggest, is that you get an extensible design system out of the box. So I built that too! The defaults are here, but I designed it to expand the design system recursively. Here’s my default. It even has themes! I then have app configs which in turn extend that one.
I’m used to things having tradeoffs but to be totally honest, for me, this remains the uncontested perfect solution. I have run into no meaningful problems with this approach.
I think I will clean this up and turn it into a real library (yes this is like the 10th time I’ve said this) once macro components ship as they will make it much less hacky. I’ll probably extract the CSS parser/generator to a separate library and maybe try to make it composable (like PostCSS or something, so people can minify etc if they want).
11
jam
I use vanilla CSS with CSS variables. I agree with the points above on Tailwind and think it’s an unnecessary abstraction. I hadn’t considered the Would be great to see Phoenix move to scoped CSS and make tailwind an opt-in.
Sounds like a great lib. I’d happily be a user. I wonder if Hologram could take advantage as well.
4
garrison
The thing about Tailwind is that it’s a legitimate solution to these problems and so from that perspective I want to defend it.
But on the other hand the implementation is just totally hideous and degenerate, and scoped CSS is so much better in this regard. I really cannot advocate for that approach enough.
Noted!
Actually there is a good argument for the design system parts working across frameworks here, since a design system is often shared across an org rather than just an app. Even in my case I am reaching the end of the research phase for my JS frontend framework (if you remember my posts on that) and I’m going to start the implementation shortly. I will definitely be finding a way to bring corp_style along for the ride (the joys of controlling your own abstractions) as I don’t think I could live without it at this point!
Interop would be nice as I intend to keep using LiveView for some things even though I’ve really been feeling the limitations lately on the app side.
1
