Bootstrap 3 Succinctly: Changed CSS Features

So far you’ve already seen a number of the new CSS features that are available in version 3 of Bootstrap. In this tutorial we’ll go into a little more detail about just what is considered new and what’s not. 

In many cases these new classes are just renames of the old ones, but we treat them as new here so that you can easily make the distinction. 

Typography Changes 

The various classes that make up BS3’s typography section haven’t changed as much as some of the other elements. Tags H1 through H6 are still treated the same way as they were in v2, with the addition that you can now use <small> in line with any header element without it first having to be wrapped in a div using the page-header class. This means no extra markup now, unless you want your block heading to be underlined with a different paragraph margin. 

In v2 you had no choice but to wrap your H1 in a page-header div, as this was the only way the small tags output would be neatly lined up. This has now been rectified and also applied to all levels of header, rather than just the first three.

Continuing on, the standard body copy class has no changes, and remains at a default size of 14 pixels with a line height of about 1.4. 

Body copy is applied to all text inside a paragraph tag automatically, so no classes are needed unless you want to use some of the special features (as we’ll see soon). 

Lead body copy (paragraphs with the class name of lead) also have no changes to their names or styling, and as with v2, are designed to give your opening paragraph a bit more emphasis than the other regular body copy. Combining these three CSS rules, you might have something like the following: 

When rendered in your browser, it should look like the following: 

Image of sample webpage with text This is my super webpage

The <small> tag can now also be used on its own too, as its styling is now correctly handled and applied in the context in which it’s used, so its styling will follow its position in the document no matter what the parent tag. 

Similarly, bold text is still created using the <strong> tag and italics using the <em> tag; as with many of the typography classes, this is no different to the v2 framework. 

The alignment classes also maintain their same class names of text-left, text-center, text-right, and text-justify, and still perform the same functions as described in the BS2 book that precedes this series. 

Likewise, abbreviations are still created using the <abbr> tag with the title attribute acting as the full description of the abbreviation. There is one new class, initialism, that can be added to an abbreviation tag and gives the rendered output a slightly smaller look and feel than the surrounding text. 

Addresses (using the <address> tag) and block-quotes (using the <blockquote> tag) also have no changes in the CSS or base rules between v2 and v3 of the framework. 

The final few tags that remain in the typographic category include <code>, used to create an inline code sample. Again, this has not changed in any way, with its intended use still being for code samples that sit in line with regular body text. 

For code samples (or anything that is plain text) that must remain formatted as per indentation and carriage returns, you should still use the <pre> tag; again the styling here has not changed from v2, and layout using this tag should still behave as expected. 

The final typographic element is the addition of a new element called <kbd>

The purpose of this new tag is to display text in a way that indicates the user should enter the information into the computer in some way, generally by typing it. 

For example: 

Which when rendered in an HTML document, should look something like the following: 

Image of text showing code text highlighted

List Changes 

In general, the normal list elements made up of <ul>, <ol>, and <dl> elements have not changed; the layout is still as it was in BS2, with no extra classes being needed. Note also that the list-unstyled, list-inline along with the dl-horizontal classes for definition lists also remain unchanged in BS3, and have the same behavior as in BS2. 

There are some changes in the list elements however, but since these occur with the specialist classes used to create menus and navigation lists, we’ll be covering those when we address the changes to the navigation elements in the next chapter. 

Table Changes 

Tables are still styled just as they were in BS2 by creating a standard <table> arrangement, then adding a table class to the markup. As in BS2, tables should always be constructed using the full range of <table>, <thead>, and <tbody> HTML elements as the following example shows: 

This markup should give you the following: 

Table styled for Bootstrap

As with BS2, the classes to add the optional styles to a table—table-striped, table-bordered, table-hover, and table-condensed—work exactly the same as in BS2; these extra classes are added as secondary classes to the main table class on the table element itself. 

This code, for example, will give you a table that has an outer border and alternating colors on each table row. 

One thing to note however, is that table striping now uses the :nth-child pseudo selector, which means that it will no longer work in IE8 or earlier without a poly-fill or other fix to help. 

The remainder of the table classes for coloring your table rows have changed slightly. Firstly there is a new class called active. Before BS3, the active class was not available on all elements, but mainly just on navigation and button elements. From BS3 onwards it can now be applied to a <tr> element to show that row as a highlighted row, which by default is a light grey. 

The remaining contextual classes, as with BS2, are designed to highlight the table rows to show different conditions, and are the same, except for one small change. 

The class name representing a dangerous or negative action has been renamed to danger. In BS2 the red class was named error. Other than that, the classes are applied the same way to the <tr> element as the following code shows: 

When rendered, it should look something like this: 

Table with rows shaded in different colors

There are two new additions to the classes used to support tables. First, there is a new responsive class that takes in to account the size of your grid system and provides either vertical scroll bars or a realigned table to fit differing size displays. Secondly, there’s the ability to use the aforementioned colored row classes on individual cells, rather than just entire rows, as was the case in BS2. 

To use the coloring classes on a cell level, you just need to add the classes to individual <td> or <th> elements as follows: 

This code should result in the following: 

Table with cells shaded in different colors

The final table-related addition is a class called table-responsive, which you can use by applying it to a <div> element that wraps the entire <table> as follows: 

When this new class is used on a display greater than 768 pixels (that is, any display using a sizing class other than *-xs-*), then the table display will behave like a normal bootstrap-responsive table. However, if the table is displayed on a device that targets an *-xs-* class and is less than 768 pixels, the container will be altered so that a vertical scroll is available, allowing the entire table to be moved left and right without affecting the rest of the page. 

Output from code sample 17 on a device greater than 768 pixels in width

Output from code sample on a device greater than 768 pixels in width
Output from code sample 17 on a device less than 768 pixels in width

Output from code sample on a device less than 768 pixels in width

Form Changes 

As with BS2, all normal form elements by default have a minimum level of markup that gives them a base style. This means that simply just marking up a normal form tag and associated controls will give your form the default Bootstrap look and feel. 

Take the following example: 

If we render this example in a browser, we’ll see that we get a reasonably good output without adding any extra classes, as you can see in the following image: 

Form rendered without adding any extra classes

Note: Since the previous example was written, there has been a minor update to the BS3 code. If you try the example as it is written here, the output will likely not look as expected. The change that has been made in BS3 seems to now mean that just marking up a form without any BS3 classes will not have the effect of giving the form a consistent look and feel. I‘ve left the example here, as it agrees with the information that is still present on the documentation site, and as such still appears to be the official advice by the framework authors.

As I mentioned in the migration section, the classes and components around HTML forms have been some of the biggest casualties when it comes to class name changes, but this is for a good reason. 

Before BS3, many of the classes used for forms were very narrow in scope—there were individual classes for many individual purposes, rather than a single class that covered many bases. For example, there were separate classes to handle the alignments of check boxes and radio buttons, and there were separate classes to handle input boxes and text areas with respect to their row alignment. 

In BS3 many of these classes have been deleted and are now all rolled up under a smaller number of classes and elements. 

Taking our previous example and adding in the recommended markup as is shown in the BS3 documentation gives us the following: 

Externally, if you render this code, you’ll see no difference to the output generated for sample 18. Internally, however, Bootstrap can now find and work with individual elements much more easily than it could previously. 

In BS2 there was no requirement to group controls unless you wanted to work with the automatic validation classes. There’s still no absolute requirement to use them, but doing so allows BS to resize and reposition things correctly when using its grid (among many other things). You’ll also note that each control now has just a single form-control class assigned to it, rather than many different ones targeting different aspects. 

Also note that the form tag itself now has a role assigned to it. This, apart from being good practice all around, is now enforced by BS3 to help with aria roles and standards guiding the use of web apps by people with disabilities. 

Lastly, if you look at the <p> tag with a help-block, you’ll notice that that is also now used for inline form text in all cases, whereas in BS2 we had a number of different classes, such as form-info

Unfortunately there is still one area in the support for forms that’s missing—the file upload control. Like BS2, this is due to the fact that security in all the current crop of browsers restricts the ability to style file input controls to match the rest of the input controls available. 

As I mentioned in the previous book, however, there are still third-party additions out there that have this area covered, and because you can now manufacture your own upload system using the HTML5 classes, strictly speaking you don’t need the file upload control—you can manufacture your own. 

In BS2 there were a number of specific form types such as the search-form; under BS3 all of these have been rolled up into three main types of form. First, you have the standard form; as we’ve seen, this is a normal form with no extra classes added to the form tag. The two other form types are form-inline and form-horizontal

The form-inline class is designed for forms in small, limited height places such as menu and navigation bars. A word of warning though: all input elements in this class and the other form types are sized 100 percent by default, so if you need the form to only take up a small amount of room (particularly in nav bar forms), you will need to put manual sizes on the individual controls. 

In the example from the previous code sample, adding form-inline or form-horizontal in turn should change your basic form layout to look like the following: 

Form produced by code sample 19 with the form-inline class added to the form tag

Form produced by previous code sample with the form-inline class added to the form tag.

The form-horizontal class is used to create regular top-down forms with input controls that have their associated labels to the left of them, rather than above them as the default form does. Be aware, however, that in order for form horizontal to work correctly, you need to add a little extra markup to the form in general, as shown in the following code sample. 

Note: In today‘s brave new world of HTML 5, it’s more important than ever to mark input elements up correctly with an associated label. Because disadvantaged users may be using aids to assist them, not providing the required pieces to allow these aids to work correctly will, going forward, be seen as a bad thing, and companies leaving them up could be shunned for doing so. Not to worry though—BS3 has you covered. If you decide you don’t want labels in your forms, you can mark them with an optional class, sr-only. Adding this class will visually prevent the label or associated help text from appearing in your document, but will ensure that it is marked up in such a way as to be visible by screen readers and other similar devices or software.

If you render the code from this example in your browser, it should look like the following: 

Output displayed from code sample 20 showing our form marked up as horizontal

Output displayed from previous code sample showing our form marked up as horizontal.

As you can see from the code in sample 20, the extra markup is not really that much more, and most of it exists just to line up the columns correctly so that everything sits nicely. 

The main points to be aware of in sample 20 are: 

  1. All label controls now have a class of control-label added. This is not required for the other form types, and BS2 will simply ignore it. 
  2. Any input control that will likely render as a block-level element is now wrapped in a parent <div> in order to control its width using the grid system. 
  3. The extra class for form-horizontal is applied to the outer-most form tag. 

For the rest of the classes and associated parts in the forms section of BS3, nothing else beyond the classes mentioned so far has changed. However, from an actual application point of view, input controls now must have a correct type on them to be styled. This means at a minimum you must have at least type="text" for BS3 to do its magic. 

It’s highly recommended that you do use the correct types, however. As you’ll see soon when we get to validation groups, having the correct type will allow most of the validation stuff to actually work correctly without making any changes to your markup. 

Check boxes and radio buttons, as in BS2, are stacked by default. If you wish to have them render vertically across the screen, you need to use the checkbox-inline and radio-inline classes as follows: 

Rendering sample 21 in your browser should look something like the following: 

Form with checkboxes 1 2 3

Select and multi-select boxes are marked up with standard styles just by using the elements as they stand; this is no change from BS2, where the markup and style of these elements is identical. 

One new style that has been introduced in BS3 is the static control style. In BS2, you often had to use a disabled form control to represent static form data that could not be changed. BS3 changes this by providing a form-control-static class that can be applied to individual controls in place of the regular form-control, as the following code shows: 

When rendered in the browser, this produces a regular form layout, with the static control clearly marked as not being editable or looking like an input control, as the following image shows: 

Regular form layout

The disabled style of form controls is still marked up and used in the same way as in BS2, simply by adding the “disabled” attribute to the input element as the following shows: 

This will produce the classic disabled and shaded control look, something like the following: 

Disabled input here message

If you add the disabled attribute to a field-set surrounding a form, all of the controls in that group will be disabled at the same time, using the same styling. This is something that didn’t happen in BS2—you instead had to mark up each individual control. 

The final thing I want to mention while on the subject of forms is the validation and focus classes. As I previously noted, adding the correct input types in HTML5 elements really helps you when it comes to using the validation classes. Why is that? 

In addition to having dedicated class names and styles for you to use, the validation classes also hook the new HTML5 pseudo-elements such as focus:, error:, and others. 

This means that if you mark a text box as type="email", and then don’t put an email address into it when submitting, the browser should automatically highlight the field red for you. 

If it does not, or you have some other way of making your validation work, then you can simply use the has-success, has-warning, and has-error classes on your form groups as the following code shows: 

If you render this code in your browser, you should see something like the following: 

Label for Form-group that has success warning error

Points to note are that I’ve added the classes to the form groups in order to produce a static display; however, you should also try just marking up the form with the correct input types. 

I’ve found browser support on the pseudo-classes is still a little patchy, even though there’s no mention of it in the BS3 docs, so I do recommend that you also make use of the class names when manipulating your elements using JavaScript. 

Also note that the label and block-level help text takes on the correct color of the group too, so you have no need of adding colors or styles to these separately to the form control group. Remember that the form-group sections can also use everything else we’ve mentioned so far to disable, shade, and resize form elements as required on a grouped basis. 

The last thing to mention for validation groups is that you can also provide optional feedback icons directly in the form controls in order to help with the state. 

You do this by providing a span element immediately after the input element with which it should be used. This span element has the usual icon classes applied to it (which we’ll see in the next chapter), along with a class of form-control-feedback. This must be put after the input control, and before any other markup in the input group, due to the way the control is repositioned to make it appear in the control. Once you add the span, you also need to add a class of has-feedback in the form group class list alongside the other has-xxxxx classes used to show the validation state. 

If we expand the previous code sample to take this in to account and add feedback icons, this is what it should look like: 

Once we re-render with these changes, you should see the following: 

Label for Form group that has success warning error including feedback icons

This tutorial represents a chapter from Bootstrap 3 Succinctly, a free eBook from the team at Syncfusion.