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.

Reply via email to