The Grid

In this thread we'd like to get your feedback on the Foundation for Apps grid. We're very excited about the grid, as it's going to allow developers to highly flexible, responsive app layouts that just aren't possible with the CSS floats of yore.

The grid code can be found in this file: scss/components/_grid.scss.

The grid is very close to feature-complete, and includes these features:

• Sizing on different screen sizes, using the 12-column grid
• Horizontal and vertical orientations, which can also be changed at different screen sizes
• Orienting grid items to the left, right, center, or with even spacing
• Easy source ordering, again with responsive classes
• Offsetting, which is perhaps less needed with the grid alignment options, but still available

On using Flexbox

To start off, our decision to use Flexbox is pretty much set in stone. We've heard some concerns from the community regarding browser support, which we totally get. We've made the choice to be somewhat bleeding-edge, but this is also something of a long game. We at ZURB think web apps will only become more prominent, and this framework is meant to make web apps more powerful, and easier to develop.

Globally, some form of Flexbox support exists in over 80% of web browsers in use worldwide. To recap, we have totally solid support in:

• Google Chrome
• Firefox 28+
• Safari 6.1+ (Mac OS 10.7 "Lion" or newer)
• Internet Explorer 10+
• Opera 12+
• iOS 7.1+
• Android 4.4
• Chrome and Firefox for Android

Support gets a little shaky with iOS 6, Safari 6, and Android 2—4.3, which don't support wrapping of flex items. And support doesn't exist at all in Internet Explorer 9.

The grid syntax

Originally the grid had two core concepts: the "group" and "block". These were roughly analagous to rows and columns in other grid systems, where the former is for layout and the latter is for content. A basic grid might look like:

<div class="group">
  <div class="small-4 block"></div>
  <div class="small-8 block"></div>
</div>

However, because of the... flexibility of Flexbox, groups can be nested immediately inside groups, and be given sizing or ordering classes, just like blocks.

<div class="group" id="container">
  <!-- A fixed title bar and a scrolling pane of content -->
  <div class="vertical large-4 group" id="sidebar">
    <div class="shrink block" id="sidebarTitle"></div>
    <div class="block" id="sidebarContent"></div>
  </div>
  <!-- The main content area -->
  <div class="large-8 block" id="main"></div>
</div>

As you can see, not only are we immediately nesting groups inside groups (contrast this with Foundation 5, wherein you aren't supposed to nest rows inside rows), we have #sidebar, a group, and #main, a block, as siblings. Current grid systems don't quite work this way, where the "row" and "column" concept intermingle.

Once we realized how similar the two concepts are, we decided to merge them into one concept, using the name block. Now we have a single layout object that can be used for content or layout.

<!-- This group becomes a block, and functions the exact same -->
<div class="block" id="container">
  <!-- As does this group -->
  <div class="vertical large-4 block" id="sidebar">
    <div class="shrink block" id="sidebarTitle"></div>
    <div class="block" id="sidebarContent"></div>
  </div>
  <div class="large-8 block" id="main"></div>
</div>

However, there was one final snag. Blocks are flex containers, which we don't usually want for actual content. So we decided to add the modifider class content, which swtiches the block from display: flex to display: block, and adds a gutter around the whole thing.

<div class="block" id="container">
  <div class="vertical large-4 block" id="sidebar">
    <!-- This two blocks are for content, not layout -->
    <div class="shrink content block" id="sidebarTitle"></div>
    <div class="content block" id="sidebarContent"></div>
  </div>
  <!-- Same with this one -->
  <div class="large-8 content block" id="main"></div>
</div>

This is how the grid syntax currently works, and we're looking to get feedback on our approach. Specifically, we're curious to know:

• Does the distinction between content and layout make sense? We've run into some trouble explaining the concept to folks, especially because of how fuzzy it can get:
  • Layout: I need to immediately nest more layout objects inside of this one.
  • Content: I don't need nest layout objects... but in reality, I might want to eventually, in which case I'll nest a new block and build another grid. Mixing content and layout is very common.
• Would the old two class approach work better than this one-class-plus-a-modifier approach? At the end of the day there are still two main concepts the developer needs to understand. The challenge is, unlike rows and columns, which each have a distinct purpose, the group and block differed in some ways but also shared some functionality.
• Are there better class names we can use than block, content, or group? It's also worth noting that Drupal uses the block class quite a bit, and there's always a risk of conflicting with CMSes that use the term content.
• Are 12-column grids old hat? When we first showed the grid, we received some comments that the 12-column model of sizing may be antiquated, especially for a more modern framework like this one. There are two other options we could explore:
  • Percentage-based, the main challenge there being how many, and which, classes you output. There are easy ones like 25, 50, and 75, but how granular do you get? It's also worth noting that, if you use mixins only to build a grid, you could set the $grid-columns variable to 100 and basically be able to do this.
  • Ratio-based, which is a lot more niche, but is possible, as flex items can be sized relative to each other. (For example, a block with a size of 2 is twice as big as any block with a size of 1.)

3 things i noticed when looking at the readme:

• Sudo isn't needed on Windows
• Windows needs Ruby installed before you can use a ruby gem.
• Bower needs Git as its dependency but that isn't installed on Windows either.

Also there isn't anything about needing ruby in your PATH, nor NODE, nor GIT.

I can understand that you guys work on Macs and most webdevs do nowadays, but there are still quite a lot on Windows. Fortunately it isn't hard to use these things on Windows but there are a couple of things OSX users might forget to add.

I see Foundation for Apps is using Gulp instead of Grunt. Why was Gulp chosen? And is there a way to use Grunt instead of Gulp?

The time has come to remove our old plugins, so let's get rid of the js/foundation folder and the hooks in our Angular code. There are two things out of there we need to keep, though: FastClick (or an equivalent library), and the viewport unit polyfill for iOS 7.

When I open the test site in my browser, I see the sidebar on the left and a title bar at the top that literally says: Foundation for Apps - {{$state.current.data.vars.title}}

So Angular doesn't appear to be binding. Furthermore, the main content pane is empty. Clicking on any nav option on the side does not load up anything.

So I look in the console and see:
Uncaught Error: [$location:nobase] $location in HTML5 mode requires a tag to be present!
http://errors.angularjs.org/1.3.1/$location/nobase

I the modified index.html to add the tag which is required, and now it all works fine.

NOTE This may be related to another issue I am about to open, which is that there is a dependency issue with the current bower setup. So it might be that you originally setup with a different version of Angular.

F-Apps is awesome enough to have the frontend ability to ng-repeat mock data, but has anyone tried to bring in the data through JSON? I attempted it myself using http://fdietz.github.io/recipes-with-angular-js/consuming-external-services/requesting-json-data-with-ajax.html but was not successful, so I am guessing that maybe Angular isn't fully up to speed yet for F-Apps. Curious if maybe one of the plugins makes them even more awesome! ;)

Comments on the use of flexbox for the overall grid goes here.

These should be Growl Style alerts and be able to be positioned by default at the top-left, top-middle, top-right, middle-middle, bottom-left, bottom-middle, bottom-right.

They'll animate in and have room for action buttons as well as a title and text.

Additional Mock Data: We think this could potentially be useful, but as of right now we're going to hold off on it to not muddle the Angular stuff.

Icon bars with options for vertical and horizontal as well as a small, medium and large version for different needs.

I decided to update everything to Angular 1.3.1 but it looks like there are some issues.

Page Title: Can we change the page Title with front matter tags

These will be one component so they can become different things for different screen sizes. We have the basics of it already, but need to simplify the mixin and need options for vertical tabs.

This is something I've just noticed from playing with this project but there's a lot of mixing between tabs and spaces and inconsistent tab-sizes as well. I would suggest tab-sizes of 2 spaces and only using space characters themselves.

Modals with different size options for different screen sizes. Must be forward thinking for eventual usage of Dialog tag, but not rely on it.

Off canvas should work from top, bottom,right & left. It should have a slide animation and a slide over animation.

Angular Helpers

In the same way that Foundation 5 allows you to quickly scaffold a page without writing any CSS, a primary goal with Foundation for Apps is to allow developers to quickly build a single-page web app without knowing any JavaScript.

Foundation for Apps will come with Angular, ngAnimate, and UI Router. To make harnessing the power of these tools easier, we're writing a series of "helpers" that tap into some of Angular's core functionality without requiring the user to write any JavaScript. Of course, if you aim to actually make a functioning web app with Foundation for Apps, the expectation is you understand Angular. These helpers are more geared towards rapid prototyping for users who aren't familiar with Angular or even JavaScript.

Routing

In MVC terminology, a "route" is a specific URL that points to a specific view (i.e., a page). We're using UI Router to handle this stuff. Like with Rails or Django or any other web framework, routes are all defined in one place:

routerApp.config(function($stateProvider, $urlRouterProvider) {
  $stateProvider.state('home', {
    url: '/url',
    templateUrl: 'partial-home.html',
    controller: 'PageController'
  });    
});

At its most basic, a route is a URL and a reference to an HTML template, but a route can also include a controller and a few other fancy things.

We've designed a solution that allows the user to define a route directly on each template, and without writing any JavaScript. A route is defined at the top of each template in a block of YAML, and our custom Gulp task pulls these values out of each file, creating an array of templates/routes that it then turns into actual UI Router code. (The plan is also to condense the helpers into a single Gulp plugin, so you can simply remove it from a pipe if you don't want to use it.)

Defining a basic route looks like this:

---
name: about
url: /about

---

<div id="about"></div>

Nested child views are also supported:

---
name: about.contact
url: /contact

---

The URL for this view would be /about/contact.

It's also possible to pass in a controller, or insert a dynamic parameter into the URL:

---
name: blogPost
url: /post/:id
controller: BlogPostController

---

Animation

In addition to defining routes, you can also define view-specific entrace and exit animations. It will also be possible to define a default in/out animation for a child view container, meaning all child views would animate in and out the same way.

---
animationIn: fadeIn
animationOut: fadeOut

---

The fadeIn and fadeOut values are simply CSS classes, meaning you could tap into any animation library with this feature. However, our built-in Motion UI component will include a number of pre-built transitions and animations, as well as a set of Sass mixins allowing you to fine-tune their behavior.

We think these helpers will be a huge boon for users looking to rapidly prototype, but we want your feedback, whether you're an Angular developer or not.

• If you don't currently develop in Angular, do these concepts make sense to you? The goal with defining routing information directly on each template is to reduce overhead. We think it will be easy for users to understand the very basics of routing: pick a name and a URL for your view, and that's it.
• If you do develop in Angular, would you just rip this stuff out when you went to production? As we mentioned before, these helpers are geared towards rapid prototyping, and they deliberately won't include all of the various complexities UI Router offers. However, maybe there's a balance we can strike between keeping the helpers simple, while also offering just enough features to Angular developers that they may consider keeping them. At the same time, we don't really care, and would likely expect, developers to rip that stuff out and use UI Router like normal.

Comments on the syntax, implementation, or utility of the vertical (stack) grid go here.

Animation (change/motion) catches the eye more than most other things, so it's great when you want to draw attention to an action that might have slipped the user's attention otherwise. Also, it looks cool.

• We are looking for feedback on the markup. Does it make sense? Can you suggest improvements?
• Also the usefulness of animation modifiers? Are these the ones you would use in an app or are there others that are more useful?

Motion UI - Animation (change/motion) catches the eye more than most other things, so it's great when you want to draw attention to an action that might have slipped the user's attention otherwise.

You can find the Motion UI example page by cloning the repo and opening in the browser. The file path is /foundation-apps/dist/mui_docs.html
Example URL: http://rafi.local/foundation-apps/dist/mui_docs.html

I am struggling with some of the classes in grids. With Foundation/Sites I am able to create rows and columns and nest them as needed to keep a table-like effect. Below is the coding that I am using for F-Apps with some class switching from my F-Sites rows.

On my desktop, each row that is created will resemble a correct row of data, but each content block is scrollable on iOS. You can see the example here: http://gamerprogress.cloudapp.net/#/games

Is there a block that I should use that will prevent scrolling inside? Last question - I think it's because my iPad is iOS7, but the left-panel does not stay fixed like it does on the desktop. Is it just iOS7 that is causing the issues?

<div class="block" style="padding-top:7.5px; padding-bottom:7.5px" ng-repeat="game in games">
 <a href="#">
        <div class="medium-1 block" style="background-color:gray;margin:0 10px;height:90px;width:90px;overflow: hidden;padding:0;-webkit-box-shadow: 0px 2px 5px 1px rgba(0, 0, 0, .50);-moz-box-shadow: 0px 2px 5px 1px rgba(0, 0, 0, .50);box-shadow: 0px 2px 5px 1px rgba(0, 0, 0, .50);">
            <img src="http://calebjsmith.com/images/small-cover/{{game.gamecover.image_location}}" style="width:90px;position: relative;">
        </div>
    </a>
    <div class="medium-10 block" style="height:90px;-webkit-box-shadow: 0px 2px 5px 1px rgba(0, 0, 0, .50);-moz-box-shadow: 0px 2px 5px 1px rgba(0, 0, 0, .50);box-shadow: 0px 2px 5px 1px rgba(0, 0, 0, .50);">
        <h4 style="margin-top:9px;line-height: 1.2">{{ game.title }} <small>({{ game.platform.short_name }})</small></h4>
        <p style="font-size: .7rem;line-height: 1.3;">{{ game.gamedescription.description | words: 50 }}</p>
    </div>
</div>

Better drop-down menus than Foundation 5. Let's remove the pip and make them easier to fire dynamic content.

Let's Explore how we handle mobile drop downs. Do they become an action-sheet on mobile?

Very minor, but the README points to gruntjs.com instead of gulpjs.com

Panels are popups that stay off-canvas until triggered. Unlike the formal off-canvas menus, panels appear over content and don't push the frame around.

A panel can be its own thing, or it can change to and from a standard grid block depending on the browser's screen width. Making sure the two components play nicely with each other is important. There are issues with selector specificity and attributes from one component leaking into the other.

For now panels can appear from the top, right, bottom, or left of the frame, but we'd like to explore ways to allow for partial-width panels that stick to corners.

I git cloned foundation-apps 5 minutes ago and got these two errors after running Gulp.

Uncaught ReferenceError: FastClick is not defined
Uncaught ReferenceError: angular is not defined

So when I go to http://localhost:8080/ and try to click one of the links in the sidebar nav nothing happens.

Why is this happening?

These will be simple styled list items that will act like mobile list sections, with a top and bottom border as well as several options for titles, copy, and icons.

Since this is a very early version of Foundation for Apps I think it would be useful to have a debug mixin similar to the edit mixin available in Jeet Grid system

Their implementation looks like

@mixin edit() {
  * {
    background: rgba(0, 0, 0, .05);
    filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#10000000, endColorstr=#10000000);
  }
}

But out of personal preference I think naming the mixin debug makes a bit more sense. :)

Despite adding xlarge and xxlarge into $breakpoint-classes I can't change a panel into a block using xlarge-block and xxlarge-block.

I found some bugs and thought of some improvements while working on some of the directives:

• if a template has a url that has a parameter (like so: user/:id) and it comes alphabetically before a more deeply nested page (like so: user/profile), the parameter page will take over and will be non-overrideable. There needs to be a mechanism to delay declaring the state for the parameter urls until the end. (possible solution: sorting front-matter backward based on URLs, this would place any URLs with : behind named routes)
• the interchange directive should allow non-template data within so instead of declaring <div fa-source src="/path/to/partial"></div>, it should also allow arbitrary HTML within the tags to be a template like so: <div fa-source><p>some html</p></p>. Solved with: 3f16aeb
• e2e testing with protractor will help solidify the codebase
• unit testing with Karma

I needed to change my breakpoints - in my case I wanted to add in the xlarge and xxlarge classes so I can work with those sizes, but I found that none of the breakpoint variables are flagged as !default, so my own settings were being ignored.

Shouldn't these variables have a !default flag so that they can be overridden cleanly? Or is there some other scss magic that i'm missing? I really don't want to go changing anything in the Foundation components directly.

Compose View: We think this could be useful, but may want to save it for later asi t adds to complications. Let's try and document Document NG include so people can use a common Angular practice.

I am not sure, if such basic issues are welcomed here.
I did everything from 'readme', step by step.
But 'build' directory doesn't contain angular.js itself,
so index.html doesn't work:

Uncaught ReferenceError: angular is not defined app.js:15

Where should i copy it from bower_components?
Why gulp didn't copy it?

Also app.css.map file is missing:

GET http://mydomain.loc/assets/css/app.css.map 404 (Not Found)

Any questions, comments, suggestions on the syntax or practice of managing the stacking / unstacking nature of the new grid goes here.

It would be nice to see the progress, so maybe just toss it on a free Heroku/PagodaBox instance so people can see what's going on.

Use FA toggle on action sheets as opposed to the directive call thats currently used.

Positioning for pinning and color options? Consistent directive for both static and dynamic. Can we create a dynamic notification without creating a tag?

I really wish this were more Angular-based and less straight-up manipulation, because that causes issues in $scope and may encourage people it's okay with Angular, when it is really discouraged.

It would also be really nice if we didn't need to initialize Foundation, because having to call .init() has some issues with Angular partials and dynamically loaded content as I have seen with Foundation 5.

It would also be great if F-apps didn't rely on jQuery at all. I know it's tough at the beginning, but Angular's binding actually makes it pretty easy and most likely faster and easier on the computer.

There should really also be factories for notifications, popups, or anything that might need to be dynamically generated. This makes it easier to just say new Notification(text, status, canBeClosed);, which I think is much more useful than having to hide and show and do all that DOM manipulation that Angular discourages.

I get that there are some cons to these things, but this is what Angular really encourages, and it works well for most people.

$ is not defined when building and opening any of the dist files after running grunt.

Cards will replace panels and will have several configurations for header images, content and action bars across the bottom.

When I ran bower install I got this:
Unable to find a suitable version for angular, please choose one: 1) angular#~1.2.25 which resolved to 1.2.26 and is required by foundation-apps 2) angular#1.2.26 which resolved to 1.2.26 and is required by angular-animate#1.2.26 3) angular#>= 1.0.8 which resolved to 1.3.1 and is required by ui-router#0.2.11 4) angular#1.3.1 which resolved to 1.3.1 and is required by angular-mocks#1.3.1Prefix the choice with ! to persist it to bower.json

I went with the latest version of Angular for now, but I don't know if that is correct as it may have caused another issue that I just submitted.

I've been working with the node alternative for SASS for a while now and it seems that using the Ruby version is a bit unneeded. The 3.4 additions aren't really major (not for this project anyways) and there are a couple of benefits.

• Using the Node-version is much faster (especially on windows)
• Its easier to get this project going on Windows as they don't have Ruby installed (you really need to watch out for your Windows users too)
• While it may not be on par with Ruby, its stable and deemed production ready by a lot (even though the readme doesn't state this).

You can just include it as a node-module (gulp-sass instead of gulp-ruby-sass) and get it over with. I really like that you won't have an entire dependency before you start and can easily update it too when new versions come out.

So there's a big problem with node-sass right now, it's well documented but there seems to be no fix in sight as of yet (it's a recent change).

We currently use gulp-sass which imports node-sass which, in turn, imports libsass. So one way, to side-step installing the node-sass that has the issues, is to specify a version and install it separately like so:

npm install [email protected]

I'll try to specify this in the package.json, but I have a worry that it'll get installed second, not first. However, that node-sass version carries a libsass version that fails on this:

 [gulp-sass] scss/foundation:66: expected 'in' keyword in @each directive

@gakimball any ideas on how to resolve this? Unfortunately, ruby-sass seems to be the easier version in this case, at least until that one bug gets resolved.

Please note that for the moment, new issues and PRs may be closed without warning. We are, in the interest of sanity, restricting commentary and changes to the Foundation Core team. If you absolutely MUST say something and are not core team, please reach out to use on twitter @zurbfoundation. Thanks!

Hey everyone,

I am trying to start off small on run the docs and the demo of this project, but I am having a few difficulties getting the Angular part to work.. I think. Starting note: I run a lot of projects in PHP using Laravel, so I have WAMP going in full force with all of those details. I'm not sure if that impacts what is going on, but I didn't want to leave it out.

I have cloned the files into a folder in my WAMP www root folder for safe storage. I compiled it all using npm install and then ran gulp which started the service and I leave it running in the background. I investigated that I should run it under localhost:3001 and I successfully see the index page for "Foundation for Apps" and can load up the playground and Interrobang - but none of the Angular components work, like switching to another page, firing a notification, etc. The dropdowns and modals work - so I assume the JS works.

What am I missing in this setup? Thanks for your help!

Right now we're looking at which of the hot new Sass features we want to use in Foundation for Apps. We'd like to shoot for libsass compatibility so our stack can be pure JavaScript, so when we say "new features" we mostly mean "maps". Maps aren't yet a native libsass feature but there is a polyfill for them.

Currently, frameworks spill out all of their variables like this:

$button-bg-color: #000;
$button-text-color: #fff;

Maps give us an opportunity to bring more structure to our settings file, by allowing us to craft an array of settings:

$foundation: (
  button: (
    background: #000,
    color: #fff,
  ),
);

Because of the confusing-ness of the map-get() function when accessing nested maps, we'd abstract map access out to a single foundation() function.

// The old way
color: $button-bg-color;
// The new (?) way
color: foundation(button, color);

More complex components could separate their settings by component.

color: foundation(dropdown, menu, color);

What we want to know is, does this make sense? Will users understand it? As far as how we write the components, we plan on giving users the same amount of customizability they're used to in Foundation 5. As usual our designs will be un-opinionated so you can easily overwrite them yourself.

Here are the benefits:

• More structure: Right now the settings file is just a loose collection of variables. They're only related because we name them and order them properly. Putting them in arrays gives them actual hierarchy.
• Namespacing: We aren't always too concerned about namespacing, because if you're mixing front-end frameworks you crazy, but it's still an issue that can come up, and its worth safeguarding against. By containing all of our stuff in one $foundation variable, we're basically guaranteed to not have conflicts with other libraries. Of course, we can't namespace our mixins, but we can at least group our settings together.
• Portability: There's a Ruby Gem that that allows you to export a Sass map as a JSON file, or import a JSON file into a Sass map. (This functionality doesn't come with the libsass polyfill I don't think.) There's a lot of potential to do weird stuff there, like automatically generate the settings file (no more adding variables twice!) or exporting/importing entire themes as one JSON file.

Here are the downsides:

• Confusing? It's somewhat weird syntax, to be sure. People who understand arrays and objects understand that you usually access them like this: Foundation.button.color or Foundation::button::color or something like that. Since Sass is entirely functional, our accessor syntax looks a little funky. foundation(button, color). It's not a way people are used to having to access arrays. Explaining the syntax is a little easier if you break it down where the first attribute is a component, and the second attribute is a setting of that component. But there's possibility to nest more levels deep, at which point your syntax looks like foundation(menu-bar, icon, size) or something like that.

Arguably it doesn't make memorization of settings any harder. You're still going to have to look up the really specific ones. However, there are a few that people use a lot in development.

padding: $column-gutter;
padding: foundation(grid, gutter);

color: $primary-color;
color: foundation(color, primary);

So those get slightly more obfuscatory, perhaps. It's a matter of re-training people mostly.

And as always we're going to try to balance best practices with ease-of-use for our users. If you went and asked any programmer, "would you rather list a bunch of related things as their own variables, or put them all in array?" the answer would be obvious. It makes sense to put things in arrays from a best practices perspective. That doesn't mean it's what's easiest for our users to understand necessarily.

But that's what we're trying to find out. Let us know what y'alls think!

Addendum

To expand on this slightly, we don't necessarily need to contain everything inside one $foundation variable. We could have separate variables for, say, component settings, global settings, breakpoints, and colors. The question is then how you access them.

// With the same function?
color: foundation(color, primary);

// With a unique function?
color: color(primary);

// Or should it be namespaced?
color: f-color(primary);

So I just got foundation for apps up and running and want to learn more so I went to index.html file to find some information and realize there is no styling .css file included which makes it a bit difficult to navigate through it. Are we waiting for those styles to be created by the Zurb team? Or am I doing something wrong?

Panels

Currently, the way most all responsive frameworks handle responsive design is through stacking of content. So given two columns that appear side-by-side on a larger screen, on a smaller screen they stack on top of each other. This works just fine for many use cases, but of course we always want designers to think a little harder about layout when the content requires it.

This stacking model doesn't quite work for web apps. Let's take the same two-pane approach, and assume this is a note-taking app, where the left pane lists all of your notes, and the right pane shows the active note. On a small screen you don't just want the entire list to stack on top of the note-taking screen or vice-versa. You might want the list to collapse into a dropdown at the top of the screen, or you might want to delegate the note list to its own separate screen, viewable via a menu icon or back button.

That's where panels come in. (And these aren't the panels you know and love from Foundation 5, so make note of that.)

The panel code can be found in this file: scss/components/_panels.scss

The two kinds of panels

The panel can take on two forms in Foundation for Apps.

Standalone panels

Panels can be anchored to a block, or the entire window, and be positioned at the top, left, right, or bottom of their parent. The markup looks like this:

<div fa-panel id="pagePanel" position="left">
  <p>You can put any markup inside here. You can even nest a grid inside here and go crazy with layout, or nest more panels inside this one.</p>
</div>

To create a control that summons the panel, add the attribute fa-toggle="id" to any element, where id is the ID of the panel.

Panel/block hyrbids

Where panels get weird (and awesome) is their ability to integrate into a grid. Here's the markup for the note-taking app we were talking about:

<div class="block" id="container">
  <div class="small-4 block" id="noteList"></div>
  <div class="small-8 block" id="currentNote"></div>
</div>

This layout should work fine for medium and large screens, but on small screens, we want our note list to disappear off-canvas until we need it. So we add these classes to to our noteList block:

<div class="block" id="container">
  <div class="panel panel-left medium-block medium-4" id="noteList"></div>
  <div class="small-8 block" id="currentNote"></div>
</div>

There's a lot going on here, so let's break down the classes in use:

• panel: This is a panel.
• panel-left: This panel anchors to the left of its parent.
• medium-block: On medium screens and up, this is a block.
• medium-4: On medium screens and up, this block is sized at 4/12 columns.

Block styles override panel styles, and since the styles are applied mobile-first, this block has the following configurations:

• On small, a panel oriented to the left.
• On medium, a block with a size of 4.
• On large, the same as medium.

We could add a large sizing class, i.e. large-5, to the block and then have a third configuration in play.

This was a tricky problem to solve, but we think this solution of dynamically hiding areas of the grid off-canvas will be a great help in creating responsive web apps. Remember, our key pitch with Foundation for Apps is that you can create an entirely responsive web app with one codebase. Complex web apps are not currently built this way.

The panel/block hybrid syntax is a little weird though, not to mention verbose. Our users understand the responsive sizing classes, like small-12 and medium-6. The thing you have to understand here is that the block itself now needs a breakpoint class, i.e. medium-block to indicate that the block styles kick in on medium screens, overriding the panel styles.

Here's what we would like your feedback on:

• In general, do you think the panel/block hybrid will be useful?
• Are the extra classes required confusing? As always, there will be mixins for grid elements and panels, meaning you can condense all of this complexity into one class if you want. But we'll still have the classes to make rapid prototyping easier.
• Would you ever want a block on a smaller screen and a panel on a larger screen? Our classes are mobile-first, and in general we're assuming that developers will want panels on smaller screens, and then they want block functionality to kick in on a larger screen, where you have more space. If the opposite is a possible scenario, we'd have to account for that in how we write classes.

I followed the quick start and everything basically went fine until I got to the part where I have to run gulp and after running gulp this is what I see:

$ gulp
[20:47:42] Using gulpfile ~/dev/foundation-apps/gulpfile.js
[20:47:42] Starting 'build'...
[20:47:42] Starting 'clean'...
[20:47:42] Starting 'server:start'...
[20:47:42] Finished 'server:start' after 20 ms
[20:47:42] Finished 'build' after 25 ms
[20:47:42] Starting 'default'...
[20:47:42] Finished 'default' after 151 ms
[20:47:42] Server started http://localhost:8080
[20:47:42] Finished 'clean' after 179 ms
[20:47:42] Starting 'copy'...
[20:47:42] Starting 'clean-partials'...
[20:47:42] Starting 'sass'...
[20:47:42] Starting 'uglify-angular'...
[20:47:42] Finished 'clean-partials' after 20 ms
[20:47:42] Starting 'copy-partials'...
[20:47:42] Finished 'copy' after 159 ms
[20:47:42] Starting 'copy-templates'...
[20:47:43] Finished 'uglify-angular' after 662 ms
[20:47:43] Starting 'uglify'...
[20:47:43] Finished 'copy-partials' after 710 ms
[20:47:43] Finished 'uglify' after 124 ms
[20:47:43] Finished 'copy-templates' after 654 ms
[20:47:44] gulp-ruby-sass: directory

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: error /home/max/dev/foundation-apps/scss/foundation.scss (Line 54: Invalid CSS after "  button": expected ")", was ": (")

This seems like a legitimate bug. How to get past this point?