• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

View
 

jQuery UI CSS Framework

Page history last edited by ajpiano 14 years, 3 months ago

jQuery UI 1.7 and higher are built around a themable CSS framework with semantic naming conventions.

 

The new CSS framework is built to support not only jQuery UI's own plugins, but also custom plugin development. The framework itself is static with comment tokens which can be manipulated by ThemeRoller to generate a customized look and feel. Framework adoption will promote shared markup conventions and ease of code integration across the plugin community at large.

 

The following classes are split between ui.core.css and ui.theme.css, depending on whether styles are fixed and structural, or themeable (colors, fonts, backgrounds, etc) respectively.

 

jQuery UI CSS Class Framework Documentation:

 

Layout helpers

 

  • .ui-helper-hidden: Applies display: none to elements.
  • .ui-helper-hidden-accessible: Applies accessible hiding to elements (via abs positioning off the page)
  • .ui-helper-reset:  A basic style reset for UI elements. Resets things such as padding, margins, text-decoration, list-style, etc.

  • .ui-helper-clearfix: Applies float wrapping properties to parent elements
  • .ui-helper-zfix: Applies iframe "fix" css to iframe elements when needed in overlays.

 

Component containers

 

  • .ui-widget: Class to be applied on outer container of all widgets. Applies font family and font size to widget. Also applies same family and 1em font size to child form elements specifically, to combat inheritance issues in Win browsers.
  • .ui-widget-header: Class to be applied to header containers. Applies header container styles to an element and its child text, links, and icons.
  • .ui-widget-content: Class to be applied to content containers. Applies content container styles to an element and its child text, links, and icons. (can be applied to parent or sibling of header)

 

Interaction states

 

  • .ui-state-default: Class to be applied to clickable button-like elements. Applies "clickable default" container styles to an element and its child text, links, and icons.
  • .ui-state-hover: Class to be applied on mouseover to clickable button-like elements. Applies "clickable hover" container styles to an element and its child text, links, and icons.
  • .ui-state-active: Class to be applied on mousedown to clickable button-like elements. Applies "clickable active" container styles to an element and its child text, links, and icons.

 

Interaction Cues

 

  • .ui-state-highlight: Class to be applied to highlighted or selected elements. Applies "highlight" container styles to an element and its child text, links, and icons.
  • .ui-state-error: Class to be applied to error messaging container elements. Applies "error" container styles to an element and its child text, links, and icons.
  • .ui-state-error-text: An additional class that applies just the error text color without background. Can be used on form labels for instance. Also applies error icon color to child icons.
  • .ui-state-disabled: Applies a dimmed opacity to disabled UI elements. Meant to be added in addition to an already-styled element.
  • .ui-priority-primary: Class to be applied to a priority-1 button in situations where button hierarchy is needed. Applies bold text.
  • .ui-priority-secondary: Class to be applied to a priority-2 button in situations where button hierarchy is needed. Applies normal weight text and slight transparency to element.

 

Icons

 

States and images

  • .ui-icon: Base class to be applied to an icon element. Sets dimensions to 16px square block, hides inner text, sets background image to "content" state sprite image. Note: .ui-icon class will be given a different sprite background image depending on its parent container. For example, a ui-icon element within a ui-state-default container will get colored according to the ui-state-default's icon color.

 

Icon types

 

 

Misc visuals

 

Corner Radius helpers:

  • .ui-corner-tl: Applies corner-radius to top left corner of element.
  • .ui-corner-tr: Applies corner-radius to top right corner of element.
  • .ui-corner-bl: Applies corner-radius to bottom left corner of element.
  • .ui-corner-br: Applies corner-radius to bottom right corner of element.
  • .ui-corner-top: Applies corner-radius to both top corners of element.
  • .ui-corner-bottom: Applies corner-radius to both bottom corners of element.
  • .ui-corner-right: Applies corner-radius to both right corners of element.
  • .ui-corner-left: Applies corner-radius to both left corners of element.
  • .ui-corner-all: Applies corner-radius to all 4 corners of element.

 

Overlay & Shadow

  • .ui-widget-overlay: Applies 100% wxh dimensions to an overlay screen, along with background color/texture, and screen opacity.
  • .ui-widget-shadow: Class to be applied to overlay widget shadow elements. Applies background color/texture, custom corner radius, opacity, top/left offsets and shadow "thickness". Thickness is applied via padding to all sides of a shadow that is set to match the dimensions of the overlay element. Offsets are applied via top and left margins (can be positive or negative).

 

 

New framework levers being considered for future releases

A few considerations: there are always lots of new things we could add to the framework to accomodate new widget types, but we need to carefully grow this framework so we strike a good balance between the power/breadth/richness of these levers and the ThemeRoller's UI complexity (and file size). For example, each new lever adds around 6-7kb because the bg texture image is 1k, icon sprite is 5k and then there are the style rules in the CSS. So adding the 3 levers for the forms will add about 20kb to each theme which isn't huge, but it's something to consider.

 

The TR's UI is designed to scale by just adding spindown sections but we already have 11 and adding more will make this a pretty intimidating form. One easy thing we can do is add labels to group logical sections together and make it easier to visually scan but there is a point where too many levers will make it too time-consuming to use so we want to make sure we really know that a new lever is going to be widely used across widgets.

 

Here is the list of new levers that have been requested and are under consideration:

 

  • Form states: There have been a bunch of requests for styling form elements with ThemeRoller. This would allow for a complete set of custom styled textareas, inputs, dropdowns, custom radio and checkboxes, spinners, etc. To do this right, it would require a full set of interaction state levers to do properly (default, hover, active) because I think you'd want to be able to style your inputs, dropdowns, custom radio and checkboxes independently from the normal clickable elements.
    • ui-form-default :: normal appearance of a form element
    • ui-form-hover :: appearance on mouse over
    • ui-form-active :: appearance in the selected state (checked radiobutton, checkbox, etc.)
  • pressed/down state
    • ui-state-down :: new 4th state for when you mouse down on a clickable element to give additional feedback that it's been clicked. also good for touchscreen based UIs
  • toolbar
    • ui-widget-toolbar :: for basic toolbars, grid header/footer, dialog button bar etc.. this is useful because there are times where you need a bar that isn't a header, button or content area.
  • secondary content area
    • ui-widget-content-secondary :: for table striping or differentiation in menu panels, etc.

       

Comments (22)

Jan said

at 4:10 pm on Jun 1, 2009

I have a request for additional icon types too: double carat (we use them e.g. for fieldset collapse)
.ui-icon-carat-2-n (two carats stacked close to each other, pointing north)
.ui-icon-carat-2-e
.ui-icon-carat-2-w
.ui-icon-carat-2-s

Jan said

at 12:57 pm on Jun 2, 2009

I have proposal for 'ui-state-pressed'
Class to be applied on mousedown and removed on mouseup to all clickable button-like elements
UI TheameRoller would add forth section "clickable pressed"

read more:
http://groups.google.com/group/jquery-ui/browse_thread/thread/eb8b56189628966c

Daniel Probst said

at 9:47 am on Jul 11, 2009

Hi Todd. Yea, thats what i meant. I understand that the colours are tied to states and functions, but for the sake of creating an entire User Interface, a colour scheme is pretty important. I found myself using only shades of gray to style elements that aren't affected by the css framework - so that they will match each theme. It would be useful if every theme had a set of colours maybe 3 to 5 (kuler-like or what ever) which can be applied to elements that aren't 'directly supported' by the framework. One can't style an entire UI just with widgets, dialogs and tabs. As an example, i'd like to style a table according to the theme specified (like this one http://redoxite.ch/UserData/Image/page_overview.png) - if i now wanted to add zebra-stripes to the table it would be great to use a framework class like ui-style-color-a. The theme designer would have to add some standard values like colors (or fonts or whatever) to the theme. In short, style information that isn't bound to states or functions but to the style of the theme.

Jason Iles said

at 3:26 pm on Jul 13, 2009

I agree that some basic formatting css would be beneficial, but would be best as an optional css file so it doesn't add to the existing file size. Just provide some basic options so you would have access to colors, padding, borders, backgrounds, etc without all the additional options each class gives you.

Jason Iles said

at 3:34 pm on Jul 13, 2009

When adding two controls inside each other such as tabs the font-size keeps getting larger because of the 1.1em in the ui-widget class. I know changing it to 1.0 will fix it, but since it's the themeroller default is this expected behavior? Would there be benefit to adding .ui-widget .ui-widget { font-size : 100%; } to the css so this doesn't happen?

Jason Iles said

at 6:46 pm on Jul 16, 2009

Todd Parker said

at 10:02 pm on Aug 23, 2009

Since all widgets are coded with relative units, this is the expected behavior. It's pretty easy to workaround and you get the beenfit of each widget being completely flexible so it will work with a wide range of font sizes and fonts. Using pixels would be more consistent (and easier for us to code) but relative units really force us to build our widgets in a very bullet-proof way.

Jeremy Martin said

at 10:31 pm on Sep 2, 2009

Would there be any major drawbacks to using 1em, rather than 1.1em then?

Richard D. Worth said

at 5:26 am on Sep 3, 2009

It would make the base font size 10px instead of 11px, assuming you have font-size: 62.5% on the body.

Jeremy Martin said

at 12:23 pm on Sep 3, 2009

Ahh - I see. So for the sake of maintaining the current widget font size, how about adding something along the lines of what @Jason suggested above?

.ui-widget { font-size : 1.1em; }
.ui-widget .ui-widget { font-size : 1em; }

I think the primary annoyance isn't the default font size of the widgets... it's that they become incrementally larger.

Kevin Dalman said

at 10:13 pm on Sep 3, 2009

There is no reason why a 'content container' should display a larger font than the user has *chosen* for page content (body). It's OK for headers/titles to be larger, but not primary content like a tab-body or accordion-body. It's these kinds of containers that are likely to have nested widgets. So strictly from a design standpoint, widgets should 'default' to 1em so the user's CSS is in control - not the widget's. If the users wants the content of a widget larger, he can customize the CSS himself.

But the .ui-widget .ui-widget { font-size : 100%; } rule is still useful in case the users does customize a widget's font-size. This rule has higher specificity than a single classname, but it's an issue as long as widget font-sizes are *always* declared using at lease 2 selectors, like ".ui-accordion .ui-accordion-header a".

Ca-Phun Ung said

at 9:36 am on Sep 9, 2009

Yes there is, a fix for nested widgets was added six months ago, see: http://dev.jqueryui.com/changeset/2372

It's part of the 1.8a1 release.

Also just to answer the other questions, if you want your widget base to use 1em that's an option that could be set via the ThemeRoller tool when creating your theme.

Jan said

at 2:32 pm on Jul 29, 2009

Here: http://uicoded.com/test-suite/js/jquery.ui/1.7.2b/jquery.ui-1.7.2b-test.html ,
are 4 new double carat icons, links to download ThemeRoller images and mask - if someone is interested.
Also there is a test with 'ui-state-down' which is useful for all clickable elms.

Todd Parker said

at 10:07 pm on Aug 23, 2009

Thanks, we have these files and will add them to the sprite in a future iteration.

umpirsky said

at 2:05 am on Dec 17, 2009

When can we expect ui-form-* classes, I can't wait. This is required for building themable sites.

Duncan Kenzie said

at 12:32 pm on Jan 8, 2010

I would like to request a new (simple) selector: .ui-right {text-align: right;} for right-adjusting content in table cells, for example, when showing lists of data.

Scott González said

at 10:55 pm on Jan 11, 2010

high contrast mode support:

1. Ensure that all widgets and Theme Roller have high contrast mode-friendly styles. In short, we want widgets to provide textual alternatives for critical background images (such as close boxes). For an example, you can see what we've done with Fluid Skinning System themes here:

http://fluidproject.org/releases/1.1.2/demos/fss/themes/demo.html

2. Add some code to jQuery UI core that detects high contrast mode and enables the high-contrast styling for a given theme. I think detecting high contrast mode was accomplished in Dojo by inserting an element with two main qualities and testing its computed styles:
a. Two differently coloured borders. If they end up both the same, we're in high contrast mode
b. Background images. If the image isn't there, we're also in high contrast mode.

http://www.dojotoolkit.org/book/export/html/1460

Scott González said

at 7:05 pm on Jan 13, 2010

Andrew Dupont said

at 12:41 am on Jun 27, 2010

I'm commenting here in order to record for posterity the feedback I gave on the jQuery forum regarding .ui-state-active. [1] Right now it's being used for both "down" state and "active" state on buttons, which makes it impossible to treat the two states differently in any theme. I feel like this is a serious restriction on the usefulness of the CSS framework.

I hope this can be addressed for an upcoming release.

[1] http://forum.jquery.com/topic/buttons-and-ui-state-active

John D'Orazio said

at 7:32 pm on Jun 29, 2011

I would like to suggest a new framework icon, I'm using a ui-layout for working on a database interface, and I'm using the ui-icons to style the navigation buttons. The last button is the "new record" button. I think the icon that most people recognize as the "new record" button is something like the "right triangle" with an asterisk. Something like this: http://www.cultures.org/New%20Record%20button.jpg . This is what MSAccess uses, and I think it's visually recognizable.
If I simply use the "ui-icon-triangle-1-e" class and then use a text asterisk next to it, it messes up the lining up of the buttons, because none of the other buttons have text in them. It would be useful to have a dedicated icon.

johnslegers said

at 5:35 pm on Jan 19, 2012

A pre-release of jQuery Bootstrap has been published at http://jslegers.github.com/jquery-bootstrap/ . This new framework combines the layout of Twitter with the semantics of jQuery into a CSS framework that's a jQuery UI theme as well.

Any feedback would be appreciated!

Romans Malinovskis said

at 7:18 pm on Apr 7, 2014

Agile Toolkit CSS is a new CSS3 framework which also includes full native support for jQuery UI css framework but is fully rewritten in LESS. It's currently in development and is due to be released soon.

http://css.agiletoolkit.org/

Scroll down for jQuery UI widgets.

You don't have permission to comment on this page.