SASS for CSS

[pollingj]

I really think it would be worthwhile to use the SASS version of the project for the CSS. SASS and Compass make CSS much easier to manage, organise and update.

https://github.com/pollingj/jQuery-Mobile-SASS

[rsaccon]

Cool ! Hope this makes it into official jquery mobile ! Started myself tinkering with 'less', with same motivation of easier custom theming !

[scottjehl]

Thanks - Great work so far. This project definitely looks interesting.

I think a main reason we'd be hesitant to adopt something like this in the official codebase is that it will add even more developer configuration and know-how for potential contributors. It's very important to us that those who want to help with bug fixes can do so as easily as possible, and we already have a small barrier of entry in that PHP is required for our css and js combiner (but at least our development files are in JS and CSS).

Anyway, we're following your project and will definitely weigh the pros and cons of adopting a similar implementation. In the near future, we intend to rebuild ThemeRoller for the new theming API, and something like this may prove to be a great system for driving that tool.

Again, very cool stuff. Thanks for working on this!

[paulirish]

I was speaking to a developer from Amazon who wanted this as well.

I would recommend doing it, as it'll make the CSS a lot more enjoyable to maintain. I would also recommend keeping the compiled CSS in the repository as to not make it harder for newbs. And @pollingj's choice of the SCSS dialect is right on. Makes this sort of change really easy and straightforward.

I'm gonna reopen the issue.. I think 1 year later is a good time to revisit this decision. Yays/nays?

[rosshadden]

My two cents: It should definitely be something that also supports vanilla CSS, such as LESS or SCSS. That way people that don't understand (or let's be real, people that don't want to understand) won't feel left out.

[aeosynth]

we already have a small barrier of entry in that PHP is required for our css and js combiner

you could consider switching to node.js. using scss will add a ruby requirement, whereas less is written in javascript.

[johnbender]

A couple of things to consider:

1. As Scott mentioned, switching to either SCSS or LESS adds to the contribution learning curve.
2. Our core devs who handle the CSS don't have experience with either LESS or SCSS, and while they both represent strict supersets of CSS using them properly (eg, avoiding overeager nesting) takes time/experience. @toddparker @Wilto and @scottjehl will have to make a determination here.
3. Adding an external dependency means another source of possible upstream issues. In any case we're actually adding two dependencies in the form of a runtime and the relevant package/library.
4. The migration path is not obvious to me. If we make a concerted effort to migrate any of the CSS we run the risk of introducing bugs where no test coverage exists (ie visuals). It's entirely possible that a slow introduction with small migrations over time is feasible, most projects I've worked on that leveraged either tool did so from the start. Some more anecdotal evidence here would be helpful.

To be clear I have used and appreciate both tools, but unless CSS is falling down hard for us in more places than just the theme roller, where I see the most obvious benefit, it seems like more trouble than it's worth.

[edit] "not obvious" => "not obvious to me"

[pollingj]

Did't expect to see this much activity in my inbox this morning :)

Ok, as I started this thing, I guess I should wade in.

I completely understand where the core team are coming from on this. Switching all the CSS to SCSS etc was easy enough, but I've always had nagging doubts in my mind if I've converted everything correctly. I think I've always managed to do a decent job as no one ever complained, but there is no 100% guarantee of the conversion being perfect. I did wonder about doing file to file comparisons, but that was never going to be perfect either.

I also get the argument about not having too many barriers to some developers, however I would say the barrier to SASS or LESS is a lot less now as more and more developers are starting to adopt them. Now I'm a big fan of SASS, and quite vocal about it, but at the same time I'm not a believer in forcing techs onto people. My personal opinion on why SASS vs LESS is simply down to Compass. For me it's always been about Compass and all the tools that provides. (Oh yeah, and I'm no fan of getting JavaScript to handle all the styling, but that's a different argument :))

Anyway, back to the point. I can't see SASS or LESS being adopted into this project, for the good reasons that @johnbender has raised. There is however clearly a call for this, so here's what I suggest.

1. I pull my finger out and actually start maintaining my Compass plugin - https://github.com/pollingj/jQuery-Mobile-SASS
2. The core dev team point people in the direction of the plugin, maybe making it an official SASS / Compass plugin?
3. Whenever any changes are made to the CSS let me know and I'll get the necessary SASS stuff updated. (To be honest this was always my biggest issue - having to start over again with the conversion).
4. Developers start contributing to the Compass plugin :)
5. If someone wants a LESS version, then they should just create a separate version, and again get the core dev team to point to it. Clearly the SASS version will be superior though ;)

So, lastly, apologies for letting my project slip so badly. Unfortunately I've not needed it myself for some time, so I've let it all slip. (You know the story).

Thoughts?

John

[toddparker]

Hi John - If you're willing to maintain this, we'd be happy to promote this as much as possible. I know having a SASS version is important to a group of developers so we'd really appreciate the help. I know we used your version on a client site a while back and it was great.

[staunsholm]

+1 for SCSS. Really makes css changes much easier after a brief and gentle learning curve.

[pollingj]

@toddparker Ok, I've made a start at upgrading my plugin, but I've got a few client deadlines this week, so don't think I'll get it done until later next week. I'll shout once it's done though :)

Could I ask when you guys make a change to the CSS that you can drop me a quick email to give me a gentle prod and I'll get any necessary updates done. It will be easier for me to keep up maintenance if I'm changing stuff in small amounts.

[toddparker]

I think the best approach would be for you to watch the repo and keep and eye out for CSS changes. We have so many people contributing, it would be hard to coordinate directly.

Are you only porting the theme file, or all the structural CSS for each widget too?

[pollingj]

That's a fair point.

I'm porting everything. The theme stuff is getting the most attention, but I plan to SASSerize (new word) everything.

[johnbender]

@toddparker

I had a thought on this last night. We don't have much in-project documentation. It might be nice to have a css directory specific readme ($PROJECT_DIR/css/README.md) with information on making alterations, conventions, and that would also be a good place to link to @pollingj 's project.

[toddparker]

Good idea @johnbender

[jokeyrhyme]

Are there good technical reasons for choosing SCSS over LESS (or vice versa)? Just to clarify, SCSS has been selected because the developer working on this issue is already familiar with Compass/SCSS?

That's a good enough reason for me, and I don't want to drag this out. I only ask because there doesn't seem to be much discussion about the LESS vs SCSS in this thread, only CSS vs SCSS/LESS.

Disclaimer: I'm not currently using LESS (although it has long intrigued me), I am using Compass/SCSS.

[toddparker]

I think someone in the community was planning on maintaining a SCSS or LESS version. I havent' heard anythign recently though. Closing since we're not going to make this switch in the forseeable future but will keep an eye on this.

[sghoweri]

@toddparker or @paulirish - Any chance we could (re)-reopen and revisit this issue?

A large jQM project I've been working on over the last month or so presented the opportunity to leverage SCSS and Compass for code maintainability. During the theming process, I took it upon myself to convert a considerable amount of the base jQM structure and theme CSS into Compass mixins, switched the static image icons over to using font icons, added mixins for generating retina and non-retina sprite sheets, etc.

While this conversion process isn't yet complete, I think the work and insight so far could benefit the community quite extensively.

If the opportunity exists, I'd be willing to put in the time to get jQuery Mobile up and running on SCSS / Compass. I feel this is far too important an issue to not take action on.

[toddparker]

@sghoweri - mind posting your code so we can take a look?

[sghoweri]

@toddparker Of course - not at all. I need about a day or two to review my work I did so far and to make some additional edits. I'll get this code posted as soon as I can!

[sghoweri]

@toddparker - I've posted the work I've hammered out so far at https://github.com/sghoweri/jquery-mobile

If you check out https://github.com/sghoweri/jquery-mobile/commit/d022248d8bd992908811f6941753e7835ba9ea15 specifically, you'll be able to see the jQM structure widgets I've gotten through my first pass at converting to SASS (nesting and replacing vendor-prefixed rules with Compass mixins, included).

There's still a TON of work to do before I would consider this to be even remotely close to completion: -Finish re-processing the structure and theme .scss files from the /structure-processing and /theme-processing folders and replacing the CSS in the corresponding /sass/structure and /sass/theme folders -Comparing the outputted SASS line by line to the original jQM CSS -Verifying rule specificity -Converting certain values such as border-radii or colors into global variables -Converting the theming color variations (and widget states) into Compass color operations -Documentation -Adding Compass tasks to Grunt build

... but it's a start. Let me know what you think.

-Salem

[toddparker]

@ sghoweri - Thanks, looks good. Whether to use a CSS pre-processor is a topic for discussion for 1.4. If you want to plug into the process and generally help out on CSS items, you're welcome to start hanging out with the team on IRC to see how we work. #jquerymobile-dev on freenode.

[sheppard]

Hi all, I have been maintaining a jquery-mobile.scss for use in my projects that should be of interest to this discussion. It is meant to be used to create custom jQM theme CSS that is compatible with jquery.mobile.structure.css, i.e. it's basically a programmable theme builder. It's built around Compass mixins with generic default colors that can be overridden for each theme swatch:

@import "wq/jquery-mobile";

@include jquery-mobile-theme(
  $theme:        b,
  $bar-border:   #b3b3b3,
  $bar-text:     #3e3e3e,
  ...

I also abstracted the notion of a jquery-mobile-block() mixin as I noticed that a number of the jQM CSS theme patterns (buttons, bars, etc) are nearly identical in structure:

• border
• gradient + fallback background color
• text color, weight, and shadow

jquery-mobile-theme() calls jquery-mobile-block() internally for each of the bar, body, button-up, button-down, and hover classes. This significantly reduced the codebase and the potential for errors in almost-duplicate code. I think the resulting CSS is comparable with that created by the theme builder, but I haven't yet tried using it to recreate the default swatches.

I'm using my own Python-based build process (with pyScss) which may be less useful to the larger jQM community, but I imagine the SCSS file itself could be useful, especially if there is a decision to migrate to a CSS pre-processor in the near future.

More info: https://github.com/wq/wq.app/blob/master/scss/jquery-mobile.scss http://wq.io/docs/jquery-mobile-scss-themes

[toddparker]

@sghoweri and @sheppard - Thanks for all your hard work on this, we really appreciate it. I think the best way to move this conversation forward would be to have you move this conversation to the dev channel. We're looking at possibly supporting CSS pre-processors so having you involved and on the team would be helpful. If interested, join us on #jquerymobile-dev on freenode and we can talk more.