I'm contracting with a team where we're using Foundation (I'm personally not a fan of the verbosity of their grid system, but everything else looks quite nice). Sasson hands down has the best "tools" for any front end work - what I ended up doing was hacking SALSA + the reset/normalize/formalize stuff out, cramming in a few includes/templates from https://drupal.org/project/zurb-foundation (which is geared much more for CSS Foundation 3, most of it isn't useful/revelant), and dropping in the SCSS/JS of Foundation.

This got me to thinking it wouldn't take much effort to abstract Sasson a bit further so anyone can leverage the assetic/scss goodness (barring grid, etc) with whatever they want on top of it.

Off the top of my head, I'd merge CSS & Responsive in theme-settings.php into something like "Styling" and have a toggle like "disable css" that unloads all the scss and non-theme js in the base theme. That way people can have a solid set of functionality, but can easily use foundation, bootstrap, susy, bourbon, whatever. I'd be interested in spinning up a Foundation subtheme for Sasson (Zurbon?), and maintaining it w/ the team.

Comments

tsi’s picture

tsi commented

This is exactly the kind of things I've built Sasson for. I actually think of Sasson more as a theme-engine then as a theme by itself.
It should be really simple to use extra layers of styling like bootstrap/foundation on top of Sasson. you can basically enable/disable most of the things via theme configuration (through the UI or your theme's .info file):

  • Disable core and contrib CSS/JS
  • Update jQuery where needed
  • Choose a reset/normalize/none
  • Normalize forms
  • etc.

Then the only styling you will still get from Sasson is the layout, but as we already discussed, this can be easily overridden too by copying and modifying the /layout folder.
I would really love to see such a sub-theme.

erutan’s picture

erutan commented

We still need to work out some of the details on how it'd be released, but I'm pretty certain it'll happen. Sasson is what I used to get my feet wet with SASS a year ago, so it'd be nice to give back. :)

I think it'd be a bit cleaner to have a fieldset toggle on/off in the UI for all the non-engine bits instead of having them spread between CSS and Responsive, but it's not critical. The only other problematic things would be the layout as you said (putting in a blank layout/fixed.scss should work by default, though that's a little odd), and possibly the grid background being tied to SALSA (I haven't dug too deep into that). It'd be nice to have a "none" for layout in the UI ala reset/normalize.

I can probably work on a little patch for theme-settings.php sometime soon (it'd get things partway there at least).

tsi’s picture

tsi commented

putting in a blank layout/fixed.scss should work by default, though that's a little odd

Why blank? You'd want to provide some kind of layout won't you? just put your own layout rules in there.

erutan’s picture

erutan commented

I think if someone is dropping in another framework, they shouldn't have to worry about the structure of one they're not using.

Layout in Foundation is done via their _settings.scss + an app.scss (e.g. SUBTHEME.scss). It's not the end of the world to have a /layout/ directory, but it feels more of an anachronism from the SALSA layout. F4 is mobile first by design (though you can obviously use it as you will), so having to use the UI to set "responsive" then "mobile first" and then create a mobile-first.scss in layout is a little strange. As a subtheme I can have those by set default in .info and tell people not to touch them, but that's less than intuitive, and if I hack paths into theme-settings.inc and hide the UI I have to maintain that fork when the base theme changes. In Foundation's case it might not be a huge deal, but I could imagine some framework creating their own set of media queries (with appropriate grid scss) in /breakpoint/ or /reponsive/ or something, in which case cramming things into /layout/ is meh.

I support the path taken with SALSA / 3.x - removing tokens being passed into stylesheets ala 2.x is for the best, but now you have 3 different base files to start from instead of the nifty if statements. It's great for someone just wanting a basic structure to do a really custom site, but it gets in the way of existing frameworks. It'd be clearer to just untick 'use Sasson's starter theming' or whatever so you can drop in your own stuff and just start from SUBTHEME.scss and @import from there. Having a "put your own path(s)" is an option but shouldn't be necessary. Not the end of the world obviously as is obviously, but imho it's less than ideal.

aimeerae’s picture

aimeerae
she/her
Primary language English
Location San Francisco, CA
commented

It is a really great idea - I hadn't worked with Sasson before erutan walked through it and I like the configuration options because they were built to turn functionality on or off, not to just to provide layout options like some other themes. Rolling Foundation into a sub-theme seems to be working well on initial tests and it is making sense in the structure of Sasson.

I'll work through the release details as we work through the implementation. If we do get permission, then we'll be sure to have nice documentation available on release. Thank you for the support tsi!

tsi’s picture

tsi commented
Status: Active » Needs work

@Aimee - Thanks, feel free to contact me with any issue/ideas you find in the process.

@erutan - I see your point, I'll consider changing the interface to choose between desktop-first/mobile-first/fixed/none.

erutan’s picture

erutan commented

Awesome.

Still in the early stages of the theme, we'll let you know how it goes.

tsi’s picture

tsi commented
Issue summary: View changes
Status: Needs work » Fixed

Cleaning up.
This exact approach was implemented in the 3.x branch long time ago :)
You are welcome to try the latest v3.x

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.