Excited to see what you come up with :) The killer feature for style-elements <https://github.com/mdgriffith/style-elements> is the layout engine. Making layout really easy to use and having a much simpler vocabulary than css is a huge win in my book. The ultimate result of that is that your view code is generally as refactorable/adjustable as refactoring normal elm code. The key part of this is that when you refactor style, your style shouldn't "break", which is really easy to do with css, even when the css is typechecked. CSS is just hard.
However, when you have unbreakable style, building tools on top of that becomes really fun :D Here's the talk I gave at Elm Europe <https://www.youtube.com/watch?v=NYb2GDWMIm0> And the slides <https://docs.google.com/presentation/d/1s7VPbvuv6m9-S7ePm0R5loqRnHsZEHHVbZALJpWAARo/edit?usp=sharing> : style-elements isn't directly about using css in terms of elm, but in creating a really nice design vocabulary which could compile to any layout engine, but for now compiles to html and css. I've found that if you have that and it works well, you don't need to inspect the DOM to figure out why your style broke, because they have a harder time breaking. It would be analogous to inspecting the JS after elm compiles. The large majority of elm programmers don't need to drop to that level. Also as a note, the class-hash calculation for style-elements is done once at the start of runtime and is actually surprisingly fast :) As in no one has ever mentioned performance as being an issue. Just my two-bits :D On Tuesday, July 4, 2017 at 4:10:47 AM UTC-4, Francesco Orsenigo wrote: > > FWIW I am working on a major overhaul of > https://github.com/xarvh/elm-styled-html > > The core idea is that CSS should be just normal Elm code, so that any > pattern, syntax and tool that you can use for normal Elm code, you can use > for CSS: modularisation, common variables, generator functions, > tree-shaking and basically any feature that will be added to the Elm > compiler (code-splitting, lazy code loading, maybe compile-time inlining?). > Plus, you kill a big chunk of your build pipeline. > > The new version will add the styles lazily in the document header, and > drops the class name hash in favour of just using the module name for > namespacing to be faster and generate class names that are more readable > and meaningful. > > Also, we are using Elm with rtfeldman/elm-css in production, and we are > not sure whether the latter is worth the effort, since it adds a lot of > overhead to solve problems that are not really a big deal (at least for us) > in CSS; because of this ideally I would like to support both elm-css style > declarations, and plain strings declarations. > > > > > On Tuesday, May 31, 2016 at 7:26:37 PM UTC+10, 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.
