Re: [elm-discuss] Re: State of CSS in Elm

[Matthew Griffith]

I do have a private package that where I've implemented `Element.lazy`, 
however it's not tested which is why I haven't made it public.

At the moment you're right there is no way to use `lazy` without dropping 
into html, however that won't always be the case.  There's nothing blocking 
lazy being implemented in style elements beyond me getting some time to 
focus on it.

There is an `Element.Keyed` module though.








On Friday, July 7, 2017 at 5:07:37 PM UTC-4, Mark Hamburg wrote:
>
> The latest version of the library does look very nice. I'm just starting 
> to use it for prototyping some new cases.
>
> A skim suggests that the only way to use laziness is to drop in and out of 
> HTML. Is that a correct read or did I miss something?
>
> Mark
>
> On Wed, Jul 5, 2017 at 10:38 AM, Matthew Griffith <mdg.gr...@gmail.com 
> > wrote:
>
>> Hey Greg,
>>
>> Thanks :)
>>
>> The most helpful thing you can do is try out the library if you get the 
>> chance, and let me know your experience on the #style-elements channel on 
>> slack
>>
>> As for drawing comparisons, that's definitely going to be part of the 
>> focus of the visual guide I'm working on.  My current plan is to have a 
>> "cookbook" of common layout recipes and how this library solves them, as 
>> well as some explanation as to *why* this approach makes sense compared 
>> to the common approach.
>>
>> I'll post here when it's done.
>>
>>
>>
>>
>> On Wednesday, July 5, 2017 at 12:47:00 PM UTC-4, Greg Coladarci wrote:
>>>
>>> Hey Matthew,
>>>
>>> Just wanted to also say that this video was fantastic. As someone who 
>>> has spent 10 years w/ my feet firmly planted in the "style concerns don't 
>>> belong in your template" it is still very hard for me to get used to this 
>>> idea, but I *want* to get there. To some, I fear these concepts will be 
>>> like bringing back the  tag. I think it'll help your project 
>>> immensely (and therefore Elm as a whole) to get ahead of this as I can tell 
>>> from your opening remarks that you are coming from a place of deep 
>>> understanding of the history of the space. You touched on this when you 
>>> phrased things like "this is like what you'd use media queries for, but..." 
>>> - I think comparing "current" "accepted" real world solutions to common 
>>> problems (SASS, Media Queries, Compass?, etc) w/ the equivalent in your 
>>> library could help bring even more people over and help the greater cause.
>>>
>>> For example, I don't want my engineers to say "Bad" but I would mandate "" over 
>>> "" and then using a dedicated style in my sheet 
>>> for this one off ID. So here I am putting styles in my markup "breaking the 
>>> rule". To some degree, your library is taking that to an absolutely extreme 
>>> w/ some incredible promises of reliable layout. I look forward to following 
>>> the progress and would love to help if there's anything I can do on this 
>>> front.
>>>
>>> On Wednesday, July 5, 2017 at 4:15:31 AM UTC-7, Matthew Griffith wrote:
>>>>
>>>> Hi Berry,
>>>>
>>>> Good to hear!
>>>>
>>>> Yeah, the video was just released a day ago, so not surprised you 
>>>> didn't see it until then :)
>>>>
>>>> I'm putting together a website that will serve as a live example, 
>>>> explanation of concepts, and a visual guide, just need the time to 
>>>> actually 
>>>> finish it.  I'll post in elm-discuss and /r/elm once it's done.
>>>>
>>>> I have seen GSS/Cassowary and have definitely thought about adding some 
>>>> sort of constraint based logic to style-elements, but we'll see.  There 
>>>> are 
>>>> a few things for the library that I'm focusing on right now(like the 
>>>> guide), but once they're done, I'm sure constraints will come up :)  
>>>>
>>>> If you check out the library, I highly recommend joining the 
>>>> #style-elements channel on the elm slack.  I'm generally there to answer 
>>>> questions.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wednesday, July 5, 2017 at 6:32:39 AM UTC-4, Berry Groenendijk wrote:
>>>>>
>>>>> Hi Matthew,
>>>>>
>>>>> I have looked at style-elements before in the package repository. But, 
>>>&

[elm-discuss] Re: more than 1d?

[Matthew Griffith]

I'd recommend getting on the elm slack, there are a bunch of helpful people 
there!

For multi-dimensional lists you can use `List.map` twice :)

```
data = [ [1,2,3], [4,5,6]]

result = 
List.map (List.map ((+) 5)) data

```



On Wednesday, July 5, 2017 at 1:19:18 PM UTC-4, Raoul Duke wrote:
>
> lists and List.map etc. are fine for 1d. 
>
> what about 2+d? 
>
> (wish we had list comprehensions.) 
>

-- 
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] Re: State of CSS in Elm

[Matthew Griffith]

Hey Greg,

Thanks :)

The most helpful thing you can do is try out the library if you get the 
chance, and let me know your experience on the #style-elements channel on 
slack

As for drawing comparisons, that's definitely going to be part of the focus 
of the visual guide I'm working on.  My current plan is to have a 
"cookbook" of common layout recipes and how this library solves them, as 
well as some explanation as to *why* this approach makes sense compared to 
the common approach.

I'll post here when it's done.




On Wednesday, July 5, 2017 at 12:47:00 PM UTC-4, Greg Coladarci wrote:
>
> Hey Matthew,
>
> Just wanted to also say that this video was fantastic. As someone who has 
> spent 10 years w/ my feet firmly planted in the "style concerns don't 
> belong in your template" it is still very hard for me to get used to this 
> idea, but I *want* to get there. To some, I fear these concepts will be 
> like bringing back the  tag. I think it'll help your project 
> immensely (and therefore Elm as a whole) to get ahead of this as I can tell 
> from your opening remarks that you are coming from a place of deep 
> understanding of the history of the space. You touched on this when you 
> phrased things like "this is like what you'd use media queries for, but..." 
> - I think comparing "current" "accepted" real world solutions to common 
> problems (SASS, Media Queries, Compass?, etc) w/ the equivalent in your 
> library could help bring even more people over and help the greater cause.
>
> For example, I don't want my engineers to say "Bad" but I would mandate "" over 
> "" and then using a dedicated style in my sheet 
> for this one off ID. So here I am putting styles in my markup "breaking the 
> rule". To some degree, your library is taking that to an absolutely extreme 
> w/ some incredible promises of reliable layout. I look forward to following 
> the progress and would love to help if there's anything I can do on this 
> front.
>
> On Wednesday, July 5, 2017 at 4:15:31 AM UTC-7, Matthew Griffith wrote:
>>
>> Hi Berry,
>>
>> Good to hear!
>>
>> Yeah, the video was just released a day ago, so not surprised you didn't 
>> see it until then :)
>>
>> I'm putting together a website that will serve as a live example, 
>> explanation of concepts, and a visual guide, just need the time to actually 
>> finish it.  I'll post in elm-discuss and /r/elm once it's done.
>>
>> I have seen GSS/Cassowary and have definitely thought about adding some 
>> sort of constraint based logic to style-elements, but we'll see.  There are 
>> a few things for the library that I'm focusing on right now(like the 
>> guide), but once they're done, I'm sure constraints will come up :)  
>>
>> If you check out the library, I highly recommend joining the 
>> #style-elements channel on the elm slack.  I'm generally there to answer 
>> questions.
>>
>>
>>
>>
>>
>>
>> On Wednesday, July 5, 2017 at 6:32:39 AM UTC-4, Berry Groenendijk wrote:
>>>
>>> Hi Matthew,
>>>
>>> I have looked at style-elements before in the package repository. But, 
>>> by just reading the package documentation I struggled to fully understand 
>>> or appreciate this library. But, your presentation at Elm Europe 2017 (
>>> https://www.youtube.com/watch?v=NYb2GDWMIm0) was very clear and 
>>> instructive. It made me realize this was exactly what I was looking for. 
>>> Elm started out with an "element" library way back in version 0.14 (or 
>>> something). Then Elm switched to the HTML Library. And style-elements looks 
>>> like a sort of merging between these two concepts. Style-elements is 
>>> exactly the kind of development that attracted me to Elm in the first 
>>> place. Elm is "javascript done better" and style-elements is "HTML+CSS done 
>>> better".
>>>
>>> My advice: please make a reference in your package readme to your Elm 
>>> Europe presentation. And/or link to a small website that explains the why 
>>> of this library and thus explains the concepts behind your library and use 
>>> examples that show how to use the library. Basically, turn your Elm Europe 
>>> presentation into a website explaining your library and put a link to this 
>>> website in your package.
>>>
>>> And a question: have you looked at Cassowary.js and implementations like 
>>> GSS? See: http://overconstrained.io/. At first glance style-elements is 
>>> currently not a constraint based layout en

[elm-discuss] Re: State of CSS in Elm

[Matthew Griffith]

Hi Berry,

Good to hear!

Yeah, the video was just released a day ago, so not surprised you didn't 
see it until then :)

I'm putting together a website that will serve as a live example, 
explanation of concepts, and a visual guide, just need the time to actually 
finish it.  I'll post in elm-discuss and /r/elm once it's done.

I have seen GSS/Cassowary and have definitely thought about adding some 
sort of constraint based logic to style-elements, but we'll see.  There are 
a few things for the library that I'm focusing on right now(like the 
guide), but once they're done, I'm sure constraints will come up :)  

If you check out the library, I highly recommend joining the 
#style-elements channel on the elm slack.  I'm generally there to answer 
questions.






On Wednesday, July 5, 2017 at 6:32:39 AM UTC-4, Berry Groenendijk wrote:
>
> Hi Matthew,
>
> I have looked at style-elements before in the package repository. But, by 
> just reading the package documentation I struggled to fully understand or 
> appreciate this library. But, your presentation at Elm Europe 2017 (
> https://www.youtube.com/watch?v=NYb2GDWMIm0) was very clear and 
> instructive. It made me realize this was exactly what I was looking for. 
> Elm started out with an "element" library way back in version 0.14 (or 
> something). Then Elm switched to the HTML Library. And style-elements looks 
> like a sort of merging between these two concepts. Style-elements is 
> exactly the kind of development that attracted me to Elm in the first 
> place. Elm is "javascript done better" and style-elements is "HTML+CSS done 
> better".
>
> My advice: please make a reference in your package readme to your Elm 
> Europe presentation. And/or link to a small website that explains the why 
> of this library and thus explains the concepts behind your library and use 
> examples that show how to use the library. Basically, turn your Elm Europe 
> presentation into a website explaining your library and put a link to this 
> website in your package.
>
> And a question: have you looked at Cassowary.js and implementations like 
> GSS? See: http://overconstrained.io/. At first glance style-elements is 
> currently not a constraint based layout engine. But, it feels like 
> style-elements and constraint based layout are a natural fit. What is your 
> opinion on this?
>
> Thanks and I will start using your library.
>
> Berry
>
> Op dinsdag 4 juli 2017 15:17:09 UTC+2 schreef Matthew Griffith:
>>
>> Excited to see what you come up with :)
>>
>> The killer feature for style-elements 
>> <https://github.com/mdgriffith/style-elements> is the layout engine. 
>>  Making layout really easy to use and having a much simpler vocabulary than 
>> css is a huge win in my book.  The ultimate result of that is that your 
>> view code is generally as refactorable/adjustable as refactoring normal elm 
>> code.  The key part of this is that when you refactor style, your style 
>> shouldn't "break", which is really easy to do with css, even when the css 
>> is typechecked.  CSS is just hard.
>>
>> However, when you have unbreakable style, building tools on top of that 
>> becomes really fun :D
>>
>> Here's the talk I gave at Elm Europe 
>> <https://www.youtube.com/watch?v=NYb2GDWMIm0>
>>
>> And the slides 
>> <https://docs.google.com/presentation/d/1s7VPbvuv6m9-S7ePm0R5loqRnHsZEHHVbZALJpWAARo/edit?usp=sharing>
>> :
>>
>> style-elements isn't directly about using css in terms of elm, but in 
>> creating a really nice design vocabulary which could compile to any layout 
>> engine, but for now compiles to html and css.
>>
>> I've found that if you have that and it works well, you don't need to 
>> inspect the DOM to figure out why your style broke, because they have a 
>> harder time breaking.  It would be analogous to inspecting the JS after elm 
>> compiles.  The large majority of elm programmers don't need to drop to that 
>> level.
>>
>> Also as a note, the class-hash calculation for style-elements is done 
>> once at the start of runtime and is actually surprisingly fast :)  As in no 
>> one has ever mentioned performance as being an issue.
>>
>> Just my two-bits :D
>>
>>
>> On Tuesday, July 4, 2017 at 4:10:47 AM UTC-4, Francesco Orsenigo wrote:
>>>
>>> FWIW I am working on a major overhaul of 
>>> https://github.com/xarvh/elm-styled-html
>>>
>>> The core idea is that CSS should be just normal Elm code, so that any 
>>> pattern, syntax and tool that you can use for normal Elm code, you can use 
>>> for CSS: modularisation

[elm-discuss] Re: State of CSS in Elm

[Matthew Griffith]

Excited to see what you come up with :)

The killer feature for style-elements 
 is the layout engine. 
 Making layout really easy to use and having a much simpler vocabulary than 
css is a huge win in my book.  The ultimate result of that is that your 
view code is generally as refactorable/adjustable as refactoring normal elm 
code.  The key part of this is that when you refactor style, your style 
shouldn't "break", which is really easy to do with css, even when the css 
is typechecked.  CSS is just hard.

However, when you have unbreakable style, building tools on top of that 
becomes really fun :D

Here's the talk I gave at Elm Europe 


And the slides 

:

style-elements isn't directly about using css in terms of elm, but in 
creating a really nice design vocabulary which could compile to any layout 
engine, but for now compiles to html and css.

I've found that if you have that and it works well, you don't need to 
inspect the DOM to figure out why your style broke, because they have a 
harder time breaking.  It would be analogous to inspecting the JS after elm 
compiles.  The large majority of elm programmers don't need to drop to that 
level.

Also as a note, the class-hash calculation for style-elements is done once 
at the start of runtime and is actually surprisingly fast :)  As in no one 
has ever mentioned performance as being an issue.

Just my two-bits :D


On Tuesday, July 4, 2017 at 4:10:47 AM UTC-4, Francesco Orsenigo wrote:
>
> FWIW I am working on a major overhaul of 
> https://github.com/xarvh/elm-styled-html
>
> The core idea is that CSS should be just normal Elm code, so that any 
> pattern, syntax and tool that you can use for normal Elm code, you can use 
> for CSS: modularisation, common variables, generator functions, 
> tree-shaking and basically any feature that will be added to the Elm 
> compiler (code-splitting, lazy code loading, maybe compile-time inlining?). 
> Plus, you kill a big chunk of your build pipeline.
>
> The new version will add the styles lazily in the document header, and 
> drops the class name hash in favour of just using the module name for 
> namespacing to be faster and generate class names that are more readable 
> and meaningful.
>
> Also, we are using Elm with rtfeldman/elm-css in production, and we are 
> not sure whether the latter is worth the effort, since it adds a lot of 
> overhead to solve problems that are not really a big deal (at least for us) 
> in CSS; because of this ideally I would like to support both elm-css style 
> declarations, and plain strings declarations.
>
>
>
>
> On Tuesday, May 31, 2016 at 7:26:37 PM UTC+10, Peter Damoc wrote:
>>
>> How do you handle styling in your Elm programs? 
>>
>> Do you use one of the following libraries?
>>
>> rtfeldman/elm-css
>>
>> seanhess/elm-style
>>
>> massung/elm-css
>>
>> Or do you do something completely different (manual style inlining, 
>> classes and external css) ? 
>>
>> I tried using Sean's library but I quickly ran into pseudo-selectors 
>> trouble wanting to implement a simple hover effect. 
>>
>> Somehow, keeping a set of hover states for some simple nav-link seams 
>> such an overkill. 
>>
>> How do you handle such scenarios? 
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

-- 
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] Re: What about partial public exposition of private types?

[Matthew Griffith]

Yeah, that was something I realized recently, though changing it requires a 
major version bump.  Should be changed in the next version though!  (Along 
with a bunch of other goodies that will come along with it.)




On Friday, March 10, 2017 at 1:02:41 PM UTC-5, Matthieu Pizenberg wrote:
>
> Did calling the type and its alias both 'Test' somehow override the 
>> private one with the public one?
>>
>
> No actually it is misleading you here. The main difference is that when I 
> write:
>
> -- module Test exposing (testFunction)
> import Public exposing (Test)
> import Private
> testFunction : Test
> testFunction = Private.SomeTest
>
> `Test` in `testFunction` type definition refers to `Public.Test`. It is 
> the same as writing:
>
> -- module Test exposing (testFunction)
> import Public
> import Private
> testFunction : Public.Test
> testFunction = Private.SomeTest
>
> whereas everywhere in elm-style-animation, mdgriffith is defining its 
> functions with the `Animation.Model.Animation msg` return type instead of 
> using the `State` public type:
>
> initialState : List Animation.Model.Property -> Animation msg
>
> Technically both types are the same (well not exactly since he defined 
> State as Animation *Never*) and both could compile (not here because of 
> this Never). But for public interface, I think that type definitions should 
> use the public types.
>

-- 
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] Re: Dealing with invalid state transitions

[Matthew Griffith]

You could invert your cases.


update msg state =
case state of
   Loading ->
  case msg of
(all your messages that apply when loading)
   Displaying stuff ->
   case msg of
(all your messages that apply when displaying




On Tuesday, January 17, 2017 at 9:03:05 AM UTC-5, Tomáš Znamenáček wrote:
>
> Hello!
>
> I have an app that loads some JSON from a website and displays it. The 
> state of the app could be modelled a bit like this:
>
> type State =
> Loading |
> Displaying Stuff
>
> type alias Stuff = { … }
>
> Now I am writing the update function to handle messages:
>
> update : Msg -> State -> (State, Cmd Msg)
> update msg state = case msg of
> UpdateThis -> …
> UpdateThat -> …
>
> My problem is that the state can be either Loading or Displaying, but most 
> of the messages only make sense in the Displaying state, leading me to code 
> like this:
>
> update : Msg -> State -> (State, Cmd Msg)
> update msg state = case msg of
> UpdateThis -> case state of
> Displaying stuff -> …
> _ -> (Failed "Invalid state", Cmd.none)
> UpdateThat -> case state of
> Displaying stuff -> …
> _ -> (Failed "Invalid state", Cmd.none)
>
> Obviously, this is dumb. How can I “divide” the loading and the displaying 
> part of the app? (Assuming that UpdateThis and UpdateThat can only arrive 
> in the correct, Displaying state.)
>
> Thank you!
>
> T.
>

-- 
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] Re: My Argument for "Why Elm" please review before I present to my company

[Matthew Griffith]

Nice!

A few notes if you want them:)

Tests are VASTLY easier to write in elm because we have a guarantee of 
same-arguments-same-result, which means each piece can be tested 
independently.  And, like you said, you'll need fewer tests because of the 
type system.

You can have higher confidence in other people's code that's written in elm 
because of the basic guarantees that elm provides out of the box.   I.e. I 
have more confidence in the code of a beginner elm dev than in a mid level 
javascript dev because of the protections the language brings.  It's much 
harder for a beginner to shoot themselves in the foot in any meaningful way 
with Elm than with Javascript.  Similarly, having a standard code formatter 
and a standard architecture means that your beginners will likely start out 
writing code that is fast, well formatted, extensible, and easier to 
understand.

(small typo: Symantec -> semantic)





On Wednesday, January 11, 2017 at 4:42:09 PM UTC-5, Rupert Smith wrote:
>
> On Wednesday, January 11, 2017 at 8:28:01 PM UTC, Ossi Hanhinen wrote:
>>
>> Nice write-up! As it happens, I recently wrote a collection of thoughts 
>> in the same vein, and just published it as a blog post:
>> http://ohanhi.github.io/why-and-when-of-choosing-elm.html
>
>
> "What is Elm a poor fit for
>
> Mostly static pages (e.g. news websites)
> Sites that need server-side rendering"
>
> Admittedly I am going out on a limb here but... now that I've started 
> doing it I think Elm is great for rendering static content server-side. I 
> recently walked away from handlebars templates and won't be looking back. 
> One possibly major issue I am having with it is that running Elm under 
> Nashorn on Java 8 is slow as - but I could add some caching or run it under 
> Node, so its not a blocker for me.
>
> Server-side rendering is not officially supported but 
> elm-server-side-renderer does the job.
>

-- 
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] Re: The Style Elements Library: a different approach to styling

[Matthew Griffith]

Hello!

Essentially there are some things I'd like to do that I wouldn't be able to 
express in elm-css (With this being said, elm-css is super-awesome, and 
this style-elements library is still experimental).  I'm writing an article 
that goes more into detail but here's a general overview.  

First, this library is both about providing a better interface to CSS and 
sometimes _removing_ parts that generally only exist to cause trouble.  If 
this is just a collection of mixins for elm-css, then the library can't 
really "remove" a property.

Secondly, there's a new version of this library in the works that has a 
different approach to how we bind a style to an html element.  That may 
seem like there's only one way to do it (via classes), but I have an 
interesting approach to try out.  I'm hoping to have something working by 
mid-January to show what I mean.

Thirdly, I'm planning a sweet integration with elm-style-animation 
<https://github.com/mdgriffith/elm-style-animation> that can only be done 
if I, as a library, have complete control over if a style is rendered 
inline or as a stylesheet.  Actually the plan is to dynamically switch 
between the two based on what the user wants.

I really appreciate the interest :)





On Monday, January 2, 2017 at 2:58:03 PM UTC-5, Kadzuya OKAMOTO wrote:
>
> Awesome! I completely agree with the policy to simplify CSS.
>
> I guess the policy may be also realized by providing a set of functions in 
> a manner of `rtfeldman/elm-css`'s `Mixin`s.
> What is the dominant benefits of making another library rather than 
> providing set of `rtfeldman/elm-css` `Mixin`s?
>
>
> On Thursday, October 27, 2016 at 10:20:14 PM UTC+9, Matthew Griffith wrote:
>>
>>
>> It's easy to write valid CSS that is still broken and frustrating. What 
>> if we could make frustrating CSS styles not expressible?
>>
>> I've been working on an experimental style library for making styles that 
>> are harder to break and easier to use.
>>
>> There is also support for flow/flexbox style layouts, animations, 
>> transitions, and media queries.
>>
>> It takes a different approach on attaching styles to html nodes. Instead 
>> of using classes and ids, you create collections of styled html elements to 
>> pull from to build your view (with support for classList style variations 
>> that can be turned on/off).  
>>
>> Let me know your thoughts!
>>
>> Note:  I haven't published this on elm-package yet as I wanted to see if 
>> there was any feedback that might alter what 1.0 looks like.
>>
>> The Style Elements library <https://github.com/mdgriffith/style-elements>
>>
>> Simple Example 
>> <https://github.com/mdgriffith/elm-style-elements-simple-example>
>>
>> Complex Example 
>> <https://github.com/mdgriffith/elm-style-elements-complex-example>
>>
>

-- 
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] Re: The Style Elements Library: a different approach to styling

[Matthew Griffith]

Hey Lourens,

Sounds reasonable, I'll put it on the list of properties to consider for a
future release.  If you run into any other properties you tend to use often
but the lib doesn't support, add a note to this issue.
<https://github.com/mdgriffith/style-elements/issues/2>

Vendor prefixing doesn't currently happen but is planned.  In the meantime,
you can set it using `Style.property "user-select" "none"` and setting the
vendor prefixes in the same way: Style.property "-webkit-user-select"
"none".

-Matt

On Sat, Dec 31, 2016 at 10:21 AM, Lourens Rolograaf <rologr...@gmail.com>
wrote:

> Hi Matt,
>
> For using a div as if it were a button, I would like to make the
> caption-text un-selectable when there is any mousemovement during click.
> This could be done with vendor-prefixed `user-select: none` according
> https://stackoverflow.com/questions/826782/how-to-disable-text-selection-
> highlighting-using-css
> Any chance of this feature in Style-elements-lib?
>
> Thx
> Lawrence
>
> Op maandag 31 oktober 2016 16:04:24 UTC+1 schreef Matthew Griffith:
>
>> Yeah, this library is more about smart styling in elm rather than
>> interfacing with polymer.  Since we can do mixins in elm, native mixins
>> probably won't be supported :/
>>
>> I have thought that you could make a polymer or mdl type library in pure
>> elm using the style-elements library, though it would just cover the
>> styling/animation portion, not full behavior type stuff.
>>
>> You've probably seen the thread discussing elm and polymer, the result of
>> that discussion might fit your needs more closely once they finish.
>>
>>
>>
>>
>>
>> On Monday, October 31, 2016 at 9:40:37 AM UTC-4, Ed Ilyin wrote:
>>>
>>> yeah, but to use polymer elements, native css mixins are required :(
>>>
>>> Il giorno lun 31 ott 2016 alle ore 14:51 Matthew Griffith <
>>> mdg.gr...@gmail.com> ha scritto:
>>>
>>>> No, it won't render as a native css mixin, it just gives you the
>>>> functionality of a mixin in your elm code.
>>>>
>>>>
>>>>
>>>> On Monday, October 31, 2016 at 7:55:38 AM UTC-4, Ed Ilyin wrote:
>>>>
>>>>> Will it render native CSS mixin?
>>>>>
>>>>> Actually I can't figure out how to create native CSS mixins even using
>>>>> elm-css module.
>>>>>
>>>>> Il giorno lun 31 ott 2016 alle ore 13:49 Matthew Griffith <
>>>>> mdg.gr...@gmail.com> ha scritto:
>>>>>
>>>>>> You can create a mixin as a function.
>>>>>>
>>>>>>
>>>>>>
>>>>>> myMixin : Style.Model -> Style.Model
>>>>>> myMixin style =
>>>>>> { style
>>>>>> | visibility = hidden
>>>>>> }
>>>>>>
>>>>>> myMixinColor : Style.Model -> Style.Model
>>>>>> myMixinColor style =
>>>>>> { style
>>>>>> | colors = palette.blue
>>>>>> }
>>>>>>
>>>>>>
>>>>>> dropDown : List (Html.Attribute a) -> List (Element a) -> Element a
>>>>>> dropDown =
>>>>>> element
>>>>>> ({ base
>>>>>> | width = px 300
>>>>>> , padding = all 20
>>>>>> , spacing = topBottom 40
>>>>>>  }
>>>>>> |> myMixin
>>>>>> |> myMixinColor
>>>>>> )
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Monday, October 31, 2016 at 5:16:43 AM UTC-4, Ed Ilyin wrote:
>>>>>>
>>>>>>> I'm actively using Polymer Paper Elements. And they accept mixings
>>>>>>> like this:
>>>>>>> ```css
>>>>>>>   paper-dropdown-menu {
>>>>>>> --paper-input-container-input: {
>>>>>>>   color: white;
>>>>>>> }
>>>>>>> --paper-input-container-underline: {
>>>>>>>   display: none;
>>>>>>> }
>>>&g

[elm-discuss] Re: How to Modularize Big Files?

[Matthew Griffith]

This file shows how multiple animations can be run through one Animate Msg:

https://github.com/mdgriffith/elm-style-animation/blob/master/examples/Gears.elm


You basically make your subscription like this:

Animation.subscription Animate
[ model.annulus
, model.sun
, model.smallPlanet
, model.largePlanet
, model.mediumPlanet
]

And your Animate Msg in your update function would look like this:

Animate animMsg ->
let
annulus =
Animation.update animMsg model.annulus

sun =
Animation.update animMsg model.sun

smallPlanet =
Animation.update animMsg model.smallPlanet

mediumPlanet =
Animation.update animMsg model.mediumPlanet

largePlanet =
Animation.update animMsg model.largePlanet

global =
Animation.update animMsg model.global
in
( { model
| annulus = annulus
, sun = sun
, smallPlanet = smallPlanet
, mediumPlanet = mediumPlanet
, largePlanet = largePlanet
, global = global
  }
, Cmd.none
)


The only thing this buys you compared to breaking out every animation into 
a separate Msg, is that your update function may be a little shorter.  

So the way you're doing it is fine:)

Try compiling with '--warn', it'll tell you all the type signatures and you 
can copy paste :D  




On Friday, December 2, 2016 at 12:11:31 PM UTC-5, Rex van der Spuy wrote:
>
>
>
> On Friday, December 2, 2016 at 11:46:49 AM UTC-5, Matthew Griffith wrote
>>
>>
>> First, (and this is kinda unrelated to organization) but I'd recommend 
>> using elm-format and having type signatures.
>>
>
> ... guilty as charged! :)
> I actually could never get elm-format to integrate with Sublime Text 
> despite many attempts - no idea why.
> Type signatures... I'll try using them more often! (... the compiler 
> scares me sometimes, so I usually just let it try and figure all the types 
> out on its own.)
>  
>
>>
>>
>> Side note, you can combine all your animation subscriptions into one 
>> message.
>>
>
> Oh, I think this is something I fundamentally don't understand about 
> elm-style-animation.
> Could you point me to reference on how to set that up?
>

-- 
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] Re: How to Modularize Big Files?

[Matthew Griffith]

Hello!

Here are a few things I'd think about.

First, (and this is kinda unrelated to organization) but I'd recommend 
using elm-format and having type signatures.


Some quick thoughts:

You could break your styles into their own file, either using elm-css, or 
raw elm styles.

You could break Model out into it's own file and take related model 
processing functions there.

Side note, you can combine all your animation subscriptions into one 
message.




   




On Friday, December 2, 2016 at 11:32:56 AM UTC-5, Rex van der Spuy wrote:
>
> Hi Everyone,
>
> Over the past few months I've been follow the Best Practice 
> recommendations in Elm World to not use nested Model/Update/View modules.
> The general consensus seems to be just to keep one giant M/U/V engine 
> running, and farm out specialized work to helper functions.
> Cool, that make sense!
> Updating child modules is a big chore anyway that I'm happy not to have to 
> do.
>
> But, the "small" application that I'm working at the moment has now grown 
> to over 1000 lines of code.
> I'm starting to have to hunt for things, do a lot of scrolling, and I'm 
> forgetting how it's organized.
> And I realized I have absolutely no idea at all how to modularize it into 
> a sensible/understandable collection of smaller files.
>
> Can anyone help?
>
> Here's a code dump of what my main application code looks like so far:
>
> https://gist.github.com/kittykatattack/e30d860bbdfba57e0af2341c0c59552c
>
> (It's a kind of Eliza-like chat-bot - the code above won't run without 
> some dependencies that I haven't included, but hopefully it illustrates my 
> problem?)
> *Disclaimer: this is a work-in-progress and there is some redundant and, 
> frankly, plain bad code I need to clean up -- so please ignore my messy 
> work!!*
>
> But, can anyone recommend to me how I can organize this into a manageable 
> series of smaller files?
>
> The general way it's structured is:
>
> - imports
> - initial model
> - update (including update helper functions)
> - view (including css and elm-mdl components)
> - subscriptions
> - main app wiring
>
>
> Thanks, Everyone!
>
>
>

-- 
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] Re: Advantages of the module - exposing syntax

[Matthew Griffith]

I find exposing functions/types at the top gives a nice summary of what is 
exposed when reading a new module.  I can usually get a good idea of how 
the module works by seeing the names of the things that are exposed next to 
each other.  That would be harder to do if the exposed annotation is 
throughout the module.

I haven't really noticed the expose syntax as being a pain in 
refactoring/reorganization, though it is an additional step when moving, so 
I see your point.  However, in my experience the additional step is pretty 
trivial/quick to handle, especially with the compiler guiding you.

-Matt



On Wednesday, November 30, 2016 at 9:07:15 AM UTC-5, Martin Cerny wrote:
>
> Hi all,
> coming from Java, C++ and C#, I find the module X exposing (A,B,C) syntax 
> weird - to be short, it feels a bit like C/C++ header files, in that you 
> repeat entity names at multiple places, making refactoring harder. I 
> however guess the syntax was chosen for a reason - so I am asking: what are 
> the advantages of 
>
> module Foo exposing (bar)
>
> bar: Int
>
> over something like
>
> module Foo 
>
> exposed bar: Int
>
> Hope the answers will help me better understand Elm
>
> Thanks
> Martin
>

-- 
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] Re: ANN: style-elements v2 published

[Matthew Griffith]

Thanks everyone!

Hey Max!  I appreciate the feedback, I've updated the readme with your 
suggestions ++ some additional notes.

And some additional descriptions for the elm-package documentation will be 
there later today :)

You make a good point about renaming `Style.Model`, though I'm going to 
think about it for a bit.  The recommendation is for style to live in its 
own file, so it might not be a big issue.







On Monday, November 28, 2016 at 10:42:29 PM UTC-5, Max Goldstein wrote:
>
> Hi Matt! I looked at the documentation and these are my thoughts.
>
>
>- The last example has the Title line twice. Copypasta?
>- It looks like this only works well if Style is imported as a (..) 
>import. I think you make a good case for this usually-discouraged feature. 
>However, I think best practice would be to keep the stylesheet definitions 
>in their own module with no other (..) imports, and expose only the 
>rendered stylesheet and Class type. If you agree, maybe add this to the 
>README?
>- You should document the types defined at the top of the 
>documentation. What the heck do these represent? Maybe there's a better 
>name for Model since that's normally something the application author 
>defines as part of TEA (The Elm Architecture).
>- Maybe it would be helpful to see the rendered CSS for the 
>definitions in the README?
>
> Overall, great work!
>

-- 
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] Re: The Style Elements Library: a different approach to styling

[Matthew Griffith]

Yeah, this library is more about smart styling in elm rather than 
interfacing with polymer.  Since we can do mixins in elm, native mixins 
probably won't be supported :/

I have thought that you could make a polymer or mdl type library in pure 
elm using the style-elements library, though it would just cover the 
styling/animation portion, not full behavior type stuff.

You've probably seen the thread discussing elm and polymer, the result of 
that discussion might fit your needs more closely once they finish.





On Monday, October 31, 2016 at 9:40:37 AM UTC-4, Ed Ilyin wrote:
>
> yeah, but to use polymer elements, native css mixins are required :(
>
> Il giorno lun 31 ott 2016 alle ore 14:51 Matthew Griffith <
> mdg.gr...@gmail.com > ha scritto:
>
>> No, it won't render as a native css mixin, it just gives you the 
>> functionality of a mixin in your elm code.
>>
>>
>>
>> On Monday, October 31, 2016 at 7:55:38 AM UTC-4, Ed Ilyin wrote:
>>
>>> Will it render native CSS mixin?
>>>
>>> Actually I can't figure out how to create native CSS mixins even using 
>>> elm-css module.
>>>
>>> Il giorno lun 31 ott 2016 alle ore 13:49 Matthew Griffith <
>>> mdg.gr...@gmail.com> ha scritto:
>>>
>>>> You can create a mixin as a function.
>>>>
>>>>
>>>>
>>>> myMixin : Style.Model -> Style.Model
>>>> myMixin style =
>>>> { style
>>>> | visibility = hidden
>>>> }
>>>>
>>>> myMixinColor : Style.Model -> Style.Model
>>>> myMixinColor style =
>>>> { style
>>>> | colors = palette.blue
>>>> }
>>>>
>>>>
>>>> dropDown : List (Html.Attribute a) -> List (Element a) -> Element a
>>>> dropDown =
>>>> element
>>>> ({ base
>>>> | width = px 300
>>>> , padding = all 20
>>>> , spacing = topBottom 40
>>>>  }
>>>> |> myMixin
>>>> |> myMixinColor
>>>> )
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Monday, October 31, 2016 at 5:16:43 AM UTC-4, Ed Ilyin wrote:
>>>>
>>>>> I'm actively using Polymer Paper Elements. And they accept mixings 
>>>>> like this:
>>>>> ```css
>>>>>   paper-dropdown-menu {
>>>>> --paper-input-container-input: {
>>>>>   color: white;
>>>>> }
>>>>> --paper-input-container-underline: {
>>>>>   display: none;
>>>>> }
>>>>> --paper-dropdown-menu-icon: {
>>>>>   color: white;
>>>>> }
>>>>> --paper-input-container-focus-color: white;
>>>>>   }
>>>>> ```
>>>>> how to do the same using style-elements library?
>>>>>
>>>>> Il giorno ven 28 ott 2016 alle ore 19:34 Matthew Griffith <
>>>>> mdg.gr...@gmail.com> ha scritto:
>>>>>
>>>> So, taking a look at it, direct support for keyed will be super easy 
>>>>>> and will absolutely show up in v1.1.0.
>>>>>>
>>>>>> And I believe I have a way to directly support lazy as well, though I 
>>>>>> want to try it out before confirming completely.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Friday, October 28, 2016 at 12:28:17 PM UTC-4, Mark Hamburg wrote:
>>>>>>
>>>>>>> On Oct 28, 2016, at 7:28 AM, Matthew Griffith <mdg.gr...@gmail.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> 2.  You can use Keyed and Lazy on a parent element (the one created 
>>>>>>> by *Style.Elements.build*).  You could use *Style.Elements.build* in 
>>>>>>> a child view and then use *Style.Elements.html *to integrate it 
>>>>>>> into the main view, using keyed or lazy in the process.   That feels a 
>>>>>>> bit 
>>>>>>> roundabout and I believe there could be a better way.  I'll just have 
>>>>>>> to 
>>>>>>> give it some thought as to how it'd w

Re: [elm-discuss] Re: The Style Elements Library: a different approach to styling

[Matthew Griffith]

You can create a mixin as a function.



myMixin : Style.Model -> Style.Model
myMixin style =
{ style
| visibility = hidden
}

myMixinColor : Style.Model -> Style.Model
myMixinColor style =
{ style
| colors = palette.blue
}


dropDown : List (Html.Attribute a) -> List (Element a) -> Element a
dropDown =
element
({ base
| width = px 300
, padding = all 20
, spacing = topBottom 40
 }
|> myMixin
|> myMixinColor
)










On Monday, October 31, 2016 at 5:16:43 AM UTC-4, Ed Ilyin wrote:
>
> I'm actively using Polymer Paper Elements. And they accept mixings like 
> this:
> ```css
>   paper-dropdown-menu {
> --paper-input-container-input: {
>   color: white;
> }
> --paper-input-container-underline: {
>   display: none;
> }
> --paper-dropdown-menu-icon: {
>   color: white;
> }
> --paper-input-container-focus-color: white;
>   }
> ```
> how to do the same using style-elements library?
>
> Il giorno ven 28 ott 2016 alle ore 19:34 Matthew Griffith <
> mdg.gr...@gmail.com > ha scritto:
>
>> So, taking a look at it, direct support for keyed will be super easy and 
>> will absolutely show up in v1.1.0.
>>
>> And I believe I have a way to directly support lazy as well, though I 
>> want to try it out before confirming completely.
>>
>>
>>
>>
>> On Friday, October 28, 2016 at 12:28:17 PM UTC-4, Mark Hamburg wrote:
>>
>>> On Oct 28, 2016, at 7:28 AM, Matthew Griffith <mdg.gr...@gmail.com> 
>>> wrote:
>>>
>>> 2.  You can use Keyed and Lazy on a parent element (the one created by 
>>> *Style.Elements.build*).  You could use *Style.Elements.build* in a 
>>> child view and then use *Style.Elements.html *to integrate it into the 
>>> main view, using keyed or lazy in the process.   That feels a bit 
>>> roundabout and I believe there could be a better way.  I'll just have to 
>>> give it some thought as to how it'd work :).   
>>>
>>>
>>> Keyed as it turns out is central to getting stateful DOM elements to 
>>> behave reliably.
>>>
>>> But I'm looking forward to trying this library out.
>>>
>>> Mark
>>>
>>> -- 
>> 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 .
>> 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] Re: The Style Elements Library: a different approach to styling

[Matthew Griffith]

Great to hear and thanks! :)

1.  What you want to use here is *Style.Elements.optional*.  It functions a 
lot like *Html.Attributes.classList* if you've worked with that at all,  it 
allows you to define variations that you can switch on and off.  There's an 
example of it in the complex example 
<https://github.com/mdgriffith/elm-style-elements-complex-example>.

2.  You can use Keyed and Lazy on a parent element (the one created by 
*Style.Elements.build*).  You could use *Style.Elements.build* in a child 
view and then use *Style.Elements.html *to integrate it into the main view, 
using keyed or lazy in the process.   That feels a bit roundabout and I 
believe there could be a better way.  I'll just have to give it some 
thought as to how it'd work :).   



On Friday, October 28, 2016 at 9:54:55 AM UTC-4, Ed Ilyin wrote:
>
> I have started to use this library - for me it is perfect that I do not 
> have to generate css file anymore.
> Great work Matthew! :)
> Of course I have first questions:
> 1. For example, user taps on menu item. To show that item is selected I 
> have to replace element with different color element correct? How it is 
> from the performance point of view? Or I have to add Bool parameter to 
> element which contols color and text weight? What is the best practice?
> 2. What about Keyed and Lazy elements? Is it ok to use them with this lib?
>
> Il giorno ven 28 ott 2016 alle ore 14:58 Matthew Griffith <
> mdg.gr...@gmail.com > ha scritto:
>
>>
>> I'll have to think about it a bit to see if this could use the work from 
>> elm-css.  The two libraries have very different approaches, though it might 
>> be possible.  Or maybe this library will grow to have additional 
>> type-checking some other way.
>>
>> It is now published! 
>> http://package.elm-lang.org/packages/mdgriffith/style-elements/latest
>>
>>
>>
>>
>>
>> On Friday, October 28, 2016 at 2:46:51 AM UTC-4, Ed Ilyin wrote:
>>
>>> And, clould you please, publish it, so we can try it easly and follow 
>>> updates.
>>>
>>> Il giorno ven 28 ott 2016 alle ore 06:54 Ed Ilyin <eduard...@gmail.com> 
>>> ha scritto:
>>>
>> Is it possible to blend it together with Richard Feldman's work elm-css 
>>>> where all properties are type checked?
>>>>
>>>> Il giorno gio 27 ott 2016 alle ore 23:54 Matthew Griffith <
>>>> mdg.gr...@gmail.com> ha scritto:
>>>>
>>> Thanks!  Feedback would be fantastic.  
>>>>>
>>>>> Yes, the compiler should help quite a bit here, however styling is 
>>>>> tough because it has quite a few "gotchas", so its hard to know 100%.
>>>>>
>>>>> Also, this library is mostly concerned with a small set  of css 
>>>>> properties(~15-20) that cause the most trouble.  Beyond that you're free 
>>>>> to 
>>>>> add whatever you need.  Of course, that means those additional style 
>>>>> properties you add are not type checked, they're just strings.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, October 27, 2016 at 4:16:22 PM UTC-4, Fed Reggiardo wrote:
>>>>>>
>>>>>> Looks great!!  Nice work.  Im getting ready to style a new website, 
>>>>>> will try it out, and send some feedback. Quick question, will the 
>>>>>> compiler 
>>>>>> catch any errors on this?
>>>>>>
>>>>>> thx!
>>>>>>
>>>>> -- 
>>>>> 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.
>>>>
>>>>
>>>>> 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 .
>> 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] Re: The Style Elements Library: a different approach to styling

[Matthew Griffith]

I'll have to think about it a bit to see if this could use the work from 
elm-css.  The two libraries have very different approaches, though it might 
be possible.  Or maybe this library will grow to have additional 
type-checking some other way.

It is now 
published! http://package.elm-lang.org/packages/mdgriffith/style-elements/latest





On Friday, October 28, 2016 at 2:46:51 AM UTC-4, Ed Ilyin wrote:
>
> And, clould you please, publish it, so we can try it easly and follow 
> updates.
>
> Il giorno ven 28 ott 2016 alle ore 06:54 Ed Ilyin <eduard...@gmail.com 
> > ha scritto:
>
>> Is it possible to blend it together with Richard Feldman's work elm-css 
>> where all properties are type checked?
>>
>> Il giorno gio 27 ott 2016 alle ore 23:54 Matthew Griffith <
>> mdg.gr...@gmail.com > ha scritto:
>>
>>> Thanks!  Feedback would be fantastic.  
>>>
>>> Yes, the compiler should help quite a bit here, however styling is tough 
>>> because it has quite a few "gotchas", so its hard to know 100%.
>>>
>>> Also, this library is mostly concerned with a small set  of css 
>>> properties(~15-20) that cause the most trouble.  Beyond that you're free to 
>>> add whatever you need.  Of course, that means those additional style 
>>> properties you add are not type checked, they're just strings.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thursday, October 27, 2016 at 4:16:22 PM UTC-4, Fed Reggiardo wrote:
>>>>
>>>> Looks great!!  Nice work.  Im getting ready to style a new website, 
>>>> will try it out, and send some feedback. Quick question, will the compiler 
>>>> catch any errors on this?
>>>>
>>>> thx!
>>>>
>>> -- 
>>> 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 .
>>> 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] Re: The Style Elements Library: a different approach to styling

[Matthew Griffith]

Thanks!  Feedback would be fantastic.  

Yes, the compiler should help quite a bit here, however styling is tough 
because it has quite a few "gotchas", so its hard to know 100%.

Also, this library is mostly concerned with a small set  of css 
properties(~15-20) that cause the most trouble.  Beyond that you're free to 
add whatever you need.  Of course, that means those additional style 
properties you add are not type checked, they're just strings.












On Thursday, October 27, 2016 at 4:16:22 PM UTC-4, Fed Reggiardo wrote:
>
> Looks great!!  Nice work.  Im getting ready to style a new website, will 
> try it out, and send some feedback. Quick question, will the compiler catch 
> any errors on this?
>
> thx!
>

-- 
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] The Style Elements Library: a different approach to styling

[Matthew Griffith]

It's easy to write valid CSS that is still broken and frustrating. What if 
we could make frustrating CSS styles not expressible?

I've been working on an experimental style library for making styles that 
are harder to break and easier to use.

There is also support for flow/flexbox style layouts, animations, 
transitions, and media queries.

It takes a different approach on attaching styles to html nodes. Instead of 
using classes and ids, you create collections of styled html elements to 
pull from to build your view (with support for classList style variations 
that can be turned on/off).  

Let me know your thoughts!

Note:  I haven't published this on elm-package yet as I wanted to see if 
there was any feedback that might alter what 1.0 looks like.

The Style Elements library 

Simple Example 


Complex Example 


-- 
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] Re: Getting functions out of the model

[Matthew Griffith]

So it's not necessarily not having interruptible animations, it's more all 
the code that you'll need to manage them.  

In elm-style-animation you can just start a new animation and interruptions 
are handled automatically.

When you have description and state split, you have to juggle switching out 
the animationDescription at the right time.

view model =
  animate animationDescription model.animationState

becomes the following when you have multiple possible animation 
descriptions.  Lets say we have model.animId to keep track of what 
description is running so we can switch between them.


view model =
let 
myAnimationDescription = lookup model.animId
in
animate animationDescription model.animationState

Easy peasy.  

What about when you want to have a delay and then an interruption, you have 
to keep track of the delay and switching out animationDescription when the 
interruption occurs.  Great, we can do that.

You also have to implement logic that handles what happens when multiple 
delayed interruptions are queued up.  So now you have a queue of animation 
interruptions to manage.  Ok then.

Basically all of this is totally writable code...it's just that that's a 
large part of the built in functionality of the elm-style-animation 
library.  Why write all that code if a library handles it out of the box?














On Thursday, October 13, 2016 at 3:25:17 PM UTC-4, Zinggi wrote:
>
> @Frederick
> Yes, that's where I got my inspiration from ;)
>
> @Matthew
> I don't think this is a problem, but I also don't understand what you mean 
> by "you'd have to do all the interruptions manually".
> Could you elaborate?
> I haven't studies your library closely, so I don't know how your library 
> currently deals with interruptions.
>
> I once created an animation library for react 
> , it kinda works like I described 
> above and it does have interruptable animations.
> But of course react doesn't map nicely to elm.
>
>
> On Thursday, 13 October 2016 21:02:29 UTC+2, Frederick Yankowski wrote:
>>
>> The elm-autocomplete package does something much like you describe. 
>> Configuration data, including some functions, is defined separately from 
>> the model and is passed as an additional parameter to the update function.
>>
>>
>> https://github.com/thebritican/elm-autocomplete/blob/4.0.1/src/Autocomplete.elm#L181
>>
>> On Thursday, October 13, 2016 at 1:34:29 PM UTC-5, Zinggi wrote:
>>
>> I think it would be nice to separate the *descriptions* of an animation 
>>> from the *state* of an animation.
>>>
>> ​
>>
>

-- 
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] Re: Getting functions out of the model

[Matthew Griffith]

That's interesting as well.  Though I think you'd run into challenges when 
trying to handle interruptible animations. Specifically you'd have to do 
all the interruptions manually.  This would be even more challenging in the 
context of interruptions that have a delay before they're supposed to 
interrupt.


On Thursday, October 13, 2016 at 2:34:29 PM UTC-4, Zinggi wrote:
>
> I also thought about this problem for a bit.
> I came up with a slightly different solution.
>
> I was not only not happy with storing functions in my model, but also with 
> storing static values in the model (e.g. stuff that wont change often).
> I think it would be nice to separate the *descriptions* of an animation 
> from the *state* of an animation.
>
> So when you actually use an animation, you need to provide an animation 
> description and an animation state, this might look kinda like this:
>
> model =
>   { animationState = Animation.new 0 }
>
> update msg model =
>   case msg of
> Tick dt ->
>   { model | animationState = Animation.tick dt model.animationState }
>
> animationDescription =
>   { startValue = 0, endValue = 10, speed = 2, easing = Easing.sinInOut, 
> etc... }
>
> view model =
>   animate animationDescription model.animationState
>
>
> On Thursday, 13 October 2016 08:29:19 UTC+2, Aaron VonderHaar wrote:
>>
>> As mentioned in some recent threads [1] [2], easing functions for 
>> animations have been an example of where functions in the model are 
>> currently used.  An alternative approach is to use a union type to indicate 
>> the easing, but a suggested shortcoming of that approach is that there 
>> would then be no way for downstream developers to use their own custom 
>> easings.
>>
>> I was just thinking that this could be achieved as follows:
>>
>> ```
>> type AdvancedEasing a
>> = Linear | InQuad | OutQuad | ...
>> | CustomEasing a
>>
>> type alias Easing = AdvancedEasing Never
>>
>> apply : Easing -> Float -> Float
>>
>> applyAdvanced : (a -> Float -> Float) -> AdvancedEasing a -> Float -> 
>> Float
>> ```
>>
>> In this way, the custom easing functions (a -> Float -> Float) are moved 
>> from the model to configuration.
>>
>> I was curious if anyone has experimented with this approach yet.
>>
>>
>> [1]: https://groups.google.com/d/topic/elm-discuss/bOAHwSnklLc/discussion
>> [2]: https://groups.google.com/d/topic/elm-discuss/9qV9iDcv-c8/discussion
>>
>>

-- 
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] Re: using js library inside elm?

[Matthew Griffith]

You still have to use ports.  Check out the SpellCheck part of this 
https://guide.elm-lang.org/interop/javascript.html

On Thursday, October 13, 2016 at 5:00:47 AM UTC-4, António Ramos wrote:
>
> hello i know that i have to use ports to pass data from elm to javascript 
> but if i want to call an external  library method inside my elm is there a 
> way to do it?
> As i load my exeternal js file before my compiled elm in my index.html 
> file there should be a way right?
>
> regards
> António
>

-- 
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] Re: Getting functions out of the model

[Matthew Griffith]

That's an interesting approach, though I'm not sure it would work for 
elm-style-animation, at least in its current form.   In elm-style-animation 
you compose an animation under one Msg, and send animation 
updates(basically tick the animation forward) via a separate Msg.  

The `apply` and `applyAdvanced` functions would have to live in the 
animation update Msg in order for them to work and not store anything in a 
model, but choosing an easing is conceptually part of composing an 
animation, not updating it. 
As a sidenote, an animation in elm-style-animation can have any number of 
separate easings used in different stages of the animation.  This 
complicates things a bit for an implementation.

```
Animation.interrupt
 [ Animation.toWith {duration=(1*second), easing=identity)}
[opacity 0]
, Animation.toWith {duration=(1*second), easing=(\x -> x^2)}
[opacity 0]
]

```






On Thursday, October 13, 2016 at 2:29:19 AM UTC-4, Aaron VonderHaar wrote:
>
> As mentioned in some recent threads [1] [2], easing functions for 
> animations have been an example of where functions in the model are 
> currently used.  An alternative approach is to use a union type to indicate 
> the easing, but a suggested shortcoming of that approach is that there 
> would then be no way for downstream developers to use their own custom 
> easings.
>
> I was just thinking that this could be achieved as follows:
>
> ```
> type AdvancedEasing a
> = Linear | InQuad | OutQuad | ...
> | CustomEasing a
>
> type alias Easing = AdvancedEasing Never
>
> apply : Easing -> Float -> Float
>
> applyAdvanced : (a -> Float -> Float) -> AdvancedEasing a -> Float -> Float
> ```
>
> In this way, the custom easing functions (a -> Float -> Float) are moved 
> from the model to configuration.
>
> I was curious if anyone has experimented with this approach yet.
>
>
> [1]: https://groups.google.com/d/topic/elm-discuss/bOAHwSnklLc/discussion
> [2]: https://groups.google.com/d/topic/elm-discuss/9qV9iDcv-c8/discussion
>
>

-- 
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] Re: Simple Fade In/Out effect?

[Matthew Griffith]

Oh!  You need to add the animation subscription as well.

Sub.batch this with your current subscriptions

subscriptions : Model -> Sub Msgsubscriptions model =
Animation.subscription Animate [ model.storyTextStyle ]


On Tuesday, October 4, 2016 at 9:28:25 AM UTC-4, Rex van der Spuy wrote:
>
> Thanks Mathew!!
> I've added your code suggestion, but so far no luck yet (FadeInOut is 
> called, but not SendStoryComponents)
>
> If anyone wants to take a look at the current Main.elm file where all this 
> code is running, it's here:
>
> https://gist.github.com/kittykatattack/f05b42efc6ecf09ddf244bbafd18edb3
>
>
> On Monday, October 3, 2016 at 5:24:43 PM UTC-4, Matthew Griffith wrote:
>>
>> In your `Animate animMsg` area, you're not returning the cmds, which is 
>> how the msg is fired :).
>>
>> Change your code to this:
>>
>> Animate animMsg ->
>>   let 
>> (newStyle, cmds) = 
>>   Animation.Messenger.update
>> animMsg
>> model.storyTextStyle
>>   in
>>  ( { model
>> | storyTextStyle = newStyle
>>}
>>  , cmds
>> )
>>
>>
>>
>> On Monday, October 3, 2016 at 2:09:57 PM UTC-4, Rex van der Spuy wrote:
>>>
>>> Thanks everyone, I like these ideas!
>>>
>>> Here's what I've got so far - but it's not working... yet! :) 
>>> Could any of you with more experience with elm-style-animation let me 
>>> know what I'm doing wrong?
>>>
>>> I've imported Animation and Animation.Messener, exposing State:
>>>
>>> ```
>>> import Animation
>>> import Animation.Messenger exposing (State)
>>> ```
>>>
>>> I created a style for my text called `storyTextStyle`
>>>
>>> ```
>>>  , storyTextStyle : Animation.Messenger.State Msg
>>>
>>> , storyTextStyle = 
>>>   Animation.style
>>> [ Animation.opacity 1.0
>>> ]
>>>
>>> ```
>>> I added it to the view, which displays my story output text
>>>
>>> ```
>>> div [ storyCardStyle ] 
>>> [ p ( Animation.render model.storyTextStyle ++ [ 
>>> storyParagraphStyle ]) [ text model.storyOutput ] ]
>>> ```
>>>
>>> I have an MDL button that triggers a `FadeInOut` update message:
>>>
>>> ```
>>> , Button.onClick FadeInOut
>>> ```
>>>
>>> The `FadeInOut` message and `Animate` message are in the `update` 
>>> function:
>>>
>>> ``` 
>>> Animate animMsg ->
>>>   let 
>>> (newStyle, cmds) = 
>>>   Animation.Messenger.update
>>> animMsg
>>> model.storyTextStyle
>>>   in
>>>  { model
>>>  | storyTextStyle = newStyle
>>>  }
>>>  ! [ ]
>>>
>>> FadeInOut -> 
>>>   let
>>> newStyle =
>>>   Animation.interrupt
>>> [ Animation.to [Animation.opacity 0]
>>> , Animation.Messenger.send SendStoryComponents
>>> , Animation.to [Animation.opacity 1]
>>> ]
>>> model.storyTextStyle
>>>   in
>>>   { model
>>>   | storyTextStyle = newStyle
>>>   }
>>>   ! [ ]
>>> ```
>>>
>>> ... all this compiles and I've tested `FadeInOut` with Debug.crash to 
>>> make sure it's called - and it is definitely being called when I click the 
>>> button.
>>> But, my `SendStoryComponents`, which generates the new text to fade is, 
>>> is never called.
>>> Here's `SendStoryComponents` (it uses a port that does some fun stuff 
>>> with nlp-compromise.js to generate a random story based on user input and 
>>> story templates)
>>>
>>> ```
>>> SendStoryComponents ->
>>>   let
>>> words = 
>>>   model.words
>>>
>>> toList string =
>>>   String.Extra.clean string
>>>   |> String.split " "
>>>
>>>
>>> words' =
>>>   { places = toList model.places 
>>>   , livingThings = toList model.livingThings
>>>   , objects = toList model.objects
>>>   , actions = toList model.actions
>>>   , moods = toList model.moods
>>>   }
>>>
>>> model' =
>>>   { model 
>>>   | words = words'
>>>   }
>>>   in
>>>   (model', sendStoryComponents(model'.words, StoryTemplates.stories))
>>> ```
>>> (`SendStoryComponents` does work, if I don't call it through the 
>>> `FadeInOut` message.)
>>>
>>> Can anyone tell by looking at that why `Animation.Messenger.send` might 
>>> not be calling `SendStoryComponents` ?
>>>
>>

-- 
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] Re: Simple Fade In/Out effect?

[Matthew Griffith]

In your `Animate animMsg` area, you're not returning the cmds, which is how 
the msg is fired :).

Change your code to this:

Animate animMsg ->
  let 
(newStyle, cmds) = 
  Animation.Messenger.update
animMsg
model.storyTextStyle
  in
 ( { model
| storyTextStyle = newStyle
   }
 , cmds
)



On Monday, October 3, 2016 at 2:09:57 PM UTC-4, Rex van der Spuy wrote:
>
> Thanks everyone, I like these ideas!
>
> Here's what I've got so far - but it's not working... yet! :) 
> Could any of you with more experience with elm-style-animation let me know 
> what I'm doing wrong?
>
> I've imported Animation and Animation.Messener, exposing State:
>
> ```
> import Animation
> import Animation.Messenger exposing (State)
> ```
>
> I created a style for my text called `storyTextStyle`
>
> ```
>  , storyTextStyle : Animation.Messenger.State Msg
>
> , storyTextStyle = 
>   Animation.style
> [ Animation.opacity 1.0
> ]
>
> ```
> I added it to the view, which displays my story output text
>
> ```
> div [ storyCardStyle ] 
> [ p ( Animation.render model.storyTextStyle ++ [ 
> storyParagraphStyle ]) [ text model.storyOutput ] ]
> ```
>
> I have an MDL button that triggers a `FadeInOut` update message:
>
> ```
> , Button.onClick FadeInOut
> ```
>
> The `FadeInOut` message and `Animate` message are in the `update` function:
>
> ``` 
> Animate animMsg ->
>   let 
> (newStyle, cmds) = 
>   Animation.Messenger.update
> animMsg
> model.storyTextStyle
>   in
>  { model
>  | storyTextStyle = newStyle
>  }
>  ! [ ]
>
> FadeInOut -> 
>   let
> newStyle =
>   Animation.interrupt
> [ Animation.to [Animation.opacity 0]
> , Animation.Messenger.send SendStoryComponents
> , Animation.to [Animation.opacity 1]
> ]
> model.storyTextStyle
>   in
>   { model
>   | storyTextStyle = newStyle
>   }
>   ! [ ]
> ```
>
> ... all this compiles and I've tested `FadeInOut` with Debug.crash to make 
> sure it's called - and it is definitely being called when I click the 
> button.
> But, my `SendStoryComponents`, which generates the new text to fade is, is 
> never called.
> Here's `SendStoryComponents` (it uses a port that does some fun stuff with 
> nlp-compromise.js to generate a random story based on user input and story 
> templates)
>
> ```
> SendStoryComponents ->
>   let
> words = 
>   model.words
>
> toList string =
>   String.Extra.clean string
>   |> String.split " "
>
>
> words' =
>   { places = toList model.places 
>   , livingThings = toList model.livingThings
>   , objects = toList model.objects
>   , actions = toList model.actions
>   , moods = toList model.moods
>   }
>
> model' =
>   { model 
>   | words = words'
>   }
>   in
>   (model', sendStoryComponents(model'.words, StoryTemplates.stories))
> ```
> (`SendStoryComponents` does work, if I don't call it through the 
> `FadeInOut` message.)
>
> Can anyone tell by looking at that why `Animation.Messenger.send` might 
> not be calling `SendStoryComponents` ?
>

-- 
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] Re: Simple Fade In/Out effect?

[Matthew Griffith]

That's a pretty reasonable way to do it.  Another option could be could be 
to use one div and use `Animation.send`.   Basically you could do something 
like this.


```
Animation.interrupt
[ Animation.to [Animation.opacity 0]
, Animation.send DoneFadingOutOldTextPleaseSwitchModelToNewText
, Animation.to [Animation.opacity 1]
]
```

In this case you'd have to keep new text in a 'staging area' in your model 
and then switch it in when DoneFadingOutOldTextPleaseSwitchModelToNewText 
fires.


On Friday, September 30, 2016 at 2:30:53 PM UTC-4, Rex van der Spuy wrote:
>
> Hi Everyone!
>
> Just a quick question: Can anyone suggest a simple way to fade out some 
> old text and fade in some new text when a `model.text` value changes?
>
> I did this once a few apps ago where I created 2 `div` layers: 
> `currentText` and `previousText`
> Then, when the text value changed, I moved the text to the previousText 
> layer and faded it out, and then displayed the updated text on the 
> currentText layer and faded it in.
> (I used `elm-html-animation` for the fade effect.)
>
> Does this seem reasonable or is there a better, easier way?
>

-- 
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] Re: Moving Color to evancz/graphics

[Matthew Griffith]

elm-style-animation accepts the Color types from core as arguments for 
color property animations. So does my color mixing library (though who 
knows how many people use that :)  I'm working on another library that 
utilizes it as well.

Having a centralized idea of color seems like a pretty basic and useful 
thing to me, even if two prominent libraries don't use it directly.  Moving 
it to evancz/graphics means I have to either make my users depend on 
evancz/graphics(which doesn't make a ton of sense as they're probably using 
the html/svg libraries), or it means that every library that wants to work 
with color has to export their own type, which seems a bit much as well.

So, I guess I'm happy where it is:)

-Matt










On Thursday, September 29, 2016 at 4:17:38 PM UTC-4, Nick H wrote:
>
> P.S. If this sounds like a good idea, I am happy to do the work.
>
> On Thu, Sep 29, 2016 at 1:16 PM, Nick H  > wrote:
>
>> Hi everybody,
>>
>> Since 0.18 is going to involve some module juggling in core, I thought 
>> this would be a good time to bring this up.
>>
>> This is a follow-up to an elm-discuss thread from last month. Robin 
>> argued that the Color module should not be in elm-lang/core. I agreed and 
>> suggested that it be moved to evancz/graphics.
>>
>> For me the strongest indicator that Color doesn't belong in core is to 
>> look at who depends on it. Neither of the UI-related elm-lang packages 
>> (html, svg) use it. elm-css and elm-mdl both define their own color types.
>>
>> The only library that operates well with Color is evancz/graphics. 
>> Furthermore, it is the only one that can use the entire thing. The Gradient 
>> type is opaque, so it's impossible for anyone but evancz/graphics to use it.
>>
>> I hate to suggest "one more thing" to add to the release, but it feels 
>> like low-hanging fruit. I'm sure there is a reason Color stayed behind when 
>> Graphics was extracted. One way or the other, it should be easy to decide. 
>> And if it makes sense to move it, the lack of dependencies means the change 
>> would be easy to implement.
>>
>> Thanks for humoring me,
>>
>> ~Nick
>>
>
>

-- 
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] ANN: elm-style-animation v3.0.0

[Matthew Griffith]

Awesome!


So, `Animation.speed` was made to handle the specific case of getting a 
reasonable default for rotating things.  It's not really intended to be 
used widely...but Im still open to hearing use cases :)

First, heres why `Animation.speed` is present in the library at all and why 
its only used as the default interpolation for rotation. 

Lets say I tell something to "Rotate 872 degrees" vs saying "Rotate 36 
degrees".  It's actually pretty reasonable to assume that it will have the 
same speed to go to each value.  However you can't achieve that result with 
duration + easing (where the duration for both of those rotations would be 
the same, making one ridiculously fast.)  You also can't use springs in 
this situation because it looks pretty weird.  The duration is just however 
long it takes to get to the target value at that speed.

Now that I've given you way too information on that subject:)  lets talk 
about what you are actually trying to do.

I'm assuming you're literally animating some number of drops per second?

The basic way to approach it would be to just using duration + easing

Something like

Animation.interrupt 
[ Animation.loop
[ Animation.toWith 
(easing { ease = identity
, duration = 0.33 * second
}
)
[ top (percent 100)
]
, Animation.set 
[ top (percent 0)
]
]
]

Though in real life the drops will always fall at the same speed, so we 
could have a `Animation.wait` step in there that varies.  So you could find 
what the duration is for a drop that feels the most natural and just vary 
the wait step to fill the spaces between.

Or, alternatively, don't worry about creating a looping animation.  Get a 
time subscription  and just worry about starting an animation every nth 
milliseconds. 

So, every time period, just run:

Animation.interrupt 
[ Animation.set 
[ top (percent 0)
]
, Animation.to
[ top (percent 100)
]
]

It'll only run into issues if you try to animate them too fast :)

Hopefully all this helps!














On Wednesday, September 21, 2016 at 5:34:31 PM UTC-4, Brian Marick wrote:
>
>
> > On Sep 21, 2016, at 4:19 PM, Brian Marick  > wrote: 
> > 
> > This is working nicely for me, a CSS (and animation newbie). Naive 
> question: what is the relationship between `Animation.speed {perSecond : 
> Float}` and the duration of the animation (or the `animation-duration` 
> property)? 
>
> To put this into context: I need to produce an animation in support of 
> exercises on setting up IV drops. I need to implement phrases like “3 drops 
> per second”.

-- 
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] ANN: elm-style-animation v3.0.0

[Matthew Griffith]

v3.0.0 of the elm-style-animation library has been released!

https://github.com/mdgriffith/elm-style-animation

This version was a major rethink and rewrite of the API.  Things are now 
list based instead of pipe based which simplifies animation creation quite 
a bit.

Beyond the new api, here are some new features.

   - send your own message at any step in the animation
   - animate css filters!   Have an image turn to greyscale.  Have an 
   animated blur.
   - animate shadows!  All of them:  text shadows, box shadows, inset 
   shadows


I also gave a lightning talk at elm-conf about this version
https://www.youtube.com/watch?v=DsDwYqsLU3E

(as a side note, elm-conf was very awesome. Such an interesting set of 
talks, which are all here and worth your 
while: https://www.youtube.com/playlist?list=PLglJM3BYAMPH2zuz1nbKHQyeawE4SN0Cd)


-- 
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] Re: Elm Package Skimmer

[Matthew Griffith]

Thanks!

Good catch.  It should be updated now :)  (it was only looking at the 
github summary but not the elm-package description)

On Sunday, August 28, 2016 at 1:32:35 PM UTC-4, Max Goldstein wrote:
>
> Wow, this is amazing!
>
> Quick bug report: elm-check says that it's deprecated but isn't marked as 
> such.
>

-- 
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] Re: Server Side Rendering with Node

[Matthew Griffith]

Hi Robert,

Check out: https://github.com/eeue56/elm-static-site

Also, it looks like server side rendering is on the docket for the next 
major revision of elm, 0.18 - 
https://groups.google.com/forum/#!topic/elm-dev/u66_K3AbqIM




On Sunday, August 28, 2016 at 1:09:46 PM UTC-4, Robert S wrote:
>
> Hey, I'm going to move my 23KLOC (Coffeescript) angular 1.5 SPA 
> application to... primarily React+Redux, but I found elm and I'm reviewing 
> if it fits my requirements.
>
> *My first concern is Server Side Rendering (SSR) for SEO and fast page 
> loading. *
> I found https://github.com/NoRedInk/take-home but as I see it is approach 
> to replace PHP with ELM, than to provide SSR for single page app. 
> Also there is 
> http://blog.overstuffedgorilla.com/server-side-elm-with-phoenix/ with 
> source at https://github.com/hassox/phoenix_elm
> but I can't get it to work and evaluate with Windows 10... What's more I 
> completely don't understand what's going on there... Elixir is a black 
> magic for me :/
>
> Is there any way for production application to render with Node? The best 
> would be with precompiled elm? Without this I'll have to drop ELM and go 
> with React :(
>

-- 
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] Re: Impressions from a new user

[Matthew Griffith]

Hi Matthieu,

Welcome to elm!  I too have a background in Python and here are some things 
I've learned as I've written projects in elm.

You're right it is more verbose in a lot of cases.  What you get in a lot 
of cases is that it's very clear what's going on while in python there can 
be a decent amount of 'hiding the magic'.

As for Dicts, I would say double check to make sure you don't actually want 
a record.  Basically if you know all the fields at compile time...you 
probably want a record, not a dict. 

(as previous people have noted)  a few of your issues are definitely on the 
community radar.  There's a recent post about proposed string 
interpolation, stuff like that.  So, there's actually a good amount of work 
going on to cover the cases you mention.  It's a young language.


The list comprehension thing is interesting.  In elm the focus is on the 
List module as opposed to a specific syntax for list comprehensions.  I've 
found it to be very expressive.

So for something like `[i +5 for i in range(20)]`  in python, you could do 
something like `List.map ((+) 5) [0..20]`

Cheers and again, welcome to elm.

-Matt








On Thursday, June 23, 2016 at 1:06:28 PM UTC-4, Matthieu Amiguet wrote:
>
> Thanks Ian for your suggestions! 
>
> As for pulling the common code into another function, my threshold is 
> probably still the python one ;-) 
>
> But I finally adopted your solution with the helper function defined in a 
> let expression. That's already much better than my initial code! 
>
>  let 
>  formatTime time = 
>  String.pad 2 '0' <| toString time 
>  in 
>String.join ":" [formatTime (hour date), formatTime (minute date)] 
>
> Thanks, 
>
> Matthieu 
>
> > 1. You could try 
> http://package.elm-lang.org/packages/mgold/elm-date-format/1.1.4/ if 
> you're not opposed to using a third party package. 
> > 2. Or pull the duplicate code out into a function: 
> > | 
> > formatTime :Int->String 
> > formatTime time = 
> > String.pad 2'0'<|toString time 
> > 
> > anddo 
> > String.join ":"[formatTime (hour date),formatTime (minute date)] 
> > | 
> > 
> > That's still not quite as tidy as string interpolation but I've found 
> it's a good habit to get into to pull anything you do more than once out 
> into its own function, especially in Elm; in Python my threshold tends to 
> be three uses :) 
> > 
>

-- 
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] [ANN] Elm Style Animation v 1.0.0 - Now with SVG animations

[Matthew Griffith]

Hi All,

I just released a fairly large update I've been working on.

https://github.com/mdgriffith/elm-style-animation

First off, elm-html-animation has been renamed* elm-style-animation* 
because it now covers SVG animations as well as html styles.  

This is for elm 0.17.  If you use this library and think you're going to be 
on 0.16 for a while, let me know and I'll see what I can do to provide a 
temporary 0.16 version.  

So what's new?

   - The syntax for specifying animations now is cleaner and more powerful. 
You can use standard elm machinery like List.map and List.indexedMap to do 
   things like stagger animations or animate a list of things.  This is much 
   better than before.  
   - Native support for Elm's Color type.
   - SVG attributes can now be animated!
   - You can morph polygons into each other 
   . 
   - You can morph batman logos into each other. 
    Cause 
   this is what you really wanted to do with elm.
   - The flowermenu 
    from 
   before is now even cleaner









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