Hi Kevin, As far as I can tell, the type alias you are quoting (Value, All, NumberedWeight) are not part of the elm-css API. I can't find them in the package documentation <http://package.elm-lang.org/packages/rtfeldman/elm-css/latest>. Are you suggesting a change to the *implementation* of elm-css, or a change to the *interface*?
Sorry if I'm missing the point. I don't have a lot of experience with Elm CSS. On Tue, Sep 13, 2016 at 8:23 AM, suttlecommakevin < [email protected]> wrote: > *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. > -- 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.
