It makes me feel sad that Elm has abandoned its limited but well-designed Element library, instead making developers directly write HTML. What's even worse, the task of dealing with CSS has been completely removed from the language, as, for instance, is implied here <http://package.elm-lang.org/packages/elm-lang/html/1.0.0/Html-Attributes>:
There is no Html.Styles module because best practices for working with HTML suggest that this should primarily be specified in CSS files. So the general recommendation is to use this function lightly. The same best practices also suggest that we should be writing HTML in .html files — in fact, it's a core idea behind some libraries (such as Ember). However, in Elm and React we are perfectly fine doing the opposite. Best principles are only the best until we come up with even better ones. So what exactly is wrong with CSS? I'm sure most of you have seen https://speakerdeck.com/vjeux/react-css-in-js where Vjeux has outlined a number of issues with CSS. It has been followed by a bunch of libraries for React (and not only) solving these issues to varying degrees of success. Some of you have mentioned SASS/LESS as solutions. However, while they do solve some of the issues, they leave out the most serious ones — isolation, global namespaces and non-deterministic resolution. In fact, from my experience, using the power of nested selectors is detrimental in the long term if you consider the cost of readability and maintenance. Simple, class-based selectors along with rules on class naming is what made BEM so scalable and easy to reason about. Unfortunately, in its current state rtfeldman/elm-css <https://github.com/rtfeldman/elm-css> doesn't solve any of those important issues. I hope it will one day — but it will likely be a very different project by then. Currently the Javascript world does offer much more superior solutions when it comes to scaling the stylesheets and reducing cognitive overhead. My personal favourite solution is CSS Modules — I successfully use it in an Ember app with over 200 stylesheets, all being completely isolated from each other, without any extra effort from our developers. However, we should ask ourselves if we can do better than Cascading and Sheets. Actually, what does it mean to Style an element? What is an element? Why do we have markup/styling separation in the first place? Aren't they both part of something known as a view? I think these are the questions Evan tried to answer with the Elements library. We need a better abstraction of both HTML and CSS, something that Elm, being an opinionated language, is best suited for. This is definitely possible — but the first step is for the community to understand the problem we are dealing with. On Tuesday, May 31, 2016 at 10:26:37 AM UTC+1, Peter Damoc wrote: > > How do you handle styling in your Elm programs? > > Do you use one of the following libraries? > > rtfeldman/elm-css > > seanhess/elm-style > > massung/elm-css > > Or do you do something completely different (manual style inlining, > classes and external css) ? > > I tried using Sean's library but I quickly ran into pseudo-selectors > trouble wanting to implement a simple hover effect. > > Somehow, keeping a set of hover states for some simple nav-link seams such > an overkill. > > How do you handle such scenarios? > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
