*Preface* Saying Elm is a language for front-end apps, but leaving out 1/3 of the stack isn't confidence-inspiring. Between our collective experience, I think we can make something awesome and fun to use, while leveraging the features that make Elm a great language.
*Problem to be solved* One thing that React got right was that the UI is *always* a reflection of state <http://rauchg.com/pure-ui>. The UI is defined by HTML/JS, but appearance is defined by CSS. I had proposed <https://github.com/elm-lang/virtual-dom/pull/33> that the style attribute of the Virtual DOM package match the same signature of the classList function, by adding a boolean as a param, but that wasn't accepted. To be fair, I didn't provide background or explanation. I should have taken more time to explain. That's on me. What this was meant to do was described just below the style attribute listing in the Elm docs, inside the classList example <http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-Attributes#classList> . As a component author, by applying styles via logic ahead of time, you save component consumers the task of having to know every possible class name. A common trick for this in React is to use ES2015 template strings to interpolate other enumerated properties, thus limiting the scope of what UI component consumers have to know, and what the compiler has to validate against. <button className={`${design}`}> where design was enumerated in a PropType list like so: <CustomButton design:'primary' | 'secondary' | 'tertiary' /> *Prior Art* Richard Feldman's work <https://www.youtube.com/watch?v=R121YzswY_4> in this area is the most promising I've seen in CSS since Sass. I mean that. One thing I'm curious about though, is in his Elm-CSS library <https://github.com/rtfeldman/elm-css/blob/master/src/Css.elm>, the APIs don't seem to be taking advantage of Elm's native primitive types. I'm almost a complete n00b, so please take that into context before I give the following example. type alias Value compatible = { compatible | value : String } type alias All compatible = { compatible | value : String, all : Compatible } Like React, it appears that every property and value ends up being a String, even when the possible CSS values are enumerated. *Example:* type alias NumberedWeight = { value : String, fontWeight : Compatible } Shouldn't this be an Union -> Int with the possible values of 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 ? Am I missing something here (*wholly possible and very likely*), or is there a reason to not do this with the rest of the package? In this case, it's true that font-weight can take other enumerated strings as values, but I'm wondering why not leverage the native primitive types? I have a slew of other ideas, but let's start here. Thanks! -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
