F6 Wishlist

[vinayraghu]

• [x] Incorporate Sass 3.3 features such as maps and provide a settings API for all Sass components
• [x] .editorconfig #4720
• [ ] Unit tests for Sass https://github.com/ericam/true
• [ ] Support both em's and rem's using a generic calc function #4633
• [ ] Experimental advanced grid system - Singularity, Susy, Zen Grids rely more on mixins, make less assumptions and do not constraint design #4134
• [ ] Animation library for use with all js plugins - http://h5bp.github.io/Effeckt.css/
• [ ] Megamenu - http://geedmo.github.io/yamm3/#
• [ ] Labels with close buttons (like alerts) - Useful in search contexts
• [x] Accessibility

Will add more Edit: Added accessibility

[zslabs]

I know that Foundation and Bootstrap are different beasts, and while I'm sure some will say, "just go with Bootstrap then since they have a SASS port), I think there's some small gains/changes that Foundation could get some inspiration from Bootstrap:

• More table styles - Right now Bootstrap has more complete styles for admin tools (as a general comment)
• Better styled dropdowns - current implementation seems a bit clunky.
• Affix
• More uniform spacing throughout. Feels like there are a lot of irregular spacing patterns in different Foundation components. Buttons seem to have a different padding "scale" than pagination.
• I'm going to +1 using @extend as a few others have mentioned. Personally, I don't understand why Zurb would go with a library that doesn't support all that SASS itself does. I get that it's faster, but @extend is such a handy feature -- and to have all consideration of it removed from Foundation because of speed improvements seems a bit silly to me. It's a port -- and an incomplete one at that.

I'm more than happy to create a PR for tables, some style updates for dropdowns and general spacing adjustments, but want to gauge the communities interest in bringing over those. Thanks!

[prembo]

Clearing improvements previously listed in #4771:

• Load progress indicator - e.g. Image Lightbox. (if things are slow, after the initial click to bring up Clearing, there can be a few seconds delay before anything happens, giving you no indication that Clearing is actually loading)
• Animations for:
  • Initial display of Clearing - eg. fade in as in Fresco
  • Zoom for single image -eg Magnific
  • Transition between images in a gallery - eg. Image Lightbox
• Padding Clearing container so that sits off the viewport edge via SCSS variables (with an appropriate default)
• Centring the carousel thumbnail container eg. Fresco
• Shadow / border around the displayed image via SCSS variables (with an attractive default)

[LDigital84]

+1 for a Foundation version of Affix.

@zslabs - +1 for both the table styles and dropdown styles. Especially the tables. I like the fact that bootstrap has all of those available options.

[ghost]

1. Responsive Typography (also margins, paddings…) as discussed here #4633
2. Flexbox Grid - I've noticed that you already have flexbox branch and I think that the situation with browsers support is finally ready for this move. I don't know what your plans about IE9 support are, but without IE9 you even might not need any fallback. Also it would enable to merge grid and block grid into one.
3. Media Queries Ranges - Rethink default media query ranges. Having a breakpoint at about 480px is often desirable (having 1 column up to 640px as it is now often looks bad). What about something like this as a starting point for discussion:

$small-range: (0, 480px);
$medium-range: (481px, 767px);
$large-range: (768px, 1023px);
$xlarge-range: (1024px, 1279px);
$xxlarge-range: (1280px);

1. Plugin Directory - It is often said that the biggest advantage of Bootstrap over Foundation is availability of plugins, especially for admin areas (datepicker etc.). Having plugins directory on Foundation website would help with this. Maybe something similar like Wordpress.org has. Also as Foundation is getting bigger and bigger it might worth considering to have some less used components as separate plugins.

[vinayraghu]

+1 for affix. Would also like to add typeahead / autocomplete / dropdowns with search but I think this is better as a separate plugin that's not part of core. Would be a great choice for the plugin directory. +1 for a smaller media query range I would like to support multiple columns at those widths instead of stacking. +1 Plugin directory - Would be awesome if we have some official plugins from zurb which will graduate into core.

[joshuajabbour]

I'd prefer less plugins in "core", and that more of them were built in a modular fashion. Many of the Foundation JS plugins are great, and I'd love an easier way to use them in other projects...

[vinayraghu]

I agree with this approach. The reason a lot of cool functionality is not being added right now is because it bloats the core. The aim is simplify and reduce the bloat. Having a modular approach allows the core to be tight and neat. Every additional plugin is available. If the user adds too many and the code's bloated that's their responsibility.

Core ships with most minimal features. More important, a lot of new plugins can be released out as addons, which can be dragged and dropped into the project. Totally love the idea!

[LDigital84]

+1 for modular plugins!!!

[WhatsNewSaes]

I totally agree on the Media Queries Ranges. I find myself changing the default to something similar that @kevinwake mentioned.

[hashanp]

1. Flexbox Grid with CSS Grid Module future-proofing
2. Segmented Buttons
3. Use the role and WAI-ARIA attributes - for example alerts could be defined with <div role="alert">, tabs could use <ul role="tablist" aria-controls="tab1"> and <div id="tab1">, and buttons could be defined with <a role="button"> rather than <a class="button">
4. Rethink button sizes - they are essentially a relationship between padding and font-size, so they should be defined like:

$button-small: (10em, 5em);

button {
   @include button-size($button-small);
}

1. Mobile lists - like table views in iOS, see (https://github.com/alfajango/foundation-mobile)

[shadowhand]

Biggest problem with Foundation for our application is that we cannot do this:

$(document).foundation();

and then later do

$('.some-page').append('<a data-dropdown ...');

and have it work properly. Currently, in order for the injected elements to be seen by Foundation, we have to call:

$(document).foundation('reflow');

which is totally unacceptable when working with a large Backbone/Marionette application where views are being injected asynchronously on a regular basis. If every component bound only clicks, regardless of whether or not any corresponding element exists, it would be possible to have a single document.foundation call and have very dynamic pages.

And we would really appreciated AMD support. :)

[techdragon]

• megamenu is neat and all but its not a must have
• some table styles would be nice but again, not a must have for me
• an optional loading progress indicator where appropriate, like in orbit, interchange, clearing, etc would be a nice touch but I figure its probably too much work to be worth it.
• 'advanced grid system' - sounds nice, not sure I really care about having any of the susy and other peoples stuff, just give me some flexbox tools to work with the foundation grid and flexbox powered layouts.
• responsive typography - more typography control is never a bad thing.
• standardizing the animation library either with effect.css or like effect.css would be cool
• Affix - feels like this is a complete missing feature that some version of should be developed
• dropdown styling needs a major improvement, this feels like one area foundation really loses to bootstrap
• Plugin directory!
  • Cant vote for this enough.
  • heres my first suggested plugin for the directory https://github.com/Ben348/Foundation-Sidebar / https://github.com/bathomson/Foundation-Sidebar

@zslabs - more SASS projects need to get behind LibSASS not less. Foundation moving to only need the libsass feature set was a big improvement! With libsass I can use the native uncompiled foundation scss into any asset build pipeline quickly, easily, and in a way that makes my life easy and lets me use foundation better and more powerfully regardless of the language or framework I'm developing with.

@rvinay88 - please use caution with the SASS 3.3 features, libsass is a big reason why I'm using SASS at all and until libsass supports the features, i really don't care if foundation doesn't have them, if Zurb deem those features important, I'd encourage them to contribute to libsass to get them instead of switching to ruby sass.

[hashanp]

@shadowhand - what about:

$('.some-page').append('<a data-dropdown ...').foundation('reflow');

Is that acceptable syntax? Personally I think given people are floating ideas of modular plugins, Backbone or something similar would be a perfect way to define JavaScript plugins. There could be a foundation subclass of Backbone.View (which I really think should be called Backbone.Controller anyway, where the template is the view) which automatically calls .foundation('reflow') on this.$el after render.

@techdragon - I think that rather than creating a whole new plugin directory because there are already some many around, we should use an already existing plugin directory and just declare that all plugins prefixed with foundation- are plugins, or if we use the npm registry we could have all modules which have the keyword foundationplugin as well. It's exactly what projects like grunt and gulp do. As a node developer I prefer npm to bower, because it gives a one shop experience.

Finally can I suggest that plugins can be added to HTML pages with having to add both a css & js file, and instead just one file. Surely there could be a grunt or perhaps gulp plugin that wraps css with a javascript file, that results in a new javascript file which adds the css to the head and then runs the original javascript.

[shadowhand]

@HashanP I just don't see the point of needing "reflow" at all. Foundation 6 should be built without it or it should not automagically bind itself globally and should require calls to $(elem).foundation({dropdown:true}) to register an element. It just seems like a huge waste of cycles to constantly be using reflow in every single view change.

[hashanp]

@shadowhand I think I've got an idea which would work. Rather than foundation.js binding event handlers to individual elements, why can't it use event delegation so ONE event handler is added on document which captures events through event bubbling. For example foundation.js could do:

$(document).delegate("click a[data-dropdown]", function(e) {
     // Show dropdown
});

Thus there would mean there would be no need to call reflow at all, for all new elements would be covered under the existing event handler.

[shadowhand]

@HashanP yes that's exactly what I suggested:

If every component bound only clicks, regardless of whether or not any corresponding element exists, it would be possible to have a single document.foundation call

The problem is that you cannot bind some events, such as mouseover, because it will fire continuously when the user is moving the cursor when bound to document. Foundation would have to find a way to address non-click events.

[hashanp]

Well now I feel like an idiot. What about using MutationObserver to listen to new nodes attached to the DOM. I know MutationObserver is only supported in DOM4 (that's IE11), but you can polyfill it with DOM3 Mutation Events (IE9), which is less efficient & now deprecated. I believe it is what the polymer project uses.

[techdragon]

@HashanP - I wouldnt really say there are many foundation plugins... If there are... their developers are very very bad at describing them, because I cant find more than perhaps a dozen plugins that are foundation native and not just theme agnostic jquery plugins... of which there are figuratively hundreds. So when it comes to 'where to publish' foundation plugins, my vote is for making the location as close to zurb as possible, if your a foundation developer, then your going to come back to look at the docs from time to time, suggesting NPM or any other ephemeral language specific directory is going to make it less likely that the plugins will be surfaced. If you need inspiration look at http://www.djangopackages.org - Yes python packages have pypi, yes they have crate.io, yes they have an incredibly easy to search syntax that makes them easy to search for directly on github, but picking plugins should be easy to do, and a site like that would make it very easy to decide which foundation plugin you needed.

[hashanp]

@techdragon I see your point, but firstly if there are so little packages I don't see the point of creating a whole new registry to accommodate them. I checked the website out - it's actually .com not .org - and I do like the idea (although not their implementation that much compared to NPM). I propose creating a more advanced version of http://gruntjs.com/plugins, or http://gulpjs.com/plugins/, or http://yeoman.io/community-generators.html, or http://klei.github.io/slush/#/, with more filtering options. What they do, and note slush has relatively few packages at time of writing, is they piggyback on NPM, and query NPM for packages with a certain keyword. I would be happy to create this, if the community would be happy publishing plugins on NPM with the foundationplugin keyword, using https://github.com/npm/npm-registry-client. Also I think that some functionality presently in foundation should be split up into separate modular plugins, as well as the proposed affix plugin. Foundation themes such as https://github.com/toolsforliving/foundationify should be included as well.

[techdragon]

@HashanP - fairly important point about why NPM may not be best. Where do non JavaScript plugins go? If I maintain a django plugin or a php module or anything other than JavaScript... Then NPM is a rather inappropriate place to store it. The nice upside of a new plugin listing is that it isn't necessarily tied to JavaScript which is why I suggested a tool like DjangoPackages, it doesn't mandate a particular package management tool chain and can act as a purely unificating force (users thinking "if it's for foundation it belongs in the index") as opposed to creating any more chances for valuable foundation resources to remain hidden (users thinking "well my plugin isn't JavaScript so I'm not going to package it for NPM, I'm sure if anyone wants it they can find it"). One other advantage of DjangoPackages is I don't have to be the maintainer to edit metadata or add a package I just found on GitHub, it makes the discovery, curation and new content on boarding process easier, leaving package management to the package owners discretion.

[klangwiedergabe]

A better off-canvas implementation for a more native app feel. Such as, fixed tapbar and fixed aside content(the offcanvas content is visible even if I'm at the bottom of the page) with a self scroll.

[istrasoft]

+1 for AMD support +1 for more plugins (pickers, smart selects

• Full RTL support : SAME html markup used to display RTL and LTR version of the same page, which is not the case now.

[mazzech]

mega menu, full screen image slider

[thierryrene]

Easy CSS transition animations, mote advanced grid options and more focus on media elements like pictures, videos and audio.

[oliverklee]

If the 6.0 release required Sass 3.3 (if I understand this correctly), can we also fix these deprecation warnings? https://github.com/zurb/foundation/pull/5258

[cmoralesweb]

@HashanP

+1 to the WAI-ARIA stuff. By the way,

"and buttons could be defined with <a role="button">"

Isn't a link with a button role, essentially, a button? :tongue:

[cautionbug]

After going through some of the Javascript recently, i see some room for clean-up, stronger coding conventions, etc. It would be nice to see the next major version not only clean up a lot of redundant, bulky code as mentioned above, but some strong guidelines for contributors to follow. Even if contributors might disagree with particular style guide details, at least they'd be expected to follow them for pull requests to be approved. It could also make the code run faster, and reduce bugs introduced by unclear code.

Also, Foundation-managed Date/Time-Picker widget. i know there are a couple out there, but it's not as good as having such a fundamental widget included in the main framework, for compatibility and continuity. :smile:

[klangwiedergabe]

+1

[chrisjlee]

• More modular components
• Implementing Web Components
• Implement styling for Dialog Modal: http://updates.html5rocks.com/2013/09/dialog-element-Modals-made-easy
• integration with angular / ember.js

[hashanp]

@chrisjlee #4212

[vinayraghu]

+1 for web components. @zurbrandon, @thedeerchild Is this something you guys are looking into? I'd love to pitch in if that's the case

[cvrebert]

For Affix, you might consider using https://github.com/filamentgroup/fixed-sticky

[zurbrandon]

Woah Hey Guys! Lot's of good stuff here, i'll be going over this today and hopefully addressing it all for the future of Foundation.

To clarify, Foundation "6" will consist of Foundation for Emails, Foundation for Sites, and Foundation for Apps. The first release of which will be Foundation for apps, in which we'll be flipping a lot of Foundation stuff on it's head.

Love that everyone is so excited and i can't wait to have all these brains working towards the most advanced framework yet.

[klangwiedergabe]

You guys are awesome :)

[istrasoft]

Regarding Foundation for Apps, given the size of Angular, don't you feel the lightweight and sleek side of Foundation is gone and it's becoming a behemoth with huge dependencies etc ?

[zurbrandon]

@istrasoft Last i looked Jquery was like 80KB minified and Angular like 35KB, but i may be misremembering. Apps are most likely going to be larger by default and thats why we've decided to keep Apps and Sites as separate things. When you need the power of an App Foundation for Apps and when you need a Marketing site Foundation for Sites.

We're going to attempt to do to Angular what we did for CSS and Components. Give you the base (Foundation) of what you need and then let you build from that.

[istrasoft]

Okay, amazing ! Thanks :) I know it's only 35Kb but it also forces a lot of quite verbose conventions for data binding which, added to the foundation html arguments can add a lot of overhead. anyway, i can't wait to see what you have in stock for all of us !

[lozandier]

Regarding web components and Modular JS

@chrisjlee Being familiar w/ web components (natively and through web component libraries such as Polymer), and ES6 modules—as well as tools such as browserify to make modular JS architectures a lot easier to realize—such things are being worked on for Foundation for Apps.

As you may be aware, future versions of Angular, Ember, and other popular frameworks will be re-engineered to work better with Web components and ES6—particularly accessing and leveraging the power of observers, the Shadow DOM, the template element and its model and bind properties; ES6 proxies, and other exciting features.

Accordingly, these things should allow Foundation for Apps to be more framework-agnostic than when it was originally announced.

When it comes to module JS, not much work has been done towards a particular architecture for the JS associated with Foundation for Apps yet (as far as I know).

That said, it has to be done in a modular way to meet the goals of the project I'd imagine, and the end users of the framework to make apps—developing JavaScript applications in a modular way is a common best practice by modern intermediate to advanced web developers today.

Regarding the Dialog element

@HashanP I myself have voiced support for the dialog element.

Towards the efforts of Foundation for Sites being more accessible, there are in fact plans to finally implement support for the dialog tag.

Chrome 37 and only the recent versions version of Firefox have native support for it as far as I know, but the polyfill is decent enough for it to be supported now, in my opinion.

That said, there's no reason for Foundation for Apps to not have support for it.

Reveal without the use of dialog is currently being planned to be compliant with WCAG standards, and it's not decided whether or not support for dialog will be implemented during the final stages of such changes or afterwards.

Being familiar with the basics of using dialog, considering the JS changes needed to be made (for example, reveal shouldn't allow other elements to be focusable when active except the address bar via esc), it's undecided whether support for it will be shipped within the next release or soon after the release that'll address accessibility woes of Foundation.

It may very well be an implementation separate from the core version of Reveal to be shipped faster.

Regarding Dependencies

@istrasoft With a modular design, such things shouldn't be a problem. Given the fact evergreen browsers are only supported with Foundation for Apps, a lot of weight that was often added to Foundation for Sites to support older browsers not ideal accounting for during the prototyping stage of a web application will be dropped.

[chrisjlee]

Oh one more. I would like to see Foundation 6 written in ES6. A nice to have.

[lozandier]

I want to as well and know how, but decisions regarding the JS architecture haven't even started.

Whether or not to support recently changed ES6 features such as the modules may limit how much of ES6 is implied to the codebase.

For now, I personally use CoffeeScript that can easily be translated to ES6 due to the explicit inspirations ES6 has with many of CoffeeScript's features/constructs:

• List comprehensions
• Arrow functions that override the value of this
• deconstructors
• string templating and more...

Similarly, I think some sort of modularity system needs to be in place to keep things maintainable much more than Foundation 5; if not ES6 modules, then browserify at least, in my opinion.

On Tuesday, August 12, 2014, Chris J. Lee notifications@github.com wrote:

Oh one more. I would like to see Foundation 6 written in ES6. A nice to have.

— Reply to this email directly or view it on GitHub https://github.com/zurb/foundation/issues/4710#issuecomment-52009829.

[davidagnome]

Working implementation of Fix Top Navigation with Full-Body Off-Canvas Menu, both overlap and move method.

[chris-canipe]

It would be great to see more classes and less elements in the CSS ala https://github.com/zurb/foundation/issues/5845.

[gakimball]

For 6 we should look at our use of semantics in components. There are a lot of examples where we're misusing <section>, <label>, and especially <dl>. I don't know if total W3C validation is possible (it's also something ZURB once gave a somewhat controversial opinion on), but we should at least think harder when we think we want to use a tag other than <div> or <span>.

[Harti]

I understand that it would be possible for someone to actually program it and put it on GitHub as a third-party plugin, but I would really like to see something like a Combobox element implemented in F6: https://github.com/danielfarrell/bootstrap-combobox

In a nutshell, it's an autocomplete text input, but with predefined answers the user can (but doesn't have to) pick one from.

Thanks for considering!

[rafibomb]

@Harti It's something that if @danielfarrell sees this as valuable to make for Foundation we would help promote it.

[rafibomb]

Remove uber specific selectors. https://github.com/zurb/foundation/issues/3974

[rafibomb]

Use HTML5 storage
https://github.com/zurb/foundation/issues/4470

[Schyzophrenic]

:+1: For not having to call a "reflow" whenever we add new elements to the DOM.

I have recently migrated a rather large full ajax website from bootstrap to Foundation and this was the biggest problem I had. It means I had to modify the way the site works in order to include Foundation whereas I was just expecting css / html and a few different JS calls at some point.

[r3wt]

I cannot stand the markup for accordions. i hated it so much that i just made my own instead and omit f5's accordion in projects.

I think the dt should be used as an anchor and the dd being used as a panel.

example

https://github.com/r3wt/simple-accordion/blob/master/accordion.html#L53

[r3wt]

also, equalizer is severely limited in that you can only put data-equalizer-watch on a direct descendant of the parent element with the data-equalizer attribute. a js plugin would be nice, but don't stop there. we should have a new data attribute or classes to dictate at which screen sizes the height match should occur. most elements tend to become small-12 after all for mobile, so the height match is probably not necessary at these screen size, and could create ugly excess whitespace. just my 2 cents.