Orbit is going to be the easiest slider you've ever hooked up. Below are the steps, but for more detail checkout the playground docs.
Tabs are very versatile both as organization and navigational constructs. To keep things easy for everyone we've created two main tab styles (simple and nice) as well as two variants of each - open and contained. With the base Foundation package, tabs of a particular format are actually already hooked up - no extra work required.
Tabs are made of two objects:a DL object containing the tabs themselves, and a UL object containing the tab content. If you simply want visual tabs (as seen in this documentation) without the on-page hookup, you only need the DL. If you want functional tabs, just be sure that each tab is linked to an ID, and that the corresponding tab has an ID of tabnameTab. Check out these examples.
Note: The third tab is using the mobile visibility classes to hide on small devices.
Contained tabs have a simple added class of 'contained' on the tabs-content element. What that means is the tab content has a border around it tying it to the tabs, and the padding on that container (by default) is one column on each side. That means you can still use standard column sizes inside a tab element.
Need something a little fancier? Nice tabs have some sweet default styling and can add a little polish to a prototype (or documentation). They can be both standard and contained, just like the simple tabs.
You can also use tabs in a vertical configuration by adding a class of 'vertical' to the DL element. These are great for more scalable nav, and you can see how they work on this page on a tablet or desktop.
To demonstrate how mobile navigation can work, adding a class of 'mobile' to a tab group will switch them (at small resolutions) to full width nav bars.
Inputs support a number of different base classes. Any text input has a class of 'input-text' and supports several sizes:
Inline labels are accomplished using the HTML5 Placeholder attribute, with a built-in JS fallback.
Error states can be applied in two ways:
Changing the form style to a slightly fancier version is dead simple - just add a class of 'nice' to the form itself.
Creating easy to style custom form elements is so crazy easy, it's practically a crime. Just add a class of 'custom' to a form and, if you want, forms.jquery.js will do everything for you.
The Foundation forms js will look for any checkbox, radio button, or select element and replace it with custom markup that is already styled with forms.css.
If you want to avoid a potential flash (waiting for js to load and replace your default elements) you can supply the custom markup as part of the page, and the js will instead simply map the custom elements to the inputs.
Foundation custom forms will even correctly respect and apply default states for radio, checkbox and select elements. You can use the 'checked' or 'selected' properties just like normal, and the js will apply that as soon as the page loads.
This is a dropdown This is another option Look, a third option This is a dropdown This is another option Look, a third option
If you are creating these custom forms using JavaScript (via AJAX, JavaScript templates or whatever), you will also need to create the custom markup that Foundation typically creates for you.
Foundation detects any custom forms when the document has loaded and adds the custom markup required to make the forms pretty. However if you are adding these forms after the document has loaded, Foundation does not know to append this markup.
All the custom forms events are bound using jQuery.fn.on(), so you don't need to worry about event handlers not being bound to new elements.
Most of the documentation is by the Zurb Team. It's awesome & I'm thankful that they wrote such thorough documentation for an open source project. Most companies would never do that.