Overriding jQuery UI Layout and Theme Styles - J Query

The customized (or standard gallery) theme you created in Theme Roller, downloaded, and referenced in your project is a partial match to your target design but doesn’t match exactly. You need to modify the styles, but at the same time you want to ensure that edits to these styles don’t make it difficult for you to upgrade to newer versions of jQuery UI scripts and CSS.


Create custom override styles, scoped to the components that need additional non- ThemeRoller styling, and structure them so that they don’t conflict with or overwrite any standard jQuery UI CSS files.
Each jQuery UI widget is styled to work out of the box when you download the jQuery UI scripts and a theme stylesheet; no changes to the CSS are necessary to incorporate the widget or styles into your site. But it’s possible that the styling may not exactly match the design conventions established in your project. For example, you may want to reduce the padding or use a custom background image for a header.
Let’s pick up where we left off in the previous recipe and continue working on our travel reservations application. We created, downloaded, and applied the theme stylesheet correctly; however, the default jQuery UI styles for the tabs and date pickers don’t quite match the design for our project, as shown in Figure :(Our design interface with customized ThemeRoller theme applied (A) and the target design provided by the designer (B)).

Our design interface with customized ThemeRoller theme applied (A) and the target design provided by the designer (B)

Figure : (Our design interface with customized ThemeRoller theme applied (A) and the target design provided by the designer (B))

Step 1. Review the widget markup and styles for jQuery UI plugins

First, we’ll review how classes are assigned in the jQuery UI widget markup to better understand how they’re applied (and can therefore be overridden).
Let’s start with the tabs markup. When the jQuery UI tabs widget is initialized on the page, the plugin script assigns several classes to the widget markup, as shown next.
(Please note that this is the markup that is transformed or inserted by the plugin script; it’s the finished product, not the markup served to the page before JavaScript is run.)
Pay particular attention to the classes that begin with the prefix ui-tabs— the Widget specific classes for the tabs—highlighted in bold:

They also identify a widget’s individual components—like the header or content panels—and as such they’re ideal for writing override rules to adjust layout features or
add customizations like drawn icons. The Widget classes for the tabs mark the following components:

Outer container that wraps around the tab navigation and content.
Container for the navigation options. The tab list items and links are styled using
descendant selectors, i.e., ui-tabs-nav li.
Selected tab “on” state, which is dynamically by the script. This class is assigned to only one tab at a time.
Content areas that map to tabs.
Default state for the content panels. They’re hidden until selectively shown by the user.

To see the style rules associated with these classes, open the theme stylesheet and find (Ctrl/Command-F) or scroll to the block that begins with ui-tabs. Notice that the rules only apply to layout characteristics, like positioning, padding, or border width, and are absent any theme styles, like background or border colors:

Step 2. Create an override stylesheet

We’ve found the best way to safely fine-tune a widget’s appearance is to write new style rules that override the jQuery UI theme styles and append these “override rules” in a separate stylesheet. Override rules are written against jQuery UI CSS class names and as such must appear in the source order after your theme stylesheet; since styles are read in order, the last style rule always takes precedence.
The jQuery UI library is constantly evolving to include more features with better stream lined code. By maintaining override styles in a separate file, you can customize the widget styles as much or as little as you’d like and still preserve the ability to easily upgrade the jQuery UI files as needed and simply overwrite your existing theme style sheet knowing that your override rules remain intact. Override rules can be listed in a dedicated stylesheet for overriding default theme styles, or if you prefer to limit the
number of files linked to your pages (and therefore limit the number of requests to the server), append override rules to the master stylesheet for your entire project.
As we work through this recipe, we’ll append override styles to the master stylesheet for our project, travel.css, just below the block of custom styles we developed for our application:

And we’ll reference travel.css after the theme stylesheet in our page:

Step 3. Edit the style rules in your override stylesheet

Now that we’ve reviewed how the Widget classes are named and applied, and also how to reference override styles in our project, let’s update our travel reservations application with our customized tabs navigation bar and datepicker header style. We’ll tacklethe tabs first.
The design we created for the tabs is specific to the travel reservations application, and we don’t necessarily want the same customizations, like the icons or font size, to apply to every tab widget in our entire application. To ensure that these styles only apply to the travel application, we’ll scope the override rules to our travel application’s unique ID.
Each new rule will start with the Widget-specific class assigned to the component we want to change; for example, when changing styles for the tab’s navigation bar, we’ll write a rule against the .ui-tabs-nav class:

And scope it to our travel application by prepending its ID, travel:

After applying the theme stylesheet, our tab’s navigation panel looks like Figure :(Our tabs with ThemeRoller theme applied before overrides):

Our tabs with ThemeRoller theme applied before overrides

Figure :(Our tabs with ThemeRoller theme applied before overrides)

the individual tabs are small and surrounded by a border that’s separated from the outermost container by a few pixels of padding.
However, our design (Figure :(Our target tab design))

Our target tab design

Figure : (Our target tab design)

calls for large tabs with icons and without a background— they appear to sit above the tab content.
To override the default tab styles, we’ll make a handful of style changes:

  1. First we’ll remove the outermost border. The entire tabs widget is surrounded bya 1-pixel border and has a few pixels of padding. For the tabs to appear above the content panels, we’ll remove both:
  2. Next, we’ll flatten the bottom of the tab navigation bar (set the bottom-corner radius to zero) and remove its top and side borders. We’ll also remove any extra padding so that the tabs appear flush with the left side of the widget, and we’ll thicken the border width to 3 pixels to match our design:
  3. The tabs are a little too close together, so let’s add some right margin:
  4. And update the selected tab, .ui-tabs-selected, so that it appears connected to the tab content area. We’ll increase the border width to 3 pixels so that it matches the design, and we’ll then fix the gap between the tab and content. The amount of space between the tab and its content panel is directly related to the tab navigation bar’s border thickness, so we can close the gap by applying a negative 3-pixel bottom margin:
  5. Next, we’ll apply our custom icons. Because each icon is unique to its tab, we can apply each icon as a background image using the unique ID of each tab. (Technically these aren’t override styles, but we’ll need to reference these rules when we style the selected tab’s icon next.)
  6. The selected tab uses a slightly different icon that sits on a white, not gray, background.For each tab, we’ll add a rule that keys off the Widget-specific class for the selected state, .ui-tabs-selected:
  7. Our tabs should also have more padding and a larger font size:
  8. To finish up the tabs, we’ll adjust the border around the content panel so that it matches the 3-pixel border width we set on the selected tab:

Now that our tabs match the design, let’s update the date picker’s header. As illustrated in Figure : (Our datepicker with ThemeRoller theme applied (A) and our target design (B)),

Our datepicker with ThemeRoller theme applied (A) and our target design (B)

Figure : (Our datepicker with ThemeRoller theme applied (A) and our target design (B))

with a few adjustments we can make the datepicker’s header component— the bar above the calendar that contains navigation arrows and month/year feedback—appear above, not contained within, the datepicker.
Like the tabs, when the datepicker plugin is initialized on the page, the script writes widget markup to the page that contains jQuery UI Widget-specific and Frame work classes to set its structural and the med appearance. In an abridged version of the datepicker markup, you can see that Widget-specific classes conform to the naming convention and begin with ui-datepicker, and identify each component:

The datepicker Widget classes are assigned the following default style rules:

This is just a subset of the datepicker’s style rules; to view all, in the theme stylesheet find the style block that starts with ui-datepicker.
Returning to our travel application, let’s write a few override rules to make the datepicker’s header appear like our design:

  1. First we’ll remove the padding that separates the header from the datepicker’s outer container:
  2. Like the tab navigation bar, we want to flatten the bottom and remove its top and side borders:
  3. Finally, we’ll remove the border and background image from the next and previous navigation arrows on hover:

With the override styles applied, our working travel application now accurately matches the final design (Figure (Our final design, with both standard ThemeRoller and override styles applied)).

Our final design, with both standard ThemeRoller and override styles applied

Figure : (Our final design, with both standard ThemeRoller and override styles applied)


Consider whether you’d like to apply override rules to all widgets in your project or whether you only want to override theme styles for a subset of widgets. If there’s even a small chance that you may want to present the widget in different ways, apply override styles by scoping them to a container element’s class or ID so that you don’t alter the default formatting of the widget.
Here are some editing tips/reminders:

  • If you want to remove the bottom border on a widget header, use border-bottomwidth: 0; instead of border-bottom:0;. The former will retain the border style and color in the event you want it back.

  • For variation in stacked elements that have the same class, you might disable just the background image in one, letting the difference in background color show through.

  • If you need to change the color of a particular portion of a widget, design the theme to accommodate that change instead of hard-coding a color into your stylesheet.

  • If you need to remove a border but would like to keep it there for structural layout, you can set it to transparent. To do this in an IE-safe way, set the border style to dashed.

  • Use em units whenever possible for structural dimensions such as padding and margins, and more importantly for font sizes. Write styles assuming 1em is the standard widget size, and try not to dip below .8em to keep text legible.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

J Query Topics