I agree with Noah. The class of errors language-level CSS value support would improve is so small, I can't think of a time its existence would have saved me a noticeable amount of debugging time.
I value language simplicity, so by default any new language feature has a very high bar to clear to justify its inclusion. I don't think this will ever clear that bar. :) On Wed, Sep 14, 2016, 8:54 AM suttlecommakevin <[email protected]> wrote: > Hey Nick, > > I linked to the source implementation in my original post, but it does > overlap the API. > > Noah, > > > burdening the compiler with excessive language features. > > > I don't see how supporting CSS via native primitives is burdening the > compiler. > "Excessive" seems diametrically-opposed to what I'm suggesting. > > Again, I simply cannot see Elm justifying itself as a front-end language > while not having a proper story for CSS. > This statement feels like a placeholder, because it's certainly not a > modern perspective. > > > 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. > > > @Evan, @Richard, I'd love your feedback here. > > *KS* > > -- > 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/vvJGw1u7NVQ/unsubscribe. > To unsubscribe from this group and all its topics, 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.
