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? 

--

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

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

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

[Yosuke Torii]

I use pure elm-html. Like David, I write styles in a separated Elm file called `Styles.elm`, but each style is declared as `List (String, String)` for composability.

zIndex =
  { subView = "600"
  , messageBar = "700"
  , contextMenu = "800"
  }

messageBar =
    [ ("position", "absolute")
    , ("color", "#fff")
    , ("z-index", zIndex.messageBar)
    , ("padding", "5px 10px")
    , ("transition", "height opacity 0.8s linear")
    ]

successBar =
  messageBar ++
    [ ("background-color", "#4c5")
    , ("opacity", "1")
    ]

Sometimes it takes arguments for dynamic values.

mainView windowHeight =
  flex ++
    [ ("height", px (windowHeight - headerHeight))
    , ("position", "relative")
    ]

I also use tiny CSS for resetting default styles and using `:hover`. For `:hover`, I wrote a helper today (here). It's not used yet, but might be useful :)

2016年5月31日火曜日 18時26分37秒 UTC+9 Peter Damoc:

[Yosuke Torii]

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stefan Houtzager]

Mikowski has an interesting presentation on less and sass: https://www.youtube.com/watch?v=rnkMjzhxw4s

-- 

Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Op dinsdag 31 mei 2016 17:13:27 UTC+2 schreef VeryThorough:

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

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

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

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

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

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


 

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Damoc]

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

[Yosuke Torii]

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

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

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

[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

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

[Yonatan Kogan]

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

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

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rex van der Spuy]

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

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

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

[Matthew Griffith]

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

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

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

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

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

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

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

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

On Tuesday, May 31, 2016 at 10:26:37 AM UTC+1, Peter Damoc wrote:

How do you handle styling in your Elm programs? 

Do you use one of the following libraries?

rtfeldman/elm-css

seanhess/elm-style

massung/elm-css

Or do you do something completely different (manual style inlining, classes and external css) ? 

I tried using Sean's library but I quickly ran into pseudo-selectors trouble wanting to implement a simple hover effect. 

Somehow, keeping a set of hover states for some simple nav-link seams such an overkill. 

How do you handle such scenarios? 

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

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Yosuke Torii]

FYI, I just released jinjor/elm-inline-hover.

I hope it would be helpful for you ;)

2016年5月31日火曜日 18時26分37秒 UTC+9 Peter Damoc:

How do you handle styling in your Elm programs? 

Do you use one of the following libraries?

rtfeldman/elm-css

seanhess/elm-style

massung/elm-css

Or do you do something completely different (manual style inlining, classes and external css) ? 

I tried using Sean's library but I quickly ran into pseudo-selectors trouble wanting to implement a simple hover effect. 

Somehow, keeping a set of hover states for some simple nav-link seams such an overkill. 

How do you handle such scenarios? 

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

On Tuesday, May 31, 2016 at 2:26:37 AM UTC-7, Peter Damoc wrote:

[Peter Damoc]

On Mon, Jul 3, 2017 at 6:59 PM, Greg Coladarci <cola...@gmail.com> wrote:

A year later, I've just discovered this thread as I am new to the Elm world and was interested in how others solved for the styling side of things. 

In the spirit of trying to figure out how Elm can help solve long-standing shortcomings w/ CSS, I see there being two massive opportunities:

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

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

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

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

On Tuesday, May 31, 2016 at 7:26:37 PM UTC+10, Peter Damoc wrote:

How do you handle styling in your Elm programs? 

Do you use one of the following libraries?

rtfeldman/elm-css

seanhess/elm-style

massung/elm-css

Or do you do something completely different (manual style inlining, classes and external css) ? 

I tried using Sean's library but I quickly ran into pseudo-selectors trouble wanting to implement a simple hover effect. 

Somehow, keeping a set of hover states for some simple nav-link seams such an overkill. 

How do you handle such scenarios? 

[Matthew Griffith]

Excited to see what you come up with :)

The killer feature for 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:

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

[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 (https://www.youtube.com/watch?v=NYb2GDWMIm0) was very clear and instructive. It made me realize this was exactly what I was looking for. Elm started out with an "element" library way back in version 0.14 (or something). Then Elm switched to the HTML Library. And style-elements looks like a sort of merging between these two concepts. Style-elements is exactly the kind of development that attracted me to Elm in the first place. Elm is "javascript done better" and style-elements is "HTML+CSS done better".

My advice: please make a reference in your package readme to your Elm Europe presentation. And/or link to a small website that explains the why of this library and thus explains the concepts behind your library and use examples that show how to use the library. Basically, turn your Elm Europe presentation into a website explaining your library and put a link to this website in your package.

And a question: have you looked at Cassowary.js and implementations like GSS? See: http://overconstrained.io/. At first glance style-elements is currently not a constraint based layout engine. But, it feels like style-elements and constraint based layout are a natural fit. What is your opinion on this?

Thanks and I will start using your library.

Berry

Op dinsdag 4 juli 2017 15:17:09 UTC+2 schreef Matthew Griffith:

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

[Marek Fajkus]

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.

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

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

[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

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.

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

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.