Foundation-sites: 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 [email protected] 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.

[cmoralesweb]

Clearing is limited to just images, which is a big limitation to have. If you want to create a gallery from thumbnails you have to put a slider (external, since Orbit is deprecated) within a modal or some weird solution like that.

Magnific, for example, is way more versatile http://dimsemenov.com/plugins/magnific-popup/

[rafibomb]

Suggestion: Use consistent submenu classes (dropdown, offcanvas) #6048

[gakimball]

Less use of !important in our codebase would be ideal. In theory, only visibility classes should need it. #5702

[gakimball]

Tag-based typography styles should be a separate import option from the typography helper classes. #5665

[gakimball]

Foundation 6 should have better vertical rhythm, most likely by way of a few global spacing variables. #5653

[gakimball]

rvinay88 suggested we use the grunt-combine-mq plugin to make our CSS even more compact. There's also a Gulp version in case we decide to switch task runners in F6. #4873

[gakimball]

It's been suggested that we cut down on the number of color variables in Foundation. #5645

[gakimball]

It's been suggested we use the native styling abilities of <input type="range"> instead of having a separate range slider component. This may be an option, but it's not supported in IE9 and it's wonky in IE10/11. #5394

[gakimball]

For the next version of Abide, let's look at leveraging more of the built-in form attributes, such as max: #4059

[gakimball]

rvinay88 suggested adding a universal "disabler" class (could also be a data attribute), which will cause the JavaScript to ignore those elements when initializing plugins. #4773

[gakimball]

It's been suggested to add another form element for adding help text to fields. #5331

[gakimball]

A few folks are in support of the idea to allow for range sliders with two handles. #5560

[gakimball]

Improve accordions so you can decide which pane is open first, or which pane is open first on different screen sizes. #5519

[gakimball]

Add disabled classes to switches. #5453

[gakimball]

Allow tab and accordion items to be deep linked without using a hash, to work better with single-page apps. #5597

[rafibomb]

Block-grid and visibility improvement https://github.com/zurb/foundation/issues/6095

[rafibomb]

Sorry, not closing this!

[gakimball]

@athanclark asked if Abide currently had an interface allowing you to grab the states of input elements using JavaScript. Adding more features like this to the JS (not just event-based stuff) would make our plugins way more powerful. #6166

[PsykoSoldi3r]

Option for position and alignment tooltips.
Alignment: center, left, right
Position: top, bottom, left, right

[rnaud]

Less overwriting of base html elements. I'd rather have a table.table {} definition than a table {} one that makes it hard to use table elements with the default behavior.

Also +1 on no reflow.

My last one would be making more elements able to load content remotely. Modals can do it but tooltips cannot.

[gakimball]

We've gotten a number of requests for date and time pickers. #6176

[cautionbug]

@gakimball YESYESYESYES! There is a calendar picker out there that _mostly_ works (i've had to do some monkeywrenching with how it handles empty values), but it might be a decent starting point:

https://github.com/jockmac22/foundation_calendar_date_time_picker

[rafibomb]

@cautionbug Thanks for the tip! We'll check it out!

[cautionbug]

@rafibomb i may set up a fork of it, since it doesn't seem there have been any significant changes in quite a while. i'll commit what i did there & follow up here.

So far, the list is looking really good. Ambitious, well-considered... looking forward to what actually makes it into the road map.

[anish274]

is foundation planning for material design? I love zurb but my website needs material design. Any Solution?

[ryanmargheriti]

Your website doesnt _need_ material design @anish274. Nor do developers _need_ another material design theme.

Use one of these instead:

• https://fezvrasta.github.io/bootstrap-material-design/
• https://github.com/angular/material

[anish274]

@ryanmargheriti but my site is already implemented in foundation and the 1st link is the material version of bootstrap. So if my site is bootstrap I can convert it to material design using above link ( I think not sure).
I am totally unaware of angular.

[gakimball]

@anish274 We'll leave creating Material skins for Foundation up to the community.

Material Design is a very structured and opinionated system for building interfaces, while Foundation is just meant to be a baseline for a project. It's not the role of our framework to lay that out for you.

[davidagnome]

Agreed. Material design is how one company is branding their apps and ux.

I get a sense that the question was related mobile apps in Cordova, in which case Ionic or Foundation for Apps would be more appropriate for applying Material Design conventions to.

Foundation is just that -- a foundation upon which beautiful architecture is expressed.

---- Geoff Kimball wrote ----

@anish274 We'll leave creating Material skins for Foundation up to the community.

Material Design is a very structured and opinionated system for building interfaces, while Foundation is just meant to be a baseline for a project. It's not the role of our framework to lay that out for you.

---

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

[cmoralesweb]

@anish274 If your site "is foundation" and you have to "convert it" to material design (or bootstrap, or whatever) you have a problem.

[thierryrene]

@anish274 try this http://ui.lumapps.com/

[gakimball]

We've had a request for Material-style circular buttons: #6217

[listepo]

customizable select box with support for searching, tagging, remote data sets, infinite scrolling, and many other highly used options?

[Phil-A-Delphia]

How about including a forum like the one used on the Foundation website?

[darkcyber]

+1 for admin menu ( admin tools ), like admin LTE and the other.
maybe full width row

[themestechnology]

How about integrating Font Awesome icons, it seems that quite a lot of people are running both in there app, it would make CSS a bit tidier and help with things like chevrons for menus and breacurms

[jr-duboc]

+1 for admin menu, modular structure and Afix

[themestechnology]

How about including a schema / schema.org and Google's Rich Snippets for better SEO?

ie http://schema.org/SiteNavigationElement
http://schema.org/WebPageElement

I could do a pull request if people think this would be worth while

[gakimball]

@themestechnology How can we incorporate these rich data hooks into the framework without any data? Wouldn't that be the job of the developer using the framework?

[themestechnology]

Well the demo/examples can include this such as Foundation Breadcrumb can have the correct schema and the < nav class="top-bar" data-topbar role="navigation" > can be marked as a navigation element, etc follow by example

[jr-duboc]

@themestechnology I tend to agree with @gakimball : I'd say rich data hooks are the responsibility of the developers using Foundation, even though minimal rich data should be included where it makes sense (such as in the navigation example you mentioned)

[darkcyber]

@themestechnology
+1 for font awesome because lot of icons.

[themestechnology]

Well yes @jr-duboc , @gakimball does have a point that not everything can be included such as content definition but it could be considered that the more commonly used element definitions would help enhance peoples apps with out the need to re-invent a new tec

For example things that might be strongly considered...

Navigation elements: < nav class="top-bar" data-topbar role="navigation" itemscope itemtype="http://schema.org/SiteNavigationElement" >

Sidebars (in example documents) : < aside role="complementary" itemscope itemtype="http://schema.org/WPSideBar" >

Breadcrumbs: < ul xmlns:v="http://rdf.data-vocabulary.org/" class="breadcrumbs" >
< li typeof="v:Breadcrumb" >
< a href="#" rel="v:url" title="" >< span property="v:title" >#< /span >< /a >
< /li >
< /ul >

Website Page < body class="antialiased hide-extras" itemscope itemtype="http://schema.org/WebSite">

*on some occasions content blocks

[jr-duboc]

@themestechnology hmmm good point, perhaps adding a few missing rich data snippets where it makes sense...
@gakimball

[adamj88]

How about using SassDoc (http://sassdoc.com) to document the code base? One thing I find lacking when using the Scss is the lack of inline comments/docs for all functions and mixins,

[gakimball]

@adamj88 Yes! We're building a tool that will generate documentation from Hologram, SassDoc, and JSDoc. This will also make it easier to design more detailed documentation for the variables and mixins. (See the Neat documentation for an example.)

[erredeco]

notification system like oh-snap or similar ones?

[gakimball]

Joyride's functionality could be separated into two plugins: one for the popover, and one for the feature tour. #6251

[gakimball]

Load images in Clearing using data URIs instead of the source attribute. #6244

[airtonix]

• [ ] move back to libsass

[gakimball]

@airtonix The codebase already supports libsass, although we might remove the Compass template from our CLI, and only distribute templates that use libsass.

[airtonix]

@gakimball heh. just a brief weekend fling with ruby.

[johnhamelink]

:+1: for no reflow - It's a massive pain to have to run that method in Ember

[vinayraghu]

Thinking out loud here. I want to be able to extend the concept of modularity to Sass components as well. If I want to just use Foundation's grid alone on my next project, it should be easy to get this component alone.

Right now, if I try to do this, I need some to import globals, use _functions and it's a pain to separate this component alone. Would be awesome if all functions, mixins and variables required by a component is defined within the same sass file.

[gakimball]

@rvinay88 If you mean _defining_ functions within the file versus just importing them, that's not likely to change. We can't anticipate if a function will ever be used on multiple components or not, so we keep them in a separate file. In Foundation 6 our Sass utilities will be a lot more organized, and also separated into multiple files (e.g., units, maps, colors). It's also better for version control if we keep these things in separate files, which is another reason we're moving away from one big functions file.

The components themselves establish dependencies through imports. So right now _grid.scss imports _global.scss, which imports _functions.scss. If any component in Foundation 5 isn't properly importing its dependencies, then that's a bug and we can fix it.

[sunhump]

Improved off canvad
Better looking icons
Simple parallax component

[anish274]

some example templates for beginners like Landing Page or Blog or Email layouts.
The structured HTML issues which I faced when I started.

[gakimball]

@sunhump What would you like to see improved with off-canvas? Our plan right now is to make the component way more generic, as in just an empty box that slides in and out. It won't have built-in menu styles; instead you'll be able to use the menu bar component, or write your own.

[sunhump]

@gakimball Sounds good. On top of my head: ability to make it fixed and also add option to overlay content not just push.

[erredeco]

Suggestion: I would like a component that could be called "expander" or "modal expander"
Some examples:

http://tympanus.net/Development/CheckoutConcepts/boxes.html (click the cart)
http://tympanus.net/Development/MorphingSearch/ (click on search)

[erredeco]

about media queries: I also vote for an x-small media query around 480px

[gakimball]

@erredeco We're looking into lowering all of the breakpoints across the board by around 100 pixels. Right now the upper end of small is awkward (it's often a super wide one-column layout), and the lower end of medium is awkward (it's often a super narrow two-column layout).

We'll have to do some experimentation on existing layouts to figure out what the right numbers are. Luckily, it's way easier to mess with breakpoints in Foundation 6. We started some of this in Foundation for Apps, but it'll have more improvements in Foundation for Sites 6.

[gakimball]

Right now Abide overloads the pattern attribute to add shortcuts for specific patterns, like colors, CCVs, etc. However, this is problematic if the user has JavaScript enabled, in which case the browser-specific validation kicks in, and pattern="email" would just become a regexp for the word "email".

One solution, as suggested in #6501 is to use data-pattern instead of pattern, to keep the two separate.

[florianbouvot]

Use BEM naming convention ?

[SalahAdDin]

:+1:

[aibrean]

HoverIntent for the top bar or hover delay (like with dropdown buttons).

[SalahAdDin]

I want help whit this useful features:
centered-block
help-text
badges
signboard(seems like boostrap panels)
list-groups(maybe)

Are you agreed wit this features or you will have problem wit this features?

Thank you.

[gakimball]

@SalahAdDin Help text for forms we're thinking about, but it's such a simple component that we aren't sure if it's worth the extra class. Badges we're doing, and panels we currently have, if that's what you mean by signboard. If you're thinking more like Bootstrap's jumbotron, we aren't doing that.

Could you explain what you mean by centered block and list groups?

[SalahAdDin]

I don't understand, why help-text is a simple component?
Oh, Jumbotron is a useless class, jajajajaja, don't worry. Yes, i want means bootstrap panels.
Well, for center block i mean

.center-block {
    display: block;
    margin-left: auto;
    margin-right: auto;
}

Well, and where can i see the badges and panels? I am using this class in a project but i don't want use boostrap anymore, but, i need this class very much.

Thanks.

[SalahAdDin]

And +1 for https://github.com/Ben348/Foundation-Sidebar :+1:, and I need very urgently this feature.

[themestechnology]

I think improvement in the Grid Push/Pull should be looked at, it seems to work well enough for two blocks horizontally with a medium-6-push/medium-6-pull but there does not seem to be anything for swapping two blocks vertically with each other in say mobile view small-12-push/small-12-pull.

I found this frustrating when I was looking at putting the "top-bar" menu at the top above the site header for mobile size screens.

[SalahAdDin]

What's about page-header?

.page-header{
  padding-bottom:rem-calc(5);
  @include rem(margin, 40px 0 20px);
  border-bottom:1px solid $smoke;
}

I think that is very handsome.

[NiklasBr]

:+1: for the Sidebar, and Flexbox mentioned by some people already.

[erredeco]

http://tympanus.net/Development/SidebarTransitions/

[SalahAdDin]

:+1: http://tympanus.net/Development/SidebarTransitions/

[erredeco]

I would like to add another suggestion, maybe it has been already discussed...
I would like to make the the "dropdown button" component more flexible:
I mean:

• should be possible to use any Icon or text to open the dropdown
• it should be possible to add icon rotation

this means that the "dropdown button" should be removed as a "special" component... the only component should be "dropdown"

[gakimball]

Abide skips validation on hidden fields, which is problematic if you have fields inside a plugin that hides content, like tabs and accordions. We could add some sort of override mechanic to force fields to validate. #6625

[brendanvinson]

Better structure for radio and checkbox lists than just row>column+column as it's overly clunky.

You can hack block-grid to work, but something intentional would be better.

[collimarco]

+1 For an autocomplete / typeahead (that can query a remote API). It is an _UI element_ that I use in most of my projects and I always have to develop custom solutions or add other heavy libraries only for that (e.g. jQuery UI).

[mediabeastnz]

Does anyone find writing rem-calc() is tedious? Can this function be shortened somehow? maybe to just remc() or rc()?

I use this as a px replacement so typing it (atom does a decent job at auto complete) gets a bit old.

[erredeco]

http://codepen.io/rgg/pen/waEYye
nothing really new here... but maybe nice for inspiration

[darkwoods-]

I would love to see a better top-bar when it comes to customizing it, as the current top-bar can be very painful to customize..

Like for example sometimes I have to do different heights for different media-queries and this messes up it all.

Or sometimes if I add radius into the top level menu it ends up with effecting the drop downs and messing it all again.

What I'm trying to say here that I don't feel like the current top-bar can be easily customized or it makes you very limited to stay with the default style.

So basically it would be nice to see more SASS customization control over the top-bar by focusing on that there will be in many cases lots of different styles for it on different media queries.

[mediabeastnz]

^ what he said!!! And make it semantically correct.

[SalahAdDin]

Don't remove Orbit Slider please, is very easy use him, and slick-slider isn't completly, i'm trying make thins that in orbit slider were easey, but, in slick it's very complicated.

[sharmashivanand]

We should have an option to change css specificity. Perhaps:

<.mynamespace> {
…foundation SCSS…
}

or be able to put in a custom namespace to make foundation CSS selector specific. This will help people like me who just want to download and use foundation inside a WordPress theme.

[themestechnology]

@shivanandwp http://foundationpress.olefredrik.com/

[themestechnology]

Lots of people asking for things... perhaps the devs at foundation should gather 50 of the best and do a multi vote poll

[gakimball]

@shivanandwp This will be possible in Foundation 6 because all CSS exporting is done through mixins.

#foundation {
  @include foundation-everything; // Exports all CSS
  @include foundation-buttons; // Exports a specific component
}

@themestechnology Way ahead of you :) Here's a Trello board with a bunch of feature requests: https://trello.com/b/QBPKlQqf/foundation-sites

[collimarco]

I would like a clear, documented way to share Foundation global variables with the Rails application stylesheets, so that I can reuse the settings in my custom CSS.

At the moment you have to add the following to application.css:

@import 'foundation_and_overrides';
@import 'a_custom_css_that_uses_foundation_settings';

However you cannot use the more proper = require of the asset pipeline that keeps the scopes separated.

It would be better to have a file called foundation_settings (that contains only the settings and doesn't import the framework) that is @imported by Foundation and by your custom CSS that needs to access the global variables.

[SalahAdDin]

Man, what's about the lisft group?
I use this list group, the bootstrap list group for make a elegant list, and use badges, but now, i don't know how adapt this to Foundation.

Are you thinking about it?

[themestechnology]

@collimarco

Copy foundation/scss/foundation/_settings.scss to foundation/scss/

rename it to _custom_settings.scss

Open foundation/scss/foundation.scss at the top of the file add @import "custom_settings";

Now you can set-up your variables using _custom_settings.scss and this will not be effected by updates

[collimarco]

@themestechnology That's still a workaround and it's not a viable solution if you use foundation-rails gem.

[SalahAdDin]

@gakimball, are you thinking about adapt bootstrap panels to Foundation? I use this in a previous version of my project and have adapt it to Foundation, foundation panels isn't useful as bootstrap panels(panel with various colors, tables, list groups), and i had to use pricing tables for adapt it.

And list group, i mean, bootstrap list groups, Foundation haven't any like this and i think that are a beautiful and elegant solution for a index page.

Help-text will be useful for people that need put a help-text class because his backend don't put place holders in the forms, as me, i work with django and wagtail, and wagtail don't put placeholders in form's inputs. It's very simple do it.

Center-block i used one time, so, i think that will be a helper class but not important class.

Badges will be a global feature for Foundation and not only Foundation for apps feature, and this have an advantage, bootstrap haven't a multicolor badges, but Foundation for Apps have, it's great!
And Basic card is very good, melt with v-car and will be great feature :D

I think that will be great if you'll implement a multiple color panels, as boostrap, will be very useful,
to put different panels depending on the context you want; maybe will be great put multiple colors to pricing tables.

I have been working hard to adapt my project and I compared Foundation, and put here the ideas that came to me. I want to share more ideas and know what you think of them and speedily Foundation 6 as Bootstrap 4 is soon to come.

[zurbrandon]

Hey All!
Thanks so much for the amazing feedback on what you are interested in seeing for Foundation 6. The team has been following, responding and acting on this list and we're really excited to be pushing out Foundation 6 pretty shortly. While not every item was done from this we used it as an invaluable roadmap for the goals of the framework. If Foundation 6 launches without a feature you suggested and still want to voice that please feel free to speak up, there's a chance we implemented it differently for a reason or a chance it simply slipped through the cracks.

Super excited for Foundation 6 Launch and really appreciate the Foundation Community.

Thankyousomuch,
Brandon (Foundation Team Lead)

[jarrydfillmore]

These are awesome suggestions :)

[dsandstrom]

Was min/max added to Abide's number validation (https://github.com/zurb/foundation-sites/issues/4059)? It's supported by HTML5 validation, so it seems like Abide should handle it also. For now, I will make a custom pattern.