Hey Matthew, Just wanted to also say that this video was fantastic. As someone who has spent 10 years w/ my feet firmly planted in the "style concerns don't belong in your template" it is still very hard for me to get used to this idea, but I *want* to get there. To some, I fear these concepts will be like bringing back the <center> tag. I think it'll help your project immensely (and therefore Elm as a whole) to get ahead of this as I can tell from your opening remarks that you are coming from a place of deep understanding of the history of the space. You touched on this when you phrased things like "this is like what you'd use media queries for, but..." - I think comparing "current" "accepted" real world solutions to common problems (SASS, Media Queries, Compass?, etc) w/ the equivalent in your library could help bring even more people over and help the greater cause.
For example, I don't want my engineers to say "<div style="color: red;">Bad</div>" but I would mandate "<div class="error-text"></div>" over "<div id="myElement"></div>" and then using a dedicated style in my sheet for this one off ID. So here I am putting styles in my markup "breaking the rule". To some degree, your library is taking that to an absolutely extreme w/ some incredible promises of reliable layout. I look forward to following the progress and would love to help if there's anything I can do on this front. On Wednesday, July 5, 2017 at 4:15:31 AM UTC-7, Matthew Griffith wrote: > > Hi Berry, > > Good to hear! > > Yeah, the video was just released a day ago, so not surprised you didn't > see it until then :) > > I'm putting together a website that will serve as a live example, > explanation of concepts, and a visual guide, just need the time to actually > finish it. I'll post in elm-discuss and /r/elm once it's done. > > I have seen GSS/Cassowary and have definitely thought about adding some > sort of constraint based logic to style-elements, but we'll see. There are > a few things for the library that I'm focusing on right now(like the > guide), but once they're done, I'm sure constraints will come up :) > > If you check out the library, I highly recommend joining the > #style-elements channel on the elm slack. I'm generally there to answer > questions. > > > > > > > On Wednesday, July 5, 2017 at 6:32:39 AM UTC-4, Berry Groenendijk wrote: >> >> Hi Matthew, >> >> I have looked at style-elements before in the package repository. But, by >> just reading the package documentation I struggled to fully understand or >> appreciate this library. But, your presentation at Elm Europe 2017 ( >> https://www.youtube.com/watch?v=NYb2GDWMIm0) was very clear and >> instructive. It made me realize this was exactly what I was looking for. >> Elm started out with an "element" library way back in version 0.14 (or >> something). Then Elm switched to the HTML Library. And style-elements looks >> like a sort of merging between these two concepts. Style-elements is >> exactly the kind of development that attracted me to Elm in the first >> place. Elm is "javascript done better" and style-elements is "HTML+CSS done >> better". >> >> My advice: please make a reference in your package readme to your Elm >> Europe presentation. And/or link to a small website that explains the why >> of this library and thus explains the concepts behind your library and use >> examples that show how to use the library. Basically, turn your Elm Europe >> presentation into a website explaining your library and put a link to this >> website in your package. >> >> And a question: have you looked at Cassowary.js and implementations like >> GSS? See: http://overconstrained.io/. At first glance style-elements is >> currently not a constraint based layout engine. But, it feels like >> style-elements and constraint based layout are a natural fit. What is your >> opinion on this? >> >> Thanks and I will start using your library. >> >> Berry >> >> Op dinsdag 4 juli 2017 15:17:09 UTC+2 schreef Matthew Griffith: >>> >>> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
