[elm-discuss] State of CSS in Elm

[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?

[Simon]

I use external scss style sheets and gulp-sass: it's known technology and I
don't believe Elm uses the sort of component level name spacing for styles
that I've seen in Angular 2 (not sure of the technical name) that rewards
putting styles in with code.

Post by 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/

[David Legard]

I use pure elm-html - the style is placed as an Attribute in the view
function

. . .
p [navstyle] [text (String.join " " m.opens) ]
. . .

while the Style itself is defined elsewhere (I put all of them in a file
called Styles.elm)

navstyle = style [("position","absolute")
,("left", "0px")
,("width","10cm")
,("backgroundColor","Beige")
,("fontFamily","Calibri,serif")
,("cursor","pointer")
]

I have used this to build in Elm quite a nice collapsing/expanding TreeMenu
navigation menu, which is something that CSS does rather well.

[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
<https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/> is
adopted...)

Post by 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/

[Stefan Houtzager]

Mikowski has an interesting presentation on less and
sass:

--
Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Post by 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
<https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/> is
adopted...)

Post by 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/

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

Post by Stefan Houtzager
http://youtu.be/rnkMjzhxw4s
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager

Post by 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
<https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/> is
adopted...)

Post by 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 the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[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
<https://gist.github.com/jinjor/439a6721065eeb83abc5a9da4049cec9>). It's
not used yet, but might be useful :)

Post by 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/

[Yosuke Torii]

For `:hover`, I wrote a helper today (here
<https://gist.github.com/jinjor/439a6721065eeb83abc5a9da4049cec9>). It's
not used yet, but might be useful :)

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

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
<https://gist.github.com/jinjor/439a6721065eeb83abc5a9da4049cec9>). It's
not used yet, but might be useful :)

Post by 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
For more options, visit https://groups.google.com/d/optout.

[Ondřej Žára]

I used Elm.embed, static <link rel="stylesheet"> in my parent document and
(obviously) an external stylesheet, preferrably using a Less preprocessor.

O.

Post by 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/

[Tim Stewart]

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

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document and
(obviously) an external stylesheet, preferrably using a Less preprocessor.
O.

Post by 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/

[Tim Stewart]

BTW when I say "I guess it's a smoother workflow", I've usually worked with
designers who provide an image/photoshop file, but I know some are quite
CSS-literate.

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document
and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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/

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

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document
and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

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

Post by 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).

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document
and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Peter Damoc]

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

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

Post by 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).

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document
and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google
Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
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
For more options, visit https://groups.google.com/d/optout.

[Yosuke Torii]

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

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

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

Post by 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).

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document
and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google
Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
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
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
For more options, visit https://groups.google.com/d/optout.

[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/

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

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

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

Post by 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).

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent
document and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google
Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
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
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
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
For more options, visit https://groups.google.com/d/optout.

[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

Post by Peter Damoc
Sean's elm-style is the successor of the elm package inspired by that
http://package.elm-lang.org/packages/seanhess/elm-style/1.0.1/

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

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

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

Post by 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).

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent
document and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google
Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it,
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
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
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
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
For more options, visit https://groups.google.com/d/optout.

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

Post by 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).

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document
and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
There is NO FATE, we are the creators.
blog: http://damoc.ro/

[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
<https://www.npmjs.com/package/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
<https://css-tricks.com/the-debate-around-do-we-even-need-css-anymore/>).
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.

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

Post by 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).

Post by Tim Stewart
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...".

Post by Ondřej Žára
I used Elm.embed, static <link rel="stylesheet"> in my parent document
and (obviously) an external stylesheet, preferrably using a Less
preprocessor.
O.

Post by 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 the Google
Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

--
There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Rex van der Spuy]

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

[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. :)

Post by Rex van der Spuy

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

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
For more options, visit https://groups.google.com/d/optout.

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

[Jeff Schomay]

I've tried a few, but prefer an external pure css style sheet with BEM
build with webpack (with css files parallel to each elm file). The only
annoying part is getting the link to the built style sheet in the right
place, especially if I am "mounting" a lower-level component with elm-live
(or elm reactor when it lets you do that again).

Post by 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/

[David Legard]

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"]

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

Post by David Legard
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
For more options, visit https://groups.google.com/d/optout.

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

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

Post by David Legard
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
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
For more options, visit https://groups.google.com/d/optout.

[Rex van der Spuy]

Post by Peter Damoc
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.

[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
<https://github.com/mdgriffith/elm-style-animation> represents style as
union types, though it's only a subset of properties that are covered
<https://github.com/mdgriffith/elm-style-animation/blob/master/src/Style/Properties.elm>.

Post by Rex van der Spuy

Post by Peter Damoc
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.

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

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

Post by 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 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
For more options, visit https://groups.google.com/d/optout.

[Kirill Korolyov]

It makes me feel sad that Elm has abandoned its limited but well-designed
Element library, instead making developers directly write HTML. What's even
worse, the task of dealing with CSS has been completely removed from the
language, as, for instance, is implied here
<http://package.elm-lang.org/packages/elm-lang/html/1.0.0/Html-Attributes>:

There is no Html.Styles module because best practices for working with HTML
suggest that this should primarily be specified in CSS files. So the
general recommendation is to use this function lightly.


The same best practices also suggest that we should be writing HTML in
.html files — in fact, it's a core idea behind some libraries (such as
Ember). However, in Elm and React we are perfectly fine doing the opposite.
Best principles are only the best until we come up with even better ones.

So what exactly is wrong with CSS?

I'm sure most of you have seen https://speakerdeck.com/vjeux/react-css-in-js
where Vjeux has outlined a number of issues with CSS. It has been followed
by a bunch of libraries for React (and not only) solving these issues to
varying degrees of success. Some of you have mentioned SASS/LESS as
solutions. However, while they do solve some of the issues, they leave out
the most serious ones — isolation, global namespaces and non-deterministic
resolution. In fact, from my experience, using the power of nested
selectors is detrimental in the long term if you consider the cost of
readability and maintenance. Simple, class-based selectors along with rules
on class naming is what made BEM so scalable and easy to reason about.

Unfortunately, in its current state rtfeldman/elm-css
<https://github.com/rtfeldman/elm-css> doesn't solve any of those important
issues. I hope it will one day — but it will likely be a very different
project by then. Currently the Javascript world does offer much more
superior solutions when it comes to scaling the stylesheets and reducing
cognitive overhead. My personal favourite solution is CSS Modules — I
successfully use it in an Ember app with over 200 stylesheets, all being
completely isolated from each other, without any extra effort from our
developers.

However, we should ask ourselves if we can do better than Cascading and
Sheets. Actually, what does it mean to Style an element? What is an
element? Why do we have markup/styling separation in the first place?
Aren't they both part of something known as a view? I think these are the
questions Evan tried to answer with the Elements library.

We need a better abstraction of both HTML and CSS, something that Elm,
being an opinionated language, is best suited for. This is definitely
possible — but the first step is for the community to understand the
problem we are dealing with.

Post by 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/

[Yosuke Torii]

FYI, I just released jinjor/elm-inline-hover
<http://package.elm-lang.org/packages/jinjor/elm-inline-hover/latest>.

I hope it would be helpful for you ;)

Post by 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/

[Greg Coladarci]

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:

1) You can't do anything clever w/ inheritance, code re-useage, variables,
etc. SASS and LESS "solve this" but both have their own annoyances in the
project setup and compilation phases; it's important to consider them as
perhaps bandaids for a larger problem.

2) As your app grows larger and larger, if you skew too far towards the
"one style sheet to rule them all" for your app, it's very difficult
(potentially impossible) to ever determine what's actually being used. This
can result in megs of styles and a team afraid to remove any of them (there
are no tests in the CSS world).

The way we have solved this outside of Elm is:

1) use SASS and deal w/ slow and (sometimes) error-prone compilation. The
errors are due to LibSass's C implementation running through NPM. Bad
things just happen from time to time and it's crazy slow for large
projects.

2) Find a balance between inheritance (perhaps css resets + shared utility
classes like .error-text) + component-css (auto-scoped css that only
affects the component matching that file
(https://github.com/ebryn/ember-component-css)).

These are the two places I would focus the brilliant minds of the Elm
community. Hypothetically, if Elm could offer a promise like this:

"With ELM, you style your app w/ a similar syntax as you write SASS (but w/
native compilation) and you can add those styles to any module you want and
they will be scoped to that view, but pulled out at compilation time to a
separate CSS include"

I think some eyes would open and it would be yet another reason to give Elm
a shot.

Again, just my two cents... I spent some time w/ elm-css and it's a steep
learning curve and will alienate a large segment of people. Add to this
having to learn a new markup language (a whole 'nother conversation) and it
starts to feel like the markup and styling side of things come secondary to
the business logic side of things.

Post by 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/

[Peter Damoc]

Post by Greg Coladarci
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

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/

[Francesco Orsenigo]

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.

Post by 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/

[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

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

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.

Post by 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/

[Berry Groenendijk]

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
http://youtu.be/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

Post by 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
http://youtu.be/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

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.

Post by 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/

[Matthew Griffith]

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.

Post by Berry Groenendijk
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 (
http://youtu.be/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

Post by 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
http://youtu.be/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

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.

Post by 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/

[Greg Coladarci]

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.

Post by Matthew Griffith
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.

Post by Berry Groenendijk
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 (
http://youtu.be/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

Post by 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
http://youtu.be/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

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.

Post by 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/

[Matthew Griffith]

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.

Post by Greg Coladarci
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.
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.

Post by Matthew Griffith
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.

Post by Berry Groenendijk
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 (
http://youtu.be/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

Post by 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
http://youtu.be/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

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.

Post by 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/

[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

Post by Matthew Griffith
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.

Post by Greg Coladarci
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.
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.

Post by Matthew Griffith
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.

Post by Berry Groenendijk
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 (
http://youtu.be/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

Post by 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
http://youtu.be/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

FWIW I am working on a major overhaul of https://github.com/xarvh/el
m-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.

Post by 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 the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

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

Post by 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

Post by Matthew Griffith
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.

Post by Greg Coladarci
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.
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.

Post by Matthew Griffith
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.

Post by Berry Groenendijk
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 (
http://youtu.be/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

Post by 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
http://youtu.be/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

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.

Post by 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 the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Marek Fajkus]

Post by Rex van der Spuy
And, is it just me, or does anyone else think the "cascading" feature is
just a fundamentally bad idea?

I rather don't say bad but it can definitely get our of hands pretty badly.

We're using external stylesheet (sass) but with strict guidelines. Instead
of generating styles directly using elm we have a library for generating
class names in quite strict fashion. You can have a look if you're
interested: https://github.com/GlobalWebIndex/class-namespaces. Also,
guidlines are published on GitHub as
well https://github.com/GlobalWebIndex/weak-css.

Post by Rex van der Spuy
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/