SCSS: More variables about flipclock HOT 8 CLOSED

Would you be against having a LESS file?

from flipclock.

I don't use CSS pre-processors at this time. (I know shame on me.). Someone else added the .scss file and it's a pain for me to maintain since I don't use it. It's constantly behind the master CSS file. For this reason alone, I don't use Coffee script or CSS pre-processors. It really takes all the modularity out of the equation and forces people to use that (or it falls behind).

Kinda between a rock and hard place. I don't have anything against packaging these files with FlipClock, as I realize tons of people use these techniques. But that's just the disclaimer I provide...

from flipclock.

Phew. Glad I noticed this. I thought there was some issue with what was going on with compiling with libsass. The SCSS version is definitely behind the one in production.

I am considering making a lot of significant updates to the SCSS file and make the whole thing responsive from a CSS perspective. Technically some of the percentage widths would need to be added inline by the script when the markup is created though.

The other possibility would be to build the styles but with em values instead. Are you aware of anyone else taking this on right now? I wouldn't want to embark on something like this if it was already being done by someone else. I could actually put the file together in a way that would be a lot easier to build themes for different counter faces as well.

@adam-lynch, this would also include more default variables that could easily be overridden.

from flipclock.

That sounds great. No one else has collaborated that they are definitely doing this. Are you going to use Grunt to compile the CSS files? Because that would make sense because there is already a Grunt build script which you can add stuff to.

I think if you make the effort to do all this work, in the future I will just have to learn how to make my edits to the SCSS files instead of manipulating the actual CSS. As stated previously, I am more of a JS/PHP dev than anything and don't currently use pre-processors of any kind (coffee script included). I am not against the SCSS in this case, as it's the general desire of the community abroad that uses FlipClock and the majority of front-end applications and frameworks.

And regarding the widths, I was already thinking the same thing. Happy to checkout the pull request once you get it ready. Adding the widths to the JS shouldn't be too hard at all. If you make edits to the core files, be sure to do so in the actual source files and recompile the library before submitting the pull request.

from flipclock.

I am on the other end of the spectrum from you and do all of the front-end. I currently am using CodeKit for compiling my scss files with the libsass compiler. Anything I am using styles with it works just as well as the main sass compiler at this point.

That being said, I can look into what you are doing with your Grunt build script and see what needs to be done to implement the compiling of the scss.

I'll have to do some tests to see how to best implement making the counter responsive. The percentage widths might be the best way to go in the long run. Then the math can be done to determine the best way to calculate widths depending on how many number faces and dividers are initialized. That would also eliminate the need for some of the label specific styles to center them over the counters.

My plate is pretty full for the next few weeks but I think I can have a real crack at this sometime mid-october. Overall I think this looks like the best implemented js solution so far. Makes sense to invest some time in the styles then.

I'm in.

from flipclock.

Awesome, glad you like the library and would appreciate any help whenever you can. I think that once this stuff is complete and after I make a couple other changes to the core lib, it will be 1.0 status. It's had quite a long time to mature and for a lot of people to use it (more than I ever expected actually), so all this work will great to keep the library modern and up to speed with the latest and greatest.

I used CodeKit a while back, but the biggest reason I switched (pre v2 anyway) was you couldn't easily share build scripts with other individuals. Using Grunt is honestly easier for me than CodeKit was, but then again I live in code all day. Once you have grunt installed on your machine, all you have to do is open your terminal, navigate to the FlipClock repo, and run the "grunt" command. And then... whenever you update the files, the script will automatically recompile and if you use the Chrome LiveReload utility, the browser will even auto-refresh the styles. And given other people might want to update the SCSS files, or add a theme (in the future), all they need to do is run the same build script.

Also, if you can, anything new you add should be backwards compatible with what is already there to not break scripts for people upgrading. I realize we can break compatibility and just up the version, but it would be nice to maintain the stability of what is already there if it's possible. Some new examples in the repo illustrating the new features would also be helpful as well.

from flipclock.

Re: version compatibility

That is definitely going to be something I will address when testing for responsiveness. I think it should be possible to maintain compatibility even when moving to 1.0. There would have to be a significant improvement to support breaking backwards compatibility.

from flipclock.

Hi All:

We may want to close and reference this issue and any other relating to SASS/SCSS over to a new one I created here: #161

from flipclock.