Using CSS to Customize Controls by Subtraction


Brazos UI controls are designed to look great right "out of the box", with most controls having a variety of configuration options to further modify the look and functionality. For example, Responsive Columns can be easily configured to display as ribbons or HTML headings to compliment the organization provided by Section controls. Even so, most designers will want to tweak the look and feel of controls to not only meet branding standards but to also meet the unique needs of a given solution.

Remove to Improve

Available configuration options offer easy options to alter the look and action of controls. Beyond these basic alterations, further customizing controls to fit your design needs is most often considered from the perspective of addition. However, a powerful method for customizing controls relies on subtraction. In more complicated scenarios, adding to a control may require an update to the Brazos UI Toolkit itself but removing nearly any visual feature (which is often enough to also remove associated functionality) of a stock Brazos UI control is as easy as applying one of two CSS options to the right selectors. 

First Things First

As always, we recommend you reach out to us when there is something that you are trying to accomplish with the Brazos UI toolkit. We can help you achieve what you need within the context of the current toolkit options, submit feature or bug reports to improve the toolkit directly, or walk you through workaround possibilities. Additionally, getting an extra set of eyes on your big picture can help identify potential pitfalls or even alternative approaches to your problem. Further, each help request around a given issue is essentially a "vote" for including that feature in the toolkit. While it may not be something we initially pursue, frequent interest in a particular feature improves the likelihood of its fully-supported inclusion into the Brazos UI toolkit directly.

One of the great strengths of the coach designer is that the majority control over the layout of a displayed page is managed by the templates, controls, and their associated CSS and JavaScript libraries. This lets a designer focus on the minor tweaks to layout and design without needing to worry about the big picture. For custom removal of a control's parts that aren't covered by existing configuration options, we need only utilize some very simple CSS. The two CSS attributes for removing components from a control are:

  • visibility: hidden;
  • display: none;

While the names of these options sound like they should have similar effects, the impact on the layout of a page is significant.

Option 1: Invisible Elements

Visually removing an element from a Coach can be done simply with the 'visibility: hidden;' attribute. This style attribute essentially makes the associated element invisible. It still takes up space in the layout of the Coach, but it isn't displayed nor can it be interacted with by the user.

The following image is taken from the Brazos UI Examples Application (sized to display as a single column):

If we target the "Controls" Section with the correct CSS selectors, we can apply the 'visibility: hidden;' attribute, producing the following result:

The noteworthy aspects of this change are: 

  • The space previously reserved for the "Controls" Section still exists. The remaining Sections are no closer to the introductory text block than they were previously.
  • The Section-specific visual style has also been suppressed. The original white background has been removed so the Buttons and demo text now appear to be part of the template's space rather than separated out into visual space of the Section.
  • The functionality of collapsing the "Controls" Section is no longer accessible. Hiding the control also hides its user interactivity; this section can't be tabbed to nor clicked on by the mouse.

Option 2: Removed Elements

The 'display: none;' CSS attribute is very similar to option 1 but results in the removal of the element from the layout.

Using the same example as above, when we apply the 'display: none;' attribute we see the following:

Noteworthy changes with this option:

  • As noted in the red text added to the screenshot, the "Controls" Section is missing from the layout. Space is not reserved, so the "Charts" Section now sits immediately below the introductory text block.
  • None of the nested child elements are displayed. The Buttons and text that were nested under "Controls" are also removed with this attribute.
  • As with option 1, functionality is also suppressed. The Section (and in this case any child element such as the buttons) cannot be interacted with.

Which Option to Pick?

The choice between 'visibility: hidden;' and 'display: none;' depends largely on visual layout considerations since either option will prevent user interactions. For most uses, complete removal of the element with 'display: none;' will be beneficial because it removes the element from the layout, so no further CSS tweaks will be needed. However, there are cases where the layout flow of the the page or control can be negatively impacted by the complete removal of an element. Likewise, removal might suppress desired nested child elements as well. In those cases, hiding the display with the 'visibility: hidden;' option is the better choice.


These examples are based on real customer requests.

Modal: Remove Dismiss Button and Only Use Normal Buttons

Use case 

The Modal has three configuration options related to how it can be closed:


The combination of options depicted above will restrict the closing of the modal to a click of the dismiss 'X' in the corner or by clicking the Done button. 

The Modal also has four configuration options related to boundary options:


The Modal can only generate a single boundary event, so the various combination of Boundary Event configuration options allow you to take different actions based on how the Modal was actually interacted with.

The design case that can't be directly met through the above two options is this: "As a designer, I want to force a user to select among three or more options in a Modal."

If a designer wants to force a valid selection, the dismiss button would allow users to circumvent that. Additionally, the number of events that can be fired from built-in buttons in the footer of a Modal is limited to two: The Done button and the Cancel Button. While there are configuration options that allow you to rename those two buttons however you like, additional buttons in the Modal (buttons in Modals can fire boundary events as normal) can't be directly placed in the footer in line with the Done and Cancel button.

Removing Modal components can achieve the desired outcome. First, by removing the dismiss button, users will not be able to close the modal. Second, by removing the footer of the Modal, a set of Buttons can be arranged in their place to handle any number of boundary events.



Applying the visibility or display CSS rule first requires identifying the correct elements, classes, and/or IDs, which can be done fairly easily using the developer tools of any modern browser. In the example below, we can see that the dismiss button in the upper right-hand corner of the Modal is a <button> with the 'close' class.


We can also use the developer tools to test which CSS option fit our needs. In this case, both 'visibility: hidden' and 'display: none' give the same result:


The same is not, however, true of the footer of the Modal.

'visibility: hidden;'




In this case, the 'display: none' option is tidier because it doesn't leave empty white space at the bottom of the modal. For simplicity, we can style the Modal using 'display: none' for both of the targeted elements:

/* Hide the dismiss "x" and remove the entire footer of modals */

.modal-header button.close {
display: none;

.modal-footer {
display: none;

This gives us the following result:


Note, however, that this solution is currently incomplete. Without any Buttons added to the table and boundary events to close the modal programmatically, this Modal can't be closed! Therefore, when removing elements from a control, you do need to be aware of changes that could break other functionality. 

Table: Remove Pagination Feedback for Static Tables

Use case

The Table control provides pagination feedback for users indicating which records are currently displayed to the user, the total number of records available, and a set of pagination controls:


When pagination is in use and there are a lot of records or a user or the system can change the number of records, this feedback is necessary to ensure that a user can always access the entirety of the data set. However, the visual appearance of a table can be streamlined when the table is being used to display a small, known, specific number of static records.

For example, if the table is being used in a read-only mode to display to the user 5 or fewer records, then the pagination feedback ("Showing 1 to 5 of 5 records) is not going to change and the first/previous/page/next/last control set will always be disabled. In that case, removing the feedback and pagination controls would be an acceptable change.



Hiding the record feedback and pagination controls can be easily done using the 'display:none;' attribute:

/* Hide record feedback */

.pull-left .dataTables_info { display: none; } /* Hide pagination controls */ .pull-right .data-page.first, .pull-right .data-page.previous, .pull-right, .pull-right, .pull-right .data-page.last { display:none; }

Which gives the following result:


As this CSS removes pagination controls, you do need to be very careful in its application. If you remove pagination controls from a table whose record count can change during use, you can end up in a situation where records are unable to be seen. Likewise, the record count feedback is helpful when filtering results (via Global Search or custom filtering) and it wouldn't be recommended to hide it under those conditions.

Other Considerations

  • Look for breaking conditions. Removing visual components from a Coach also removes the associated functionality of whatever it is you're hiding. As cautioned in the two use cases outlined above, you may unknowingly create a control that no longer functions as expected or even results in data loss (or at least obfuscation).
  • Keep it tidy. Make sure your CSS is organized both at the level of the code itself, but also in terms of how and where you apply it to your Coaches. Our recommendation in the latter case is to keep your customizations in a Coach View that you always place in the same location. This allows you to easily identify if a coach has customizations applied and to find out what they are.
  • Hidden elements are still present in the DOM. This may not often be of concern, but also be aware that even when elements are not rendered visibly to users, they still exist. That means they can be seen using developer tools and JavaScript can still access and manipulate them. Do not use 'display:none;' or 'visibilty:hidden;' attributes as a method for protecting data!
  • Specificity of CSS selectors. When applying CSS to a coach, you need to consider if the change you are implementing should apply to every control on the page or just a select few. This article on the Help Center covers how to use custom classes to narrowly target specific controls in the coach. Using the above example of the Table, if you had editable and read-only tables in the same coach, you would need to restrict the subtractive CSS. You could, therefore, add 'no-feedback' and 'no-page-nav' classes to the shorter, read-only, static Table controls and update the associated CSS to be:
    /* Hide record feedback of specific Tables */
    .no-feedback .pull-left .dataTables_info {
    	display: none;
    /* Hide pagination controls of specific Tables */
    .no-page-nav .pull-right .data-page.first,
    .no-page-nav .pull-right .data-page.previous,
    .no-page-nav .pull-right,
    .no-page-nav .pull-right,
    .no-page-nav .pull-right .data-page.last {

Further reading on using CSS styling with Brazos UI controls:


Have more questions? Submit a request


Powered by Zendesk