add sass version

[kukac7]

No description provided.

[desandro]

Thanks for taking a look here. Flickity CSS is written in plain ol' CSS, which makes it accessible for whatever CSS processor you are using.

I'll leave this PR open for a bit in case others find it useful.

[imaginamundo]

https://gist.github.com/imaginamundo/c2c8ef8e8b191e45ef90

Need to create the variables, but it is a start.

Thanks for the awesome plugin.

[zslabs]

@desandro If we are going to use a pre-processor, I'd lean on something like Less. Not because of my personal preference, but because of the tools available out there; like this one from UIkit to convert that to SASS automatically. I'd also like to see Less hooks integrated, which will provide pluggable selectors for Flickity.

I'm more than happy to lead this effort, but this makes Flickity possible to extend via Less, Sass, or vanilla CSS. Thanks!

[impsart]

+1 for pre-processors. Doesn't matter if Sass or Less. :)

[silvenon]

Why Sass/Less version? You should always strive towards plain CSS if possible.

[zslabs]

@silvenon Until sass/sass#193 is implemented, it'd be silly to require this package via bower and then have to manually copy in the styles in order to compile with your main app's styles. Even if that is implemented; if you can have a build tool that can satisfy Less/Sass (including variables for spacing and sizing which Flickity has A LOT of) along with a built CSS file, why would you not? Think you're missing the boat on this.

Otherwise you're overriding package defaults when you could have a more precise built file with what you customized.

[silvenon]

But would rewriting the CSS for a preprocessor make it better? Wouldn't you then have to configure Flickity in two places? Also, which preprocessor to choose and why?

I don't think CSS should be rewritten with a preprocessor just because currently there might not be a good way to consume it, instead we should push for that solution. I'm pretty new to the Browserify scene, but I think there might be some transforms for that?

[zslabs]

If you "start" with a preprocessor, then your build task; whether it's Grunt or Gulp, can automatically create the "other" preprocessor and the CSS file. The CSS file will have the defaults while the respective preprocessor will provide the flexibility to change said defaults and make it easier to integrate into their project all the while being able to keep not only the JS, but the styles behind it up to date with minimal effort when running bower update.

[silvenon]

This is the situation I'm currently in. I started with SASS + JS, but I realized there are a couple of things wrong with that setup:

1. In order to use the plugin I had to configure both SASS and JS, where ideally the user should have to configure only one.
2. Users using plain CSS will not be able to configure the plugin fully.
3. Guesswork around vendor prefixes is undesirable. But I guess this isn't really solvable anyway, maybe with PostCSS + adding inline CSS with JS, but I haven't tried it.
4. Duplicate code, only to accommodate a situation where a better solution should (and probably does) exist.

However, things get weird when @media queries are involved. Anyway, this was my experience.

[zslabs]

I can certainly relate to having a system that needs to work with different setups, but to address each of your points:

1. That's the beauty of a build-system like Grunt or Gulp. Frameworks like UIkit already can handle the conversion from Less to Sass automatically. For example, if you write in Less, you could use a build-script like the one I linked to create the Sass version, and obviously the CSS version would be available from that script.
2. Same as above
3. Build system again. That's exactly what gulp-autoprefixer was made for.
4. It should be the burden of the developer of the plugin to help make it as extensible and usable as possible. You are obviously going down this route to make it as simple for plain-CSS uses, but you're not alienating those that do use preprocessors; which it almost seems like you're assuming there is not a lot of. Sure, there's more than a few different preprocessors, but I've given you examples of how to workaround the caveats you were running into.

[silvenon]

1. This is not what I meant. I don't have trouble converting to CSS. I was saying that as an end user instead of having to pass options only to new Flickity(), I now have to pass options to the CSS preprocessor as well.
2. CSS users are locked with the defaults. I see that this is the situation now, but I don't see why we as end users can't just override them with specificity. We wouldn't save too much file size if we were to configure it via preprocessor variables.
3. Yes, but you have to guess which browsers the user wants to support. Actually, this problem is only solvable if you build your own assets with selected browser support, so this is not a valid point.
4. Like I said, I don't see any reason why the end user wouldn't just override styles from the CSS file. The developer should make it as accessible as possible, but within reason. End users also have Gulp/Grunt, which they can use to concatenate CSS and whatever. So I don't see how developers are alienating anyone.

All in all, I see very little point in bothering with CSS preprocessors in this case. Especially because they are eventually going to be replaced with PostCSS.

[zslabs]

Oof guess we'll just have to agree to disagree on this one; think we've both beaten our points into the ground ;)

[silvenon]

Agreed 😃

[tingletech]

At the very least the bower.json needs to be fixed, my front end designer could not get it to work because "main": is wrong. He also liked that there was a SASS version in kukac7's fork. I guess we will keep using kukac7's fork with bower.

[desandro]

@tingletech bower.json main is following a new specification. See bower/spec#43

[metaskills]

Using a scss would mean that users would @import "flickity"; and it would concatenate and be part of a single CSS bundle.

[silvenon]

Concatenation isn't a good reason to make a Sass version, you can concatenate CSS with a build tool. A Sass version should exist if you have to configure it.

[KittyGiraudel]

Allow me to dip in! While I am a big fan of Sass, I don't feel like adding a Sass stylesheet to Flickity makes sense. Flickity is written in plain CSS, which means it can be safely imported in a Sass file.

There is no need to have a Sass version. What would be the point? Nesting? Please. And I don't think like a few variables will help that much, in regard to the extra complexity added.

Flickity is more like a logic library, heavily focused on the JavaScript behaviour. The styles provided are simple enough for default, and can be safely improved and enhanced without having to rely on a pre-processor dependant stylesheet.

Needless to say, you cannot really add a Sass version without eventually adding LESS, Stylus and PostCSS versions. And then, you maintain a whole styling system while you could have staying with CSS, which in this case makes perfect sense. Flickity is not a CSS framework.

I'd advise against this PR. Just my 2 cents. :)

[desandro]

Thanks all for the input. I'm sticking with my guns and leaving Sass out. Time to put this one to rest. 😴