jQuery UI CSS Framework

Page history last edited by Todd Parker 5 mos ago

jQuery UI 1.6rc6/1.7 is built upon a brand new, themable CSS framework.

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 (Show all 41)

Good idea. We'll add these pin icons to the sprite.

@kevin: I've been looking around on the web for examples of the pin up/down icons you requested and I'm not finding many examples of this in use. I remember seeing the pin metaphor a long time ago on an old Microsoft app (Encarta?) to "pin" open a panel that auto-hid on mouse out. Is this the type of use you had in mind or is this more of a pin in a map kind of interaction? Seems like it might not be needed until there is an application that calls for it.

@Todd: I requested pin graphics because the Layout Manager widget I created can automatically synchronize 'pin buttons' with the state of the layout. You can see example of this - on the toolbar and in the pane-headers - in this demo:

http://layout.jquery-dev.net/demos/complex.html

I'm currently reformatting the widget to conform to the UI API. After that I'll be creating some layout 'themes'. Since the icon sprite has *everything else* I would need, I thought if would be nice if no custom graphics were needed. I'm also hoping to get ThemeRoller support for Layout soon, so I am trying to use *only* the CSS framework.

I can provide a set of 2-color pin graphics in 16px format, if you want them.

@kevin: The framework icons have been updated and now include two pin icons (ui-icon-pin-w and ui-icon-pin-s).
You can find them documented here as well: http://docs.jquery.com/UI/Theming/API

@Todd: That's great Todd - thanks. Once UI 1.6 is final, I'll upate one of my demos to use all the new icons.

@Kevin - There are also some nice gripper and arrow icons that you can use for the re-sizable panels in the icon sprite. I tried to make sure we had the bits you'd need for a layout panel system when creating the set. Missed the pins tho.

Hi all, I have an icon suggestion: .ui-icon-map

something wrong with images, when i try edit in photoshop, im getting it without transparency, how did u seved it, which format of PNG there?

The icons and background images are saved as PNG8 which Photoshop should be able to open. Sometimes, PS can display masked (transparent) parts of a PNG as black for some odd reason. This is just Photoshop's bad PNG support.

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

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

On separate form element states in response to: 'because I think you'd want to be able to style your inputs, dropdowns, custom radio and checkboxes independently from the normal clickable elements.'

I think, it would be better to set up a single class for a form element (e.g 'ui-form-element') and style an element with a combination of this one and the states defined before. This proposes more consistency on states of elements (as being active, disabled or focused). More specific states may be added later.

Eventually found a better name for an empty icon class: .ui-icon-none

my vote for ui-icon-none (even if it may sounds weird to define something that's not there)
Plus i propose two additional states like ui-state-highlight:
- ui-state-success
- ui-state-info and/or ui-state-notice.
This will be in help when displaying application messages such as form submission / validation.
regarding icons it may be nice to also have some of them representing some basics in text editing i will personnaly liked to use such icons for my RichTextEditor plugin to keep theme consitency.

We designed ui-state-highlight and ui-state-error for these form submission scenarios. For example, if there is a validation error, use error. If te form was submitted successfully, you could drop in a div with the highlight class, then maybe fade away after a timeout using a class transition. Highlight state the check icon would make a good success message, info message or anything that needs attention but isn't an error.

I'm already using them in such manner. I'm ok that ui-state-highlight may serve for info/notice but i still think that a ui-state-success would be meaningfull and a good complementary to ui-state-error. Also it would be nice to have a green color as opposite of error wich is red as users are used to see green/red message for success/error.

I second this request. User messaging systems commonly contain 3 levels of "urgency" - specifically error, warning, and success/confirmation. An equivalent ui-state would be helpful when implementing jQuery UI based notifications.

My vote also for an ui-widget-content-secondary or stuff like that.
Would be nice too to have an ui-class to add default border style to elements perhaps in a way much like for corners this to allow ui-theme user to get consistent borders for elements.

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.

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.

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?

Here's a demo: http://daersystems.com/jquery/widgetfont/

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.

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

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

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.

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".

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.

When are the W3C's standards for 'border-radius' [http://www.w3.org/TR/css3-background/] going to be implemented? They have specifications for everything being used in the current ui css. Also it states the url in background-image should be wrapped in single or double quotes. (if this should go somewhere else please let me know)

It really comes down to browser support and IE isn't going to implement this until 9 or later. I'm not sure that they've committed to adding this yet but maybe others have some better info than me. It supported by Webkit, Opera and Mozilla so we're getting close.

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.

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

Has there been any consideration of adding class names that would equate with poorly supported pseudo selectors? For example:

.ui-psuedo-first-child
.ui-psuedo-last-child
.ui-psuedo-even
.ui-psuedo-odd (perhaps more practical than nth-child)

These could allow more advanced theming of plugins like tabs, accordion, and eventually the grid in legacy/non-standards browsers. The even/odd has already been hinted at with .ui-widget-content-secondary, but that may not be the most semantic way of denoting that (although I do like that proposal for other purposes)....

Are you thinking that you could call some sort of generic pseudo selector plugin to add these? Or are you just asking for the individual widgets to add these classes as an optional feature? Adding all these classes could be pretty heavy so you'd want to do it selectively and I'm wondering if it's worth the complexity. Do you have a prototype of this you could share?

I was thinking more along the lines of a convention, rather than a generic plugin. I agree that anything that parses through the DOM decorating elements would be far too heavy handed - but it would nice if, say, the accordion provided me a way to stripe the panes in IE6 (optionally, as you stated).

I respect the balance that needs to be maintained between robustness and keeping the library lightweight. In my personal experiences with jQuery UI, a feature like this would be worth the cost - but I don't have much of a feel for how the need is within the community at large. If I represent a minority here, I'd settle for a createPane event/callback... :p

Isn't accordion striping just one line of code to write on your own?

Yes - but I would contend that this is also true for other options provided by core ui components. I only suggest this on the possibility that it would be helpful as default behavior for the community at large (and additionally would allow the themeroller to integrate with this relatively common task). I would consider this a classic 80/20 question, rather than an issue of whether or not there are viable alternatives.

I've been thinking about this a bit, and on the several websites I've implemented Jquery ui, I'm wondering if having both the ui.all.css and the ui.base.css files are both redundant and confusing. Why not just include all of the base files inside of ui.all.css along with the theme file. Or just name the master file (if even needed) jquery.ui.css .... I find that I'm actually just @importing all of these files inside of my own css file anyways, every time. Are having two files really necessary? I might be missing something, so I figured I'd ask.

There are two distinct parts to a jQuery UI theme. The functional/layout css, and the look-and-feel/visual css. ui.base.css gives you the base css you need for all plugins to function but does no styling whatsoever. So if you only want the base, link to ui.base.css, which is everything minus ui.theme.css. And if you want the whole theme link to ui.all.css which is base plus ui.theme.css.

As far as using these files yourself, if you're doing development, no harm in @importing each file on its own, or just ui.base.css or just ui.all.css, which in turn will do a number of @imports. Once you get to a production scenario, where you want to minimize requests, you should have a single css file, called jquery-ui.css. This file is provided in each released and custom theme and contains everything that ui.all.css would @import but without any @imports.

Case in point: http://groups.google.com/group/jquery-en/browse_thread/thread/fe1ffef4542888b2

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

Anonymous Create an account or Log in

jQuery UI CSS Framework

jQuery UI CSS Class Framework Documentation:

Layout helpers

Component containers

Interaction states

Interaction Cues

Icons

Misc visuals

New framework levers being considered for future releases

jQuery UI CSS Framework

Page Tools

Insert links

Comments (Show all 41)

Todd Parker said

Todd Parker said

Kevin Dalman said

scottjehl said

Kevin Dalman said

Todd Parker said

Bohdan Ganicky said

Sasha said

Todd Parker said

Jan V said

Jan V said

sompylasar said

sompylasar said

Jonathan Gotti said

Todd Parker said

Jonathan Gotti said

Jeremy Martin said

Jonathan Gotti said

Daniel Probst said

Jason Iles said

Jason Iles said

Jason Iles said

Todd Parker said

Jeremy Martin said

Richard D. Worth said

Jeremy Martin said

Kevin Dalman said

Ca-Phun Ung said

trevnorris said

Todd Parker said

Jan V said

Todd Parker said

Jeremy Martin said

Todd Parker said

Jeremy Martin said

Scott González said

Jeremy Martin said

Jonas Flint said

Richard D. Worth said

Richard D. Worth said

Join this workspace

Navigator

SideBar

Recent Activity