Proposal for a 1st-class, officially-supported CSS package

[suttlecommakevin]

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. The UI is defined by HTML/JS, but appearance is defined by CSS. 

I had proposed 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.

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 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, 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!

[Nick H]

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

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

[Noah Hall]

elm-css doesn't need extra first class Elm support. It has first class
Elm support - everything is a function. As Nick said, focus on how you
_use_ elm-css. It's plenty first-class enough wihtout burdening the
compiler with excessive language features.

>> email to elm-discuss...@googlegroups.com.

>> 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 elm-discuss...@googlegroups.com.

[suttlecommakevin]

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

[Richard Feldman]

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

--
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 elm-discuss...@googlegroups.com.

[suttlecommakevin]

Thanks Richard,

Could you elaborate on this statement? I'm having trouble understanding how the Elm compiler,

known for it's awesome UX and errors, wouldn't help CSS. 

You even demoed it. https://www.youtube.com/watch?v=R121YzswY_4

[Richard Feldman]

Yeah elm-css is a library. I think a library is the way to go here, not a language addition. :)

To me it's not a question of "could CSS UX theoretically be better." I'm sure it could! The question is whether those benefits would justify the innate complexity increase of adding anything whatsoever to the language.

I don't think they would. It's more important to me to keep the language simpler than to add CSS-specific features of any kind. :)

--

[suttlecommakevin]

Thanks, Richard. Fair enough, I suppose. 

2 final questions:

1. Why not make Elm-CSS an officially-supported core package? 
   
2. Is there a roadmap for Elm-CSS or suggested ways to improve it?

[Richard Feldman]

1. Why not make Elm-CSS an officially-supported core package? 
   

Besides the fact that that's not up to me, I'd say the main reason would be that it's not officially supported. ;)

It's just me and other community members working on it; there's no "official" support work being done on it.

1. Is there a roadmap for Elm-CSS or suggested ways to improve it?

Pretty much just the stuff on https://github.com/rtfeldman/elm-css/issues