In this article, I explain what I think is the fundamental problem that’s not addressed by popular CSS solutions.
8 Likes
Thank you for pointing to the elephant in the room 
1 Like
Did you mean a stylish elephant by any chance? 
4 Likes
Sorry, but I don’t get it. The same solution that applies in plain CSS will apply in elm-css, tailwind or css modules. I still need to know css to arrive at the best solution. I don’t see the abstraction you are talking about.
I think that is what he is saying - there is no abstraction with elm-css, but you have to do the extra work of typing your CSS. Work for little gain.
Personally I think it is worth it, especially when you start to write Elm code that generates various CSS structures, for font scales, grids and media queries. Even the typing is worth it in my view, as it helps to avoid CSS typos that would be silently ignored otherwise.
My main concern with elm-css is that it can be slow. For that reason I avoid doing inline CSS with it, except in places where something really needs to be calculated at runtime. Instead I used Css.Global and named classes. I might have many Css.Globals defined accross a project, but I gather them all up and put them at the top to ensure the browser knows all the CSS before getting to work on the HTML.
Elm-css is not supposed to catch the kind of traps that you describe.
Elm-css generates Stylesheets, because selectors have no other apis. As we can’t from the dom easilly say “change the background on :hover”, without all the fuss. I think I’ve considered all the options like you. At first you think that you only need “pseudo-selectors”, but then you realize that media-queries could be nice, and pretty quickly you end-up generating a Stylesheet anyhow.
Architecturing styles is very hard… I don’t think that even after 20 years of CSS I’ve been able to grasp a perfect recipee. My best advice is to ensure that dead styles don’t find their way into production (elm-css does it, very elegantly). Beyond that, I don’t think there is a silver bullet.
I am curious what you mean by this. Do you mean that if you use elm-css for inline styling, that will prevent dead style because when you remove some Html you would also remove the CSS for it simply because the 2 things are written together?
Or do you use some technique to eliminate dead classes or ids from Elm code?
oh sorry yes ! I meant by using it “inlined” (but the advice applies in general, even outside Elm), although I try as much as possible to declare them using Html.Styled.styled tagName [...styles] at the top level, so that all the hashing work is only done on load, and eventualy unused declarations are taken care of by the elm compiler itself. By not using global for anything but reset and typography, I’m quite confident I’m not shipping unused styles. In your situation, I guess only an elm-review could help out.
I’ve been using tailwind on projects at work (in Typescript) recently, and I must admit that there are things I like a lot with it, especially at prototyping. Although maintaining a compnonent system… maybe not. I’ve been curious to try it out in Elm but haven’t just yet.
This is similar to where I’ve found myself. My current approach for Elm code has been to use @ryannhg/css-in-elm - npm. It lets me work with vanilla CSS while also allowing me to handle dead code in my CSS by using elm-review to warn about unused classes.
If I’m working with something like elm-watch I also get really fast feedback loops too. If all I need to do is edit my CSS then elm-watch will handle that hot-reloading and my site updates styles almost immediately. If it includes class name changes then @ryannhg/css-in-elm will change the names accordingly and the Elm compiler will warn me nearly immediately.
Is there any other kind? 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.