Re: [elm-discuss] Re: State of CSS in Elm

[Matthew Griffith]

I do have a private package that where I've implemented `Element.lazy`, 
however it's not tested which is why I haven't made it public.

At the moment you're right there is no way to use `lazy` without dropping 
into html, however that won't always be the case.  There's nothing blocking 
lazy being implemented in style elements beyond me getting some time to 
focus on it.

There is an `Element.Keyed` module though.








On Friday, July 7, 2017 at 5:07:37 PM UTC-4, Mark Hamburg wrote:
>
> The latest version of the library does look very nice. I'm just starting 
> to use it for prototyping some new cases.
>
> A skim suggests that the only way to use laziness is to drop in and out of 
> HTML. Is that a correct read or did I miss something?
>
> Mark
>
> On Wed, Jul 5, 2017 at 10:38 AM, Matthew Griffith  > wrote:
>
>> 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  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 "Bad" but I would mandate "" over 
>>> "" 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 

Re: [elm-discuss] Re: State of CSS in Elm

[Mark Hamburg]

The latest version of the library does look very nice. I'm just starting to
use it for prototyping some new cases.

A skim suggests that the only way to use laziness is to drop in and out of
HTML. Is that a correct read or did I miss something?

Mark

On Wed, Jul 5, 2017 at 10:38 AM, Matthew Griffith 
wrote:

> 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  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 "Bad" but I would mandate "" over
>> "" 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 201

Re: [elm-discuss] Re: State of CSS in Elm

[Peter Damoc]

On Mon, Jul 3, 2017 at 6:59 PM, Greg Coladarci  wrote:

> A year later, I've just discovered this thread as I am new to the Elm
> world and was interested in how others solved for the styling side of
> things.
>
> In the spirit of trying to figure out how Elm can help solve long-standing
> shortcomings w/ CSS, I see there being two massive opportunities:
>

One of the best projects that came up in this domain is:
https://github.com/mdgriffith/style-elements

The solution will be something like that: separating layout concerns from
surface concerns.

As a more exotic alternative, I have toyed in January with an approach that
rests on custom elements but I haven't put in enough thought to flesh that
out. It was inspired by this article:
https://www.smashingmagazine.com/2017/01/styled-components-enforcing-best-practices-component-based-systems/




-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Max Goldstein]

Elm doesn't want to be a graphics library (anymore). It wants to be a language, 
a reactive framework (TEA), and to expose the web platform. I think the current 
state of CSS is, while unfortunate for production users, a fertile breeding 
ground for new ideas and innovation. And if you want to come up with a new 
abstraction that compiles down to HTML, nothing is stoping you (see 
elm-mdl-lite). 

-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Peter Damoc]

I went full XKCD on this one:
https://xkcd.com/927/

I played a little bit with "rtfeldman/elm-css" and I actually liked it but
looking at the source code and at the long list of issues and PRs, I
got discouraged about contributing.
It is a great library and probably the most tested and used in real world
scenarios.

I ended up spending most of today implementing my own little library
"pdamoc/elm-css" that is a blend of all three libraries.
It has a stylesheet declarative approach that is closer to
*rtfeldman/elm-css* than to* massung/elm-css* and a simple, String based
Declarations approach like in *seanhess/elm-style*.

It is alpha quality but I managed to port the code I wrote yesterday to it
and I'm planning to play with it for a few more days just for fun. :)




On Wed, Jun 15, 2016 at 10:22 PM, Rex van der Spuy 
wrote:

>
>> I haven't used elm-css yet but I'm really looking forward to it - It
>> sounds like it will make working with CSS much more bearable.
>>
>
> Just replying to my own comment:
>
> I played around with elm-css for an afternoon, but realized it was adding
> more complexity than my (tiny) app was benefiting from.
> So I'm back to using Elm's `style` function - nice and simple for now.
> But elm-css is really excellent and it would be ideal for a large,
> traditional web site project.
>
> --
> 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.
>



-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Rex van der Spuy]

>
>
> I haven't used elm-css yet but I'm really looking forward to it - It 
> sounds like it will make working with CSS much more bearable.
>

Just replying to my own comment:

I played around with elm-css for an afternoon, but realized it was adding 
more complexity than my (tiny) app was benefiting from.
So I'm back to using Elm's `style` function - nice and simple for now.
But elm-css is really excellent and it would be ideal for a large, 
traditional web site project.  

-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Tim Stewart]

I agree Wouter, a lot has gone into optimising CSS animation in browsers,
rebuilding those wheels in a compile-to-JS language seems somewhat
redundant.

Again I think it depends on your background. If you are experienced with
working in CSS, retooling and reskilling (CSS and JS can often be the
concern of different people in a team) to do it all a different way when
all you really want to do is improve the JS layer could seem like a
drawback rather than a plus. On the other hand, if you don't have a
particularly large legacy of CSS work, handling everything in one language
probably makes more sense.

On Wed, Jun 8, 2016 at 7:07 AM, Wouter In t Velt 
wrote:

> Really interesting discussion and viewpoints. As  newcomer and hobbyist in
> the elm arena, some may think this naive, but I find the principle to
> separate concerns very appealing.
> Meaning (simply put) the DOM (html) is for the component structure, CSS is
> for layout, and JavaScript is for interaction.
> IMHO, the fuzziness we have to deal with is because each of the 3 building
> blocks is lacking features that we need.
> Which is why so many web apps/ sites end up with messy DOM trees with
> loads of unwanted div layers, and messy Jquery as a band-aid for styling
> deficiencies.
>
> In learning elm (coming from react), I really like the functional and pure
> aspects of it.
> But I really wish I would be able to keep styling and transitions for
> state changes separate, preferably with styling in CSS stylesheets.
>
> Especially for transitions.
>
> I try to have my elm code render only twice, and let CSS would take care
> of transition. Seperates concerns, and keeps code clean. Is the right class
> applied in state 1? And in state 2? Then elm is fine. Layout and transition
> wrong? Must be CSS.
> Adding a subscription in elm to every single of 500 animation frames +
> extending model to not only save state but also all
> in-between-two-discrete-states information, feels like an unwanted
> complication and mixture of concerns.
>
> I see benefits of DOM + styling + interaction mix in components (reminds
> me of Polymer).
> And I dislike the cascading aspect (and other shortcomings) of pure CSS,
> and it is hard to switch back and forth between elm and CSS mindset.
> Not sure of I can keep transitions from blending, and the will definitely
> investigate elm CSS solutions mentioned.
>
> But for now, I still believe code will be cleaner and more maintainable as
> it grows, if one persists to separate the styling on the one hand from the
> content and interaction in the other.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Matthew Griffith]

If you want to do any animation beyond relying on css animations, you're at 
least partially required to use inline styles.  

Also, if I have a project with lots of animation (say...a game), then it 
makes sense to have a solution that helps with managing inline styles.  

For me, a solution that allows inline vs file based styles to be as 
interchangeable as possible based on operational needs would be ideal.

That being said, currently most of my projects are not games and so I tend 
to use LESSCSS heavily while the handful of animated properties are handled 
inline by Elm.  I haven't yet tried out elm-css, elm-style, etc.  but I'll 
probably give them ago in the near future.

Also, just as a note, elm-style-animation 
 represents style as 
union types, though it's only a subset of properties that are covered 
.
 
  




On Tuesday, June 7, 2016 at 12:34:08 PM UTC-4, Rex van der Spuy wrote:
>
>
>> Layout for a web app IS part of the critical information. It encapsulates 
>> a lot from the UX of that app. 
>>
>
> - This is exactly what I've found to be the case with the apps I've been 
> building. 
>
>>

-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Wouter In t Velt]

Really interesting discussion and viewpoints. As  newcomer and hobbyist in the 
elm arena, some may think this naive, but I find the principle to separate 
concerns very appealing.
Meaning (simply put) the DOM (html) is for the component structure, CSS is for 
layout, and JavaScript is for interaction.
IMHO, the fuzziness we have to deal with is because each of the 3 building 
blocks is lacking features that we need.
Which is why so many web apps/ sites end up with messy DOM trees with loads of 
unwanted div layers, and messy Jquery as a band-aid for styling deficiencies.

In learning elm (coming from react), I really like the functional and pure 
aspects of it.
But I really wish I would be able to keep styling and transitions for state 
changes separate, preferably with styling in CSS stylesheets.

Especially for transitions.

I try to have my elm code render only twice, and let CSS would take care of 
transition. Seperates concerns, and keeps code clean. Is the right class 
applied in state 1? And in state 2? Then elm is fine. Layout and transition 
wrong? Must be CSS.
Adding a subscription in elm to every single of 500 animation frames + 
extending model to not only save state but also all 
in-between-two-discrete-states information, feels like an unwanted complication 
and mixture of concerns.

I see benefits of DOM + styling + interaction mix in components (reminds me of 
Polymer).
And I dislike the cascading aspect (and other shortcomings) of pure CSS, and it 
is hard to switch back and forth between elm and CSS mindset.
Not sure of I can keep transitions from blending, and the will definitely 
investigate elm CSS solutions mentioned.

But for now, I still believe code will be cleaner and more maintainable as it 
grows, if one persists to separate the styling on the one hand from the content 
and interaction in the other.

-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Rex van der Spuy]

>
>
> Layout for a web app IS part of the critical information. It encapsulates 
> a lot from the UX of that app. 
>

- This is exactly what I've found to be the case with the apps I've been 
building. 

>

-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Peter Damoc]

I think using inline styles might be both maintainable and scalable but it
might require a different way of thinking about the app.
You can structure the views to have a second parameter that would contain
device information like size and DPI and you could case on that info and
have totally different layouts for each class of device. One layout for
phones, one for tablets, one for desktops.
These layouts could share a lot in common by abstracting certain widgets
and by using responsive techniques. For example, you can have a highly
specialized mobile version and have the tablet and the desktop look more or
less the same.

CSS was created for presentation back when the web was about documents and
it makes perfect sense to have that separation for a document.
What we have now are web apps and these are in a completely different
category.
Layout for a web app IS part of the critical information. It encapsulates a
lot from the UX of that app.



On Mon, Jun 6, 2016 at 3:24 AM, Tim Stewart 
wrote:

> This is a very interesting discussion which I think is covering two
> vectors - firstly, is statically typed CSS better that traditional approach
> (with or without CSS pre-processor), and secondly is inline CSS better than
> stylesheet. On the first, there seems to be different opinion, depending to
> some extent on background, as well as David's suggestion of turning one
> into the other, which may be the best of both worlds.
>
> On the second point though, I really don't get the appeal of inline CSS.
> One of the things I reckon the web got right was decoupling presentation
> from structure and behavior. In Android and iOS SDK development, the two
> are combined into a single file, in each case a dialect of XML. So what
> happens when you want your app to have a different appearance on different
> screen sizes or orientations? You produce a whole different XML file for
> that media size. That's Apple's official advice - at least last time I last
> looked at iOS native development. By having to duplicate the entire view
> structure, you double your maintenance overhead and introduce an
> opportunity for bugs to creep in where you change an identifier in one XML
> file, say, but not the matching identifier in a different layout's file.
>
> With CSS media queries, while not perfect, you get to define everything
> that stays the same just once, and media-specific aspects as appropriate -
> with source grouped together for that media size. Now, you can put media
> queries into inline CSS I guess (is that what you guys are doing?) but then
> your conditional layout logic is spread all over the place.
>
> And then your styles are replicated into the DOM on each individual node.
> If you have an component type repeated 1000 times, that's 1000 times the
> same style code gets added in and re-evaluated by the browser. Browsers
> render CSS fast, but still that just seems wrong.
>
> I guess if your app doesn't care about media size and doesn't have 1000
> components then this is just a non-issue, but I struggle with the concept
> of this being maintainable and scalable.
>
> On Fri, Jun 3, 2016 at 7:40 PM, David Legard  wrote:
>
>> How difficult would it be to write an automated script to turn CSS into
>> Elm-Css?
>>
>>>
>> i.e. to turn
>>
>> h1 {
>> background-color: green;
>> }
>>
>> into
>>
>> h1 = style ["background-color","green"]
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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.
>



-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Tim Stewart]

This is a very interesting discussion which I think is covering two vectors
- firstly, is statically typed CSS better that traditional approach (with
or without CSS pre-processor), and secondly is inline CSS better than
stylesheet. On the first, there seems to be different opinion, depending to
some extent on background, as well as David's suggestion of turning one
into the other, which may be the best of both worlds.

On the second point though, I really don't get the appeal of inline CSS.
One of the things I reckon the web got right was decoupling presentation
from structure and behavior. In Android and iOS SDK development, the two
are combined into a single file, in each case a dialect of XML. So what
happens when you want your app to have a different appearance on different
screen sizes or orientations? You produce a whole different XML file for
that media size. That's Apple's official advice - at least last time I last
looked at iOS native development. By having to duplicate the entire view
structure, you double your maintenance overhead and introduce an
opportunity for bugs to creep in where you change an identifier in one XML
file, say, but not the matching identifier in a different layout's file.

With CSS media queries, while not perfect, you get to define everything
that stays the same just once, and media-specific aspects as appropriate -
with source grouped together for that media size. Now, you can put media
queries into inline CSS I guess (is that what you guys are doing?) but then
your conditional layout logic is spread all over the place.

And then your styles are replicated into the DOM on each individual node.
If you have an component type repeated 1000 times, that's 1000 times the
same style code gets added in and re-evaluated by the browser. Browsers
render CSS fast, but still that just seems wrong.

I guess if your app doesn't care about media size and doesn't have 1000
components then this is just a non-issue, but I struggle with the concept
of this being maintainable and scalable.

On Fri, Jun 3, 2016 at 7:40 PM, David Legard  wrote:

> How difficult would it be to write an automated script to turn CSS into
> Elm-Css?
>
>>
> i.e. to turn
>
> h1 {
> background-color: green;
> }
>
> into
>
> h1 = style ["background-color","green"]
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Yonatan Kogan]

It really depends on who you're working with. If you're working with 
designers, asking them to learn elm in order to style the site is a pretty 
big ask, especially if they're overburdened work-wise. That's something we 
ran into when trying to use local-css 
. If everyone writing is an 
engineer though, or you're in a situation where everyone who does styling 
is willing to learn elm, you can get away with doing things inline (this 
also is/was a trend in react land as discussed a bit here 
). 
 If you're rendering your DOM in elm though, you already probably need a 
bunch of buy-in from your designers and such so maybe it's not that big a 
stretch.

On Thursday, June 2, 2016 at 11:46:39 AM UTC-5, Rex van der Spuy wrote:
>
> A few months ago, when I was still a rank Elm beginner, I was teaching 
> myself Elm while simultaneously building a production app.
> To my surprise, the most time-consuming part was not learning Elm, but 
> fiddling with and debugging the CSS.
>
> The fact that CSS just fails silently is a real headache.
> And, is it just me, or does anyone else think the "cascading" feature is 
> just a fundamentally bad idea?
>
> I haven't used elm-css yet but I'm really looking forward to it - It 
> sounds like it will make working with CSS much more bearable.
>
> On Thursday, June 2, 2016 at 5:35:52 AM UTC-4, Peter Damoc wrote:
>>
>> I understand how using Elm for CSS might look like a case of "I've got a 
>> hammer..." and the external CSS has its merits, especially when it comes to 
>> transitioning from a traditional HTML+CSS+JS to Elm. 
>>
>> CSS in Elm comes with its own set of advantages and, in the long run, I 
>> think it might be a way better option. 
>> It can use types to make sure that changes to IDs or Classes are 
>> consistent throughout. Named values can make for an additional line of 
>> defense against typos. 
>> It has way better composition and much more flexibility due tot the fact 
>> that one can create style on the fly based on information from the 
>> environment (e.g. device size and/or DPI).   
>>
>>
>>  
>>
>>
>> On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart  
>> wrote:
>>
>>> Ondrej's approach makes sense to me too. The advantages Elm brings to 
>>> the table - ensuring program validity, eliminating runtime errors and 
>>> issues related to mutable state etc. - just aren't really problems in CSS. 
>>> The shortcomings that CSS does have are mainly addressed by LESS, it's 
>>> quick and easy to iterate by copying styling experiments in the browser 
>>> directly back to source, and I'm guessing it's a smoother workflow when 
>>> collaborating with designers, embedding into existing sites etc. Using Elm 
>>> for CSS seems to me a bit like a case of "I've got a hammer...".
>>>
>>>
>>> On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:

 I used Elm.embed, static  in my parent document 
 and (obviously) an external stylesheet, preferrably using a Less 
 preprocessor.

 O.

 On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> 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.

Re: [elm-discuss] Re: State of CSS in Elm

[Rex van der Spuy]

A few months ago, when I was still a rank Elm beginner, I was teaching 
myself Elm while simultaneously building a production app.
To my surprise, the most time-consuming part was not learning Elm, but 
fiddling with and debugging the CSS.

The fact that CSS just fails silently is a real headache.
And, is it just me, or does anyone else think the "cascading" feature is 
just a fundamentally bad idea?

I haven't used elm-css yet but I'm really looking forward to it - It sounds 
like it will make working with CSS much more bearable.

On Thursday, June 2, 2016 at 5:35:52 AM UTC-4, Peter Damoc wrote:
>
> I understand how using Elm for CSS might look like a case of "I've got a 
> hammer..." and the external CSS has its merits, especially when it comes to 
> transitioning from a traditional HTML+CSS+JS to Elm. 
>
> CSS in Elm comes with its own set of advantages and, in the long run, I 
> think it might be a way better option. 
> It can use types to make sure that changes to IDs or Classes are 
> consistent throughout. Named values can make for an additional line of 
> defense against typos. 
> It has way better composition and much more flexibility due tot the fact 
> that one can create style on the fly based on information from the 
> environment (e.g. device size and/or DPI).   
>
>
>  
>
>
> On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart  > wrote:
>
>> Ondrej's approach makes sense to me too. The advantages Elm brings to the 
>> table - ensuring program validity, eliminating runtime errors and issues 
>> related to mutable state etc. - just aren't really problems in CSS. The 
>> shortcomings that CSS does have are mainly addressed by LESS, it's quick 
>> and easy to iterate by copying styling experiments in the browser directly 
>> back to source, and I'm guessing it's a smoother workflow when 
>> collaborating with designers, embedding into existing sites etc. Using Elm 
>> for CSS seems to me a bit like a case of "I've got a hammer...".
>>
>>
>> On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:
>>>
>>> I used Elm.embed, static  in my parent document 
>>> and (obviously) an external stylesheet, preferrably using a Less 
>>> preprocessor.
>>>
>>> O.
>>>
>>> On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> 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.

Re: [elm-discuss] Re: State of CSS in Elm

[Yosuke Torii]

Oh, didn't know that, thank you. But I agree that the critical thing we
don't have is a simple hover. lol


2016-06-02 22:53 GMT+09:00 Peter Damoc :

> Sean's elm-style is the successor of the elm package inspired by that
> presentation:
>
> http://package.elm-lang.org/packages/seanhess/elm-style/1.0.1/
>
> On Thu, Jun 2, 2016 at 4:43 PM, Yosuke Torii  wrote:
>
>> I'm from the first group but on the way of experimenting inline style
>> inspired by "CSS in JS" from React community :)
>>
>>
>> 2016-06-02 21:18 GMT+09:00 Peter Damoc :
>>
>>> I'm actually from the third group and I'm primed to be the most
>>> dissatisfied.
>>> I come from traditional GUI programming. ;)
>>>
>>>
>>>
>>> On Thu, Jun 2, 2016 at 12:55 PM, Tim Stewart 
>>> wrote:
>>>
 I see your point Peter, I think it depends on where you're coming from.
 I get the impression Elm draws interest from two groups - those with a
 front-end web-dev background interested in an alternative to the prevailing
 view that "the answer to the problems in JavaScript is ... more JavaScript"
 (ES6/ES7/JSX...) and those from a functional programming background
 interested in how functional principals are being applied in a new language
 and environment. Probably the former are glad to be able to leverage
 existing assets (stylesheets) and skills on the styling front while the
 latter are keen to explore how things can be done better using functional
 principles. It's great to have both options.

 On Thursday, June 2, 2016 at 7:35:52 PM UTC+10, Peter Damoc wrote:
>
> I understand how using Elm for CSS might look like a case of "I've got
> a hammer..." and the external CSS has its merits, especially when it comes
> to transitioning from a traditional HTML+CSS+JS to Elm.
>
> CSS in Elm comes with its own set of advantages and, in the long run,
> I think it might be a way better option.
> It can use types to make sure that changes to IDs or Classes are
> consistent throughout. Named values can make for an additional line of
> defense against typos.
> It has way better composition and much more flexibility due tot the
> fact that one can create style on the fly based on information from the
> environment (e.g. device size and/or DPI).
>
>
>
>
>
> On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart 
> wrote:
>
>> Ondrej's approach makes sense to me too. The advantages Elm brings to
>> the table - ensuring program validity, eliminating runtime errors and
>> issues related to mutable state etc. - just aren't really problems in 
>> CSS.
>> The shortcomings that CSS does have are mainly addressed by LESS, it's
>> quick and easy to iterate by copying styling experiments in the browser
>> directly back to source, and I'm guessing it's a smoother workflow when
>> collaborating with designers, embedding into existing sites etc. Using 
>> Elm
>> for CSS seems to me a bit like a case of "I've got a hammer...".
>>
>>
>> On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:
>>>
>>> I used Elm.embed, static  in my parent
>>> document and (obviously) an external stylesheet, preferrably using a 
>>> Less
>>> preprocessor.
>>>
>>> O.
>>>
>>> On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> 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.

>>>
>>>
>>>
>>> --
>>> There is NO FATE

Re: [elm-discuss] Re: State of CSS in Elm

[Peter Damoc]

Sean's elm-style is the successor of the elm package inspired by that
presentation:

http://package.elm-lang.org/packages/seanhess/elm-style/1.0.1/

On Thu, Jun 2, 2016 at 4:43 PM, Yosuke Torii  wrote:

> I'm from the first group but on the way of experimenting inline style
> inspired by "CSS in JS" from React community :)
>
>
> 2016-06-02 21:18 GMT+09:00 Peter Damoc :
>
>> I'm actually from the third group and I'm primed to be the most
>> dissatisfied.
>> I come from traditional GUI programming. ;)
>>
>>
>>
>> On Thu, Jun 2, 2016 at 12:55 PM, Tim Stewart 
>> wrote:
>>
>>> I see your point Peter, I think it depends on where you're coming from.
>>> I get the impression Elm draws interest from two groups - those with a
>>> front-end web-dev background interested in an alternative to the prevailing
>>> view that "the answer to the problems in JavaScript is ... more JavaScript"
>>> (ES6/ES7/JSX...) and those from a functional programming background
>>> interested in how functional principals are being applied in a new language
>>> and environment. Probably the former are glad to be able to leverage
>>> existing assets (stylesheets) and skills on the styling front while the
>>> latter are keen to explore how things can be done better using functional
>>> principles. It's great to have both options.
>>>
>>> On Thursday, June 2, 2016 at 7:35:52 PM UTC+10, Peter Damoc wrote:

 I understand how using Elm for CSS might look like a case of "I've got
 a hammer..." and the external CSS has its merits, especially when it comes
 to transitioning from a traditional HTML+CSS+JS to Elm.

 CSS in Elm comes with its own set of advantages and, in the long run, I
 think it might be a way better option.
 It can use types to make sure that changes to IDs or Classes are
 consistent throughout. Named values can make for an additional line of
 defense against typos.
 It has way better composition and much more flexibility due tot the
 fact that one can create style on the fly based on information from the
 environment (e.g. device size and/or DPI).





 On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart 
 wrote:

> Ondrej's approach makes sense to me too. The advantages Elm brings to
> the table - ensuring program validity, eliminating runtime errors and
> issues related to mutable state etc. - just aren't really problems in CSS.
> The shortcomings that CSS does have are mainly addressed by LESS, it's
> quick and easy to iterate by copying styling experiments in the browser
> directly back to source, and I'm guessing it's a smoother workflow when
> collaborating with designers, embedding into existing sites etc. Using Elm
> for CSS seems to me a bit like a case of "I've got a hammer...".
>
>
> On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:
>>
>> I used Elm.embed, static  in my parent
>> document and (obviously) an external stylesheet, preferrably using a Less
>> preprocessor.
>>
>> O.
>>
>> On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 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.
>>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
>> To unsubscribe from

Re: [elm-discuss] Re: State of CSS in Elm

[Yosuke Torii]

I'm from the first group but on the way of experimenting inline style
inspired by "CSS in JS" from React community :)


2016-06-02 21:18 GMT+09:00 Peter Damoc :

> I'm actually from the third group and I'm primed to be the most
> dissatisfied.
> I come from traditional GUI programming. ;)
>
>
>
> On Thu, Jun 2, 2016 at 12:55 PM, Tim Stewart 
> wrote:
>
>> I see your point Peter, I think it depends on where you're coming from. I
>> get the impression Elm draws interest from two groups - those with a
>> front-end web-dev background interested in an alternative to the prevailing
>> view that "the answer to the problems in JavaScript is ... more JavaScript"
>> (ES6/ES7/JSX...) and those from a functional programming background
>> interested in how functional principals are being applied in a new language
>> and environment. Probably the former are glad to be able to leverage
>> existing assets (stylesheets) and skills on the styling front while the
>> latter are keen to explore how things can be done better using functional
>> principles. It's great to have both options.
>>
>> On Thursday, June 2, 2016 at 7:35:52 PM UTC+10, Peter Damoc wrote:
>>>
>>> I understand how using Elm for CSS might look like a case of "I've got a
>>> hammer..." and the external CSS has its merits, especially when it comes to
>>> transitioning from a traditional HTML+CSS+JS to Elm.
>>>
>>> CSS in Elm comes with its own set of advantages and, in the long run, I
>>> think it might be a way better option.
>>> It can use types to make sure that changes to IDs or Classes are
>>> consistent throughout. Named values can make for an additional line of
>>> defense against typos.
>>> It has way better composition and much more flexibility due tot the fact
>>> that one can create style on the fly based on information from the
>>> environment (e.g. device size and/or DPI).
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart 
>>> wrote:
>>>
 Ondrej's approach makes sense to me too. The advantages Elm brings to
 the table - ensuring program validity, eliminating runtime errors and
 issues related to mutable state etc. - just aren't really problems in CSS.
 The shortcomings that CSS does have are mainly addressed by LESS, it's
 quick and easy to iterate by copying styling experiments in the browser
 directly back to source, and I'm guessing it's a smoother workflow when
 collaborating with designers, embedding into existing sites etc. Using Elm
 for CSS seems to me a bit like a case of "I've got a hammer...".


 On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:
>
> I used Elm.embed, static  in my parent document
> and (obviously) an external stylesheet, preferrably using a Less
> preprocessor.
>
> O.
>
> On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> 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.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 ema

Re: [elm-discuss] Re: State of CSS in Elm

[Peter Damoc]

I'm actually from the third group and I'm primed to be the most
dissatisfied.
I come from traditional GUI programming. ;)



On Thu, Jun 2, 2016 at 12:55 PM, Tim Stewart 
wrote:

> I see your point Peter, I think it depends on where you're coming from. I
> get the impression Elm draws interest from two groups - those with a
> front-end web-dev background interested in an alternative to the prevailing
> view that "the answer to the problems in JavaScript is ... more JavaScript"
> (ES6/ES7/JSX...) and those from a functional programming background
> interested in how functional principals are being applied in a new language
> and environment. Probably the former are glad to be able to leverage
> existing assets (stylesheets) and skills on the styling front while the
> latter are keen to explore how things can be done better using functional
> principles. It's great to have both options.
>
> On Thursday, June 2, 2016 at 7:35:52 PM UTC+10, Peter Damoc wrote:
>>
>> I understand how using Elm for CSS might look like a case of "I've got a
>> hammer..." and the external CSS has its merits, especially when it comes to
>> transitioning from a traditional HTML+CSS+JS to Elm.
>>
>> CSS in Elm comes with its own set of advantages and, in the long run, I
>> think it might be a way better option.
>> It can use types to make sure that changes to IDs or Classes are
>> consistent throughout. Named values can make for an additional line of
>> defense against typos.
>> It has way better composition and much more flexibility due tot the fact
>> that one can create style on the fly based on information from the
>> environment (e.g. device size and/or DPI).
>>
>>
>>
>>
>>
>> On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart 
>> wrote:
>>
>>> Ondrej's approach makes sense to me too. The advantages Elm brings to
>>> the table - ensuring program validity, eliminating runtime errors and
>>> issues related to mutable state etc. - just aren't really problems in CSS.
>>> The shortcomings that CSS does have are mainly addressed by LESS, it's
>>> quick and easy to iterate by copying styling experiments in the browser
>>> directly back to source, and I'm guessing it's a smoother workflow when
>>> collaborating with designers, embedding into existing sites etc. Using Elm
>>> for CSS seems to me a bit like a case of "I've got a hammer...".
>>>
>>>
>>> On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:

 I used Elm.embed, static  in my parent document
 and (obviously) an external stylesheet, preferrably using a Less
 preprocessor.

 O.

 On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> 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.
>



-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Tim Stewart]

I see your point Peter, I think it depends on where you're coming from. I 
get the impression Elm draws interest from two groups - those with a 
front-end web-dev background interested in an alternative to the prevailing 
view that "the answer to the problems in JavaScript is ... more JavaScript" 
(ES6/ES7/JSX...) and those from a functional programming background 
interested in how functional principals are being applied in a new language 
and environment. Probably the former are glad to be able to leverage 
existing assets (stylesheets) and skills on the styling front while the 
latter are keen to explore how things can be done better using functional 
principles. It's great to have both options.

On Thursday, June 2, 2016 at 7:35:52 PM UTC+10, Peter Damoc wrote:
>
> I understand how using Elm for CSS might look like a case of "I've got a 
> hammer..." and the external CSS has its merits, especially when it comes to 
> transitioning from a traditional HTML+CSS+JS to Elm. 
>
> CSS in Elm comes with its own set of advantages and, in the long run, I 
> think it might be a way better option. 
> It can use types to make sure that changes to IDs or Classes are 
> consistent throughout. Named values can make for an additional line of 
> defense against typos. 
> It has way better composition and much more flexibility due tot the fact 
> that one can create style on the fly based on information from the 
> environment (e.g. device size and/or DPI).   
>
>
>  
>
>
> On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart  > wrote:
>
>> Ondrej's approach makes sense to me too. The advantages Elm brings to the 
>> table - ensuring program validity, eliminating runtime errors and issues 
>> related to mutable state etc. - just aren't really problems in CSS. The 
>> shortcomings that CSS does have are mainly addressed by LESS, it's quick 
>> and easy to iterate by copying styling experiments in the browser directly 
>> back to source, and I'm guessing it's a smoother workflow when 
>> collaborating with designers, embedding into existing sites etc. Using Elm 
>> for CSS seems to me a bit like a case of "I've got a hammer...".
>>
>>
>> On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:
>>>
>>> I used Elm.embed, static  in my parent document 
>>> and (obviously) an external stylesheet, preferrably using a Less 
>>> preprocessor.
>>>
>>> O.
>>>
>>> On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> 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.

Re: [elm-discuss] Re: State of CSS in Elm

[Peter Damoc]

I understand how using Elm for CSS might look like a case of "I've got a
hammer..." and the external CSS has its merits, especially when it comes to
transitioning from a traditional HTML+CSS+JS to Elm.

CSS in Elm comes with its own set of advantages and, in the long run, I
think it might be a way better option.
It can use types to make sure that changes to IDs or Classes are consistent
throughout. Named values can make for an additional line of defense against
typos.
It has way better composition and much more flexibility due tot the fact
that one can create style on the fly based on information from the
environment (e.g. device size and/or DPI).





On Thu, Jun 2, 2016 at 11:30 AM, Tim Stewart 
wrote:

> Ondrej's approach makes sense to me too. The advantages Elm brings to the
> table - ensuring program validity, eliminating runtime errors and issues
> related to mutable state etc. - just aren't really problems in CSS. The
> shortcomings that CSS does have are mainly addressed by LESS, it's quick
> and easy to iterate by copying styling experiments in the browser directly
> back to source, and I'm guessing it's a smoother workflow when
> collaborating with designers, embedding into existing sites etc. Using Elm
> for CSS seems to me a bit like a case of "I've got a hammer...".
>
>
> On Thursday, June 2, 2016 at 4:48:35 AM UTC+10, Ondřej Žára wrote:
>>
>> I used Elm.embed, static  in my parent document
>> and (obviously) an external stylesheet, preferrably using a Less
>> preprocessor.
>>
>> O.
>>
>> On Tuesday, May 31, 2016 at 11:26:37 AM UTC+2, 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.
>



-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Peter Damoc]

Interesting presentation.
I wonder if the double buffering technique he's talking about has any value
in the context of the virtual-dom.



On Wed, Jun 1, 2016 at 8:25 PM, Stefan Houtzager  wrote:

> Mikowski has an interesting presentation on less and sass:
> https://www.youtube.com/watch?v=rnkMjzhxw4s
>
>
> --
> Kind regards,
>
> Stefan Houtzager
>
> Houtzager ICT consultancy & development
>
> www.linkedin.com/in/stefanhoutzager
>
> Op dinsdag 31 mei 2016 17:13:27 UTC+2 schreef VeryThorough:
>
>> I use external styles written in Sass.  In my next project, I plan to try
>> using rtfeldman/elm-css, though again as a generator for an external
>> stylesheet.  Pseudo selectors are a perfect example of why external CSS is
>> more powerful (and generally more performant) than inline styles.  (At
>> least until the Houdini project
>> 
>>  is
>> adopted...)
>>
>>
>> On Tuesday, May 31, 2016 at 2:26:37 AM UTC-7, 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.
>



-- 
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.

Re: [elm-discuss] Re: State of CSS in Elm

[Yosuke Torii]

>
> For `:hover`, I wrote a helper today (here
> ). It's
> not used yet, but might be useful :)


Hmm... I just tried it, but not so useful as I thought.


2016-06-01 17:44 GMT+09:00 Yosuke Torii :

> I use pure elm-html. Like David, I write styles in a separated Elm file
> called `Styles.elm`, but each style is declared as `List (String, String)`
> for composability.
>
> zIndex =
>   { subView = "600"
>   , messageBar = "700"
>   , contextMenu = "800"
>   }
>
> messageBar =
> [ ("position", "absolute")
> , ("color", "#fff")
> , ("z-index", zIndex.messageBar)
> , ("padding", "5px 10px")
> , ("transition", "height opacity 0.8s linear")
> ]
>
> successBar =
>   messageBar ++
> [ ("background-color", "#4c5")
> , ("opacity", "1")
> ]
>
> Sometimes it takes arguments for dynamic values.
>
> mainView windowHeight =
>   flex ++
> [ ("height", px (windowHeight - headerHeight))
> , ("position", "relative")
> ]
>
> I also use tiny CSS for resetting default styles and using `:hover`. For
> `:hover`, I wrote a helper today (here
> ). It's
> not used yet, but might be useful :)
>
>
> 2016年5月31日火曜日 18時26分37秒 UTC+9 Peter Damoc:
>>
>> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.