Re: [elm-discuss] Proposal for a 1st-class, officially-supported CSS package

[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

* > I can't think of a time its existence would have saved me a noticeable 
amount of debugging time.*

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

Re: [elm-discuss] Proposal for a 1st-class, officially-supported CSS package

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

On Wed, Sep 14, 2016, 8:54 AM suttlecommakevin 
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
> elm-discuss+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Proposal for a 1st-class, officially-supported CSS package

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

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

Re: [elm-discuss] Proposal for a 1st-class, officially-supported CSS package

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

On Tue, Sep 13, 2016 at 7:17 PM, Nick H  wrote:
> 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.
>
>
> On Tue, Sep 13, 2016 at 8:23 AM, suttlecommakevin
>  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. 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.
>>
>> 
>>
>>
>> where design was enumerated in a PropType list like so:
>>
>> 
>>
>>
>> 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!
>>
>> --
>> 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Proposal for a 1st-class, officially-supported CSS package

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


On Tue, Sep 13, 2016 at 8:23 AM, suttlecommakevin <
suttlecommake...@gmail.com> 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 . 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.
>
> 
>
>
> where design was enumerated in a PropType list like so:
>
> 
>
>
> *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!
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] 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.



 
where design was enumerated in a PropType list like so:




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

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