Hey Greg, Thanks :)
The most helpful thing you can do is try out the library if you get the chance, and let me know your experience on the #style-elements channel on slack As for drawing comparisons, that's definitely going to be part of the focus of the visual guide I'm working on. My current plan is to have a "cookbook" of common layout recipes and how this library solves them, as well as some explanation as to *why* this approach makes sense compared to the common approach. I'll post here when it's done. On Wednesday, July 5, 2017 at 12:47:00 PM UTC-4, Greg Coladarci wrote: > > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
