Why don't you use a css pre processor?

[GianlucaGuarini]

Why we cannot use a css preprocessor like SASS or LESS to speed up the styling development?
Thanks to the mixins and a smart use of some css var we can style all the templates having the same scaffold.

[scottgonzalez]

Preproccesing adds an extra layer of required knowledge and therefore reduces the number of people who are able to contribute.

[scottgonzalez]

I should note that I'm not against using a CSS preprocessor. I justed wanted to point out that there are downsides to using one. We should weigh the pros and cons before making a decision. In the meantime, using plain CSS is always the safest choice.

[jonlongnecker]

Gianluca, that's a great question. We did a good bit of research and ultimately decided that adding another dependency and increasing the complexity didn't make sense for a project that so many people would be contributing to. Especially within the time constraints :)

Thanks for your thoughts,

Jonathan

On Sep 30, 2012, at 4:47 PM, Gianluca Guarini wrote:

Why we cannot use a css preprocessor like SASS or LESS to speed up the styling development?
Thanks to the mixins and a smart use of some css var we can style all the templates having the same scaffold.

—
Reply to this email directly or view it on GitHub.

Jonathan Longnecker
FortySeven Media
(865) 607-4756
@necker47
http://fortysevenmedia.com
http://kickawesome.tv
https://kicktastic.com

[GianlucaGuarini]

With this pull request https://github.com/GianlucaGuarini/web-base-template/commit/e585c221f92da4498f33404aea742c6809b03eec I am trying to show you how it could be easy and smart working with a css preprocessor on these templates. Here you got an example:
Before:

background-image: -webkit-gradient(radial, 0% 50%, 0, 0% 50%, 80, color-stop(0%, #f2f2f2), color-stop(80%, #ffffff));
background-image: -webkit-radial-gradient(left, #f2f2f2, #ffffff 80%);
background-image: -moz-radial-gradient(left, #f2f2f2, #ffffff 80%);
background-image: -o-radial-gradient(left, #f2f2f2, #ffffff 80%);
background-image: -ms-radial-gradient(left, #f2f2f2, #ffffff 80%);
background-image: radial-gradient(left, #f2f2f2, #ffffff 80%);
-moz-border-image: -moz-linear-gradient(#ffffff, #e7e7e7 15%, #e7e7e7 85%, #ffffff);
-webkit-border-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #ffffff), color-stop(15%, #e7e7e7), color-stop(85%, #e7e7e7), color-stop(100%, #ffffff));
-webkit-border-image: -webkit-linear-gradient(#ffffff, #e7e7e7 15%, #e7e7e7 85%, #ffffff);
-o-border-image: -o-linear-gradient(#ffffff, #e7e7e7 15%, #e7e7e7 85%, #ffffff);
border-image: linear-gradient(#ffffff, #e7e7e7 15%, #e7e7e7 85%, #ffffff);

After:

@include border-image(linear-gradient(white, #e7e7e7 15%, #e7e7e7 85%, white));
@include background(radial-gradient(#f2f2f2, #ffffff 80%));

It does not add any complexity to the project indeed it makes it more maintainable and well organized.
If you like the idea I could do the same also on the other templates, maybe having a variables.scss file ready to use including all the common properties.

[scottgonzalez]

It does not add any complexity to the project

This is just not true. While adding SASS makes the source files cleaner, it certainly adds complexity. This would add:

• A build step for working on themes.
• A dependency on ruby.
• The need to understand SASS.

[ajpiano]

If we wanted to add a CSS preprocessor, I think we'd want to add a pure JS one like Stylus that can be incorporated into our existing grunt build process would be a much easier ask. The Ruby dependency is not something we want to have - we actually spent a lot of time removing Ruby and Python deps in the build process where they had been involved in various sites, so we are not going to add it back in.

In terms of the complexity a CSS preprocessor adds, I think we can mitigate it a lot if it's just something that happens as part of grunt watch, but there still is the question of whether that adds cognitive overhead for new folks. It sort of does, but the maintainability win might be worth it down the line.

[scottgonzalez]

Some people seem to be happy with grunt watch. I have yet to use it and I really don't want it to become a dependency for working on WordPress themes.

[GianlucaGuarini]

@scottgonzalez

A build step for working on themes.

Actually I think that any web project now has a build step to optimize the sources (minify concat js and so on..) so If you think that avoiding it is a good idea you, it is just your opinion but i don'agree

A dependency on ruby.

You have noted that we can do the same thing with grunt, you are right! But once again you do not want have node + grunt such as project dependency :(

The need to understand SASS.

SASS is just CSS you can keep writing your CSS as you like, it does not add any restriction to your previous knowledge, it just helps speeding up the workflow. BTW Do you really think that someone, that is not able to understand the simple SASS syntax, could raise up the level of this project?

@ajpiano

whether that adds cognitive overhead for new folks. It sort of does, but the maintainability win might be worth it down the line.

Cognitive overhead? Projects like twitter bootstrap are using LESS having thousand of followers and forks, why should we reinvent the wheel working with vanilla CSS?

I think your point of view is not properly right. The question is not whether a CSS preprocessor is good for our folks? But:

• is a CSS preprocessor good for this project?
• Could a framework like Compass be increase the maintainability of this project?

[dmethvin]

@GianlucaGuarini, this is not a priority for us now. Several sites like the plugin site have been out of commission for a year while we redesigned everything. Others have been on the drawing board for much more than a year, and we are finally getting the resources we need to produce them.

The most important thing for us today is to make the sites available to the jQuery community which has been waiting patiently for all that time. Implementing this proposal is certain to delay our progress in the near term, no matter what its benefits might be in the future.

Come back in a few months once the sites are all released and we have a better idea of what problems users are truly encountering and the things we should do to solve them.

[jonlongnecker]

Seeing as the project is being worked on by "our folks" those questions are deeply intertwined.

@GianlucaGuarini You're also making the assumption that everyone is working with preprocessors and it's simply not the case. It can speed up the workflow, but in many cases is brings it to crashing halt if you're not setup properly for it. Locally you need something else running to listen and rebuild the files - it's definitely a different beast than vanilla CSS.

Not that I'm against SASS or Compass - I think they're very interesting. But it's not a good fit at this time.

For this project the biggest benefit is obviously vendor prefix simplification. Has anyone thought about something like http://prefixr.com to do this with javascript?

[GianlucaGuarini]

@dmethvin

Come back in a few months once the sites are all released and we have a better idea of what problems users are truly encountering and the things we should do to solve them.

Premising I know that I was not involved in this project since from the beginning and so I don't know all the problems behind that. I could just tell you that I am used to solve the problems before going live, before it is to late.

@jonlongnecker

It can speed up the workflow, but in many cases is brings it to crashing halt if you're not setup properly for it. Locally you need something else running to listen and rebuild the files - it's definitely a different beast than vanilla CSS.

I spent 3 hours to configure your wordpress project on my mac (virtualhost + port 80 + db + wordpress installation + etc) and 3 minutes to configure the sass environment (Compass installation included)

Seeing as the project is being worked on by "our folks" those questions are deeply intertwined.

I know jQuery community is full of professional developers, I really respect all of you, but sometimes it's good thing do not trust everybody: 6 lines having same css declaration! https://github.com/jquery/web-base-template/blob/master/themes/plugins.jquery.com/style.css#L706 (are you sure that these mistakes are just here?)

For this project the biggest benefit is obviously vendor prefix simplification. Has anyone thought about something like http://prefixr.com to do this with javascript?

Ok after that, I can throw in the sponge granted you the point.

@scottgonzalez has tried to bring me in this project contributing with my knowledge and my ideas on the frontend stuff but it seems that there is no way to raise up the level of this project because everything is stuck.

Without a css preprocessor I feel like I am working with just one hand, and I have no time to blast my mind on browser prefixes, disordered css and nested css propertes. I am sorry guys, I have raised an issue and I gave you also many solutions and motivations, but no way.

Good luck for all,
Respect

[eddiemonge]

Not that my opinion matters much here, but I agree with @GianlucaGuarini that Sass would be a great addition to the project. Sass would be the easiest thing to add and would immensely help front-end devs. If their first introduction to Sass is from the jQuery project walking them through, then all the better. There are already so many dependencies in the project.

That said, if everyone is against then oh well. I just wanted to let @GianlucaGuarini know he isn't alone in trying to raise the overall level of the whole project, not just the JS part.

[nathansmith]

I'm also a huge fan of Sass.

But, I know I'm not an active participant/contributor to jQuery theme efforts, so I won't purport to know if it's good to add it as a dependency.

Anyway, melikey Sass/Compass for all my own projects, and have been advocating for it internally where I work.

[danheberden]

It sounds like this is one of the things that should be tackled at our dev-summit, given that one of the tables (the one Ryan and I are heading up) is the dev/deployment of these kind of things. @GianlucaGuarini are you by chance planning on attending it?

Either way, you've brought up some good points that we can weigh against our current needs and goals - so thank you for that. As you can imagine, getting this easier to work on for everybody is a big deal so we'll be getting some input at the dev-summit from other developers working on this (and other jQ stuff) to field how we can make this better/easier moving forward.

[ajpiano]

I also think that @GianlucaGuarini raises a bunch of fair points here - we should be concerned about engaging people who have grown accustomed to using CSS preprocessors and consider the use of on a minimum requirement for being effective, not only those for whom it represents a stumbling block. I'm totally +1 for the eventual inclusion of a JS based CSS preprocessor that can be included in an eventual build process - but that's exactly the point. Right now there isn't a build step for web-base-template itself, only the actual content repos that it displays. The people who have been working on the sites the most strongly value not having any build step whatsoever for development. (Production is obviously a different story.)

Adding in a big picture-piece to the workflow of a network of sites that a number of people are and have been working on for some time is something that inevitably requires a period of discussion and consensus building, especially if the changes in workflow are orthogonal to progress people need to be making to ship the sites. In a large open source project, if you show up with a pull request that adds undesired dependencies and/or necessitates significant changes to an existing workflow, you can't rationally expect those changes will be enacted within a day or two. On the other hand, it's completely reasonable to choose not to participate if you feel those changes are a prerequisite to your involvement.

It's worth noting, however, that typically when one has large changes he or she wants to enact, they gradually build up the "currency" to convince others to go along by also working on more tangible, bite-size issues over time, rather than encountering those very issues and pointing them out as evidence of incompetence.

I think we'd be considerably more amenable to an approach that first added a grunt based build step that actually met some of the more immediate goals of web-base-template: concatting/minifying the JS for production, and providing a switch that allows a developer to toggle what they'd like to work against in their local development environment. From there, with agreed-upon targets in mind, someone could layer on a functioning [Stlylus/Compass] step and say, "Hey, kick the tires on this." and then we could evaluate whether it's indeed transparent enough to meet everyone's needs. Like @danheberden said while I was typing up this whole thing, this is something that we could choose to tackle at the summit.