CSS selectors used in Eclipse are identifiers that relate to widgets or other elements, for example, predefined pseudo classes. Non-standard properties are prefixed with either swt- or eclipse-.

You can use the swt-data-class attribute to query the class hierarchy of an object. For example, the following selector identifies all Shell elements from a JFace dialog.

The CSS attributes for SWT widgets that can be styled are listed in the CSS documentation of the Eclipse platform.

Model elements of your Eclipse application, for example, MPartStack or MPart, can be used as selectors for styling. The CSS selectors are based on the Java classes for the model elements. Some examples are given in the following table.

For example, you can hide the minimize and maximize buttons of an MPartStack via the following CSS rule.

Eclipse supports CSS pseudo classes, but these are disabled by default. You can enable them via the Java system property org.eclipse.e4.ui.css.dynamic=true.

The following table lists several of the available pseudo classes.

You can test the effect of this CSS with the following code.

See Pseudo classes in SWT for the project documentation.

You can assign a CSS ID or class to widgets in your source code and use them as selectors for styling. An identifier is supposed to be unique, while a class can be assigned to several elements.

The following example demonstrates how to set an identifier and a class on SWT widgets.

The setId and setClassname methods use the setData method on the widget. You can also use the SWT setData method directly, as demonstrated in the following example.

These IDs or classes can be addressed in the CSS file via the # or the . selector.

Another example is the assignment of an image to a label via CSS.

On the label, set the CSS ID or the class.

The org.eclipse.e4.ui.css.disabled key can be used to instruct the CSS engine to ignore certain widgets.

Colors can be defined in different ways. For example, the color white can be described as white, rgb(255,255,255) or #ffffff.

Color constants from SWT can be used, for example, SWT.COLOR_BLACK or SWT.COLOR_WIDGET_BACKGROUND.

Styling supports gradients for the background color of user interface widgets. Linear and radial gradients are supported. The definition of gradients is demonstrated in the following listing.

With the optional percentage, the color change happens at the defined percentage. The following picture shows the result of different settings.

Eclipse supports the import of existing stylesheets via the @import directive using the platform URI notation.

For example, the following stylesheet imports an existing dark theme of the org.vogella.ui.themes plug-in.

You can add additional styling to an existing theme. For example, if you defined additional settings for the default dark theme of the Eclipse IDE in a file called css/additional.css, you can register it with the following extension.

The swt-show-close property that older documentation suggests for this was removed from the CSS engine in Eclipse 2024-03 and is silently ignored today. Whether a part can be closed is a property of the application model, set the closeable flag of the MPart instead.

CSS can still hide the close button on the tabs that are not selected.

Under this extension, you can specify for which entries in the CSS style sheet the IElementProvider is responsible. The org.eclipse.e4.ui.css.core.elementProvider extension defines an IElementProvider that returns the widget’s adapter (ElementAdapter). IElementProvider returns an org.w3c.dom.Element.

In general, the returned org.w3c.dom.Element is an instance of an ElementAdapter. By the widget properties under the provider, you point to the class of the actual widget, like org.eclipse.swt.widgets.Control, for which the provider is responsible.

The SWTElementProvider, for instance, contains those ElementAdapter implementations that are shown in the type hierarchy screenshot and looks like this:

See https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/docs/CSS.md for more information.

In the org.eclipse.e4.ui.css.core.propertyHandler extension point, you define an adapter of type ElementAdapter for your widget that is used by the CSS engine. Here you specify an implementation of an ICSSPropertyHandler, where different property-names for the widget can be defined. This implementation is responsible for applying the CSS properties to the underlying widget.

You have to define three properties for a org.eclipse.e4.ui.css.core.propertyHandler.

Here you can see a sample of the org.eclipse.e4.ui.css.swt projects propertyHandler extension point:

These are the default ElementAdapter implementations for the adapter property in the screenshot above:

In the ICSSPropertyHandler implementation those property-names are read and applied to the actual widget.

The CSSPropertyBackgroundSWTHandler and its parent AbstractCSSPropertyBackgroundHandler are examples of such an implementation of the ICSSPropertyHandler. Here the background property is applied for certain widgets.

The AbstractCSSPropertyBackgroundHandler class delegates to the methods for the property-names. These are applied in the propertyHandler extension point to its subclasses like the CSSPropertyBackgroundSWTHandler.

The following listing is the applyCSSPropertyBackgroundColor method of the CSSPropertyBackgroundSWTHandler. It shows how the background-color property-name is applied for several widgets:

The CSS spy tool shows the available styling properties and the current style settings of selected elements. It is part of the Eclipse PDE (org.eclipse.pde.spy.css plug-in).

You open the CSS spy via the Shift+Alt+F5 shortcut.

The CSS Scratch Pad allows you to change CSS rules interactively. It is part of the same plug-in, and you open it via the Shift+Alt+F6 shortcut.

If you click the Apply button, the entered CSS is applied to your running application.

Create a new simple plug-in named com.vogella.eclipse.css.

Add the org.eclipse.e4.ui.css.swt.theme plug-in as a plug-in dependency to the manifest file of your new plug-in.

Create a folder named css in the root of your com.vogella.eclipse.css plug-in. Create the following css/fonts.css file. The default theme and the dark theme of a later exercise import it, so both use the same fonts and lay out the widgets identically.

Create the following css/default.css file. It imports the fonts via the platform URI of your plug-in.

In addition, create the following css/rainbow.css file.

Open the Extensions tab in the MANIFEST.MF editor.

Press the Add…​ button in the Extensions tab, select the org.eclipse.e4.ui.css.swt.theme extension point and press the Finish button.

Right-click on the org.eclipse.e4.ui.css.swt.theme extension and select the New  theme menu entry to create a theme. Create two themes.

The following screenshots show the extensions you should create.

When you add the first extension via the editor, PDE marks the plug-in as singleton (Bundle-SymbolicName: com.vogella.eclipse.css;singleton:=true in the MANIFEST.MF file). If you create the plugin.xml file by hand, add this directive yourself, as the extension registry ignores the extensions of a plug-in that is not a singleton.

The plugin.xml file should look similar to the following listing.

Ensure that all CSS files are included in your build via the build.properties file of your plug-in. This makes them available in the exported application.

The build.properties file should look similar to the following listing.

Configure the default theme via a property of your product extension.

For this, open the plugin.xml file in your com.vogella.tasks.ui plug-in and select the Extensions tab. Add the cssTheme property to your product and point to the com.vogella.eclipse.css.default theme.

To add a new property, right-click on the product and select New  property. Do not press the Add…​ button.

If present, remove an existing entry for applicationCSS. applicationCSS is an alternative way to define fixed styling for the application, but it is not used in this exercise.

The entry in the plugin.xml of com.vogella.tasks.ui should look similar to the following.

Add your com.vogella.eclipse.css plug-in to your feature. Afterward, start the application via the product configuration file.

Start your application and ensure that the application is styled according to the cssTheme property setting. Your application might look similar to the following (screenshot from Linux).

Try adjusting the colors and styling of your application to achieve a visually appealing design.

Ensure that the manifest file of com.vogella.tasks.ui has a plug-in or package dependency on the theme engine org.eclipse.e4.ui.css.swt.theme.

Create a new Java class that allows you to switch between the themes.

Define a new command with the com.vogella.tasks.ui.command.theme.switch ID and a handler in your application model for switching the style. Assign the above class to the handler.

Add a menu entry to the application model to use your handler for style switching.

Start the application and select your new menu entry. Afterwards, the styling of your application should use the rainbow theme.

Change your Manager class to apply one of your CSS files to the widgets in the login screen.

Start your application and ensure the splash screen is styled according to your settings.

Add the org.eclipse.e4.ui.css.core and the org.eclipse.e4.ui.css.swt plug-ins as a dependency to your application.

Add the following CSS to your CSS file, which is used in your application plug-in.

To learn how to implement customizations for CSS, we need a custom widget that should be styled. We implement a simple custom widget, which is a Composite that consists of three other Composites for the header, image, and description area. For the following widget, you should create a widget package in your plug-in and place the UserProfileWidget class into it.

The most important method for our custom CSS here is the last setHeaderColor() method, which we will use for our header-background-color CSS property. To test this widget, you can place it on a new part in your application or in a tooltip as it is depicted in the screenshot above. Afterwards, you should set a certain header-text, an image, and a description-text to the UserProfileWidget.

Select the Extensions tab in the editor for the plugin.xml file and add the org.eclipse.e4.ui.css.core.propertyHandler extension point. You create an extension in the Extensions tab by pressing the Add…​ button.

Select the org.eclipse.e4.ui.css.core.propertyHandler extension point and press the Finish button.

By clicking on the adapter hyperlink of the handler in the plugin.xml, a "New Java Class" dialog appears, where you define the CompositeElement as superclass. Call the class itself UserProfileElementAdapter and place it into a css package.

The UserProfileElementAdapter class should look like this:

In this case, we only have a custom composite that needs to be adapted. The propertyHandler needs a handler that has to be an implementation of the ICSSPropertyHandler interface. Therefore, we need to click on the handler hyperlink in the plugin.xml, and the following "New Java Class" dialog appears:

The AbstractCSSPropertySWTHandler is an abstraction of the ICSSPropertyHandler interface for SWT widgets. It handles the cast to an SWT Control, which is then passed to the applyCSSProperty and retrieveCSSProperty methods. In the UserProfileCSSHandler implementation we apply the header-background-color to our UserProfileWidget.

At first, we check if the given Control is a UserProfileWidget and cast it. Then we check if the property that should be applied is our header-background-color. In case these checks are valid, the CSSEngine can be used to convert the given CSSValue in our case to a Color. The value arrives as an org.w3c.dom.css.CSSValue, which the CSS engine of Eclipse 4.41 (2026-09) builds with its own parser, so let the engine convert it instead of reading the W3C accessors. Finally, we set this color for the header of our custom widget.

The last thing we need to do for the propertyHandler extension is to define for which property-name this handler is responsible:

Now the second and last extension point has to be added:

After adding the org.eclipse.e4.ui.css.core.elementProvider extension point, we can add an IElementProvider to it. For this, click on the class hyperlink and give the class the name UserProfileWidgetElementProvider.

The widget property you can see in the screenshot above points to the fully qualified name of the UserProfileWidget (com.vogella.rcp.css.custom.widget.UserProfileWidget). The widget property may be used several times, so that one IElementProvider implementation can be in charge of several widgets. The UserProfileWidgetElementProvider class we just created by clicking the class hyperlink in the plugin.xml implements the IElementProvider interface and should look like this:

In this IElementProvider implementation, we return the UserProfileElementAdapter, which we previously defined when we attached this adapter to the propertyHandler.

Now we can check if our custom CSS definitions are applied to the UserProfileWidget. Make sure that you have completed all the steps and then start your application.

Adjacent sibling selectors (+) are not supported. A pseudo class is not accepted as the argument of :not(). The :not() itself adds nothing to the specificity of a rule, the specificity of its argument is added instead. A selector the engine rejects disables the whole rule group it belongs to, so qualify class selectors with an element type when in doubt.

Every ToolItem also accepts background-color and color, on GTK these values are not painted.

font-adjust, font-stretch and font-variant are not supported, because an SWT font has no such attribute. Such a declaration is ignored and does not affect the other declarations of the rule.

An SWT font height is a point size, so a font-size is always resolved to points.

Relative values are resolved against the font the widget had before it was styled, which lets a theme ask for a font a bit larger than the rest without overriding the size the user configured in the Colors and Fonts preference page. A relative size on a FontDefinition scales the font the definition was registered with. The font shorthand accepts the same values, for example Label { font: Verdana 1.5em; } or Label { font: Verdana larger; }.

Point sizes stay resolution independent, the platform converts them with the system DPI and Eclipse scales on top of that. Relative sizes, including larger and smaller, and the px conversion require the planned Eclipse 2026-12 release. Before that, px was read as a point size and em and % were ignored.

font-weight accepts normal, bold, bolder, lighter and any number from 1 to 1000. bolder and lighter step from the weight the widget inherited, following CSS Fonts Level 4. The engine derives the inherited weight from the bold flag of the SWT font, so it is always 400 or 700, even if the font uses an intermediate face. For a regular font bolder gives 700 and lighter gives 100. For a bold font bolder gives 900 and lighter gives 400. It also accepts the face names designers use. Apart from normal and bold, these names are not standard CSS.

The names are case-insensitive and may be written without the hyphen, as in semibold, but not with a space, as in semi bold. They are only understood by font-weight, not in the font shorthand, where they could be part of a family name.

An SWT font style only knows regular and bold, but a font family can ship more faces, so a weight between them, such as 500 or 600, selects the installed face of that weight, for example Semibold. On GTK Pango picks the closest face of the family, on Windows a family such as "Segoe UI Semibold" is used when it is installed, and on macOS a face of the family with a matching name such as HelveticaNeue-Medium. Where no such face is found, a weight of 600 or more selects the bold face and anything below it the regular one. The face is chosen by rounding the weight to the nearest hundred, halves rounding up, and clamping the result to 100 to 900. So 50 uses the 100 face, 650 the bold face, and 950 and 1000 the 900 face. A number outside 1 to 1000 is ignored.

In the font shorthand normal, bold, bolder and lighter are weights too. Only a bare multiple of 100 from 100 to 900 is read as a weight there, any other bare number is a size in points. So Label { font: 600 12pt Arial; } and Label { font: 12 Arial; } both work, but in font: 1000 12pt Arial the 1000 is read as a size. When the shorthand contains several sizes the last one wins, so this declaration gives a 12pt font and font: 12pt 1000 Arial a 1000pt one. Set such a weight with font-weight instead.

The numeric weights, bolder, lighter, the face names and the face selection require the planned Eclipse 2026-12 release. Before that, only bold made a font bold and every other value made it regular.

There is no property for the selection colors of Tree, Table and List, these come from SWT.

Use one color for swt-unselected-tabs-color. Two different colors switch the folder to a gradient image, and the controls in the tab row, the min/max bar and the chevron, then stop following the theme. Starting with the planned Eclipse 2026-12 release, a gradient whose stops are all the same color is collapsed to that solid color, so it no longer produces the image. Before that, even identical stops produced the gradient image.

The swt-show-close and swt-mru-visible properties listed in older documentation are no longer registered by the engine, swt-show-close was removed in Eclipse 2024-03. Use the closeable flag of the MPart to control the close button and swt-unselected-close-visible to hide it on the unselected tabs. swt-tab-outer-keyline is not registered either, swt-outer-keyline-color is the property that works.

Color and font definitions are the entries of the theme registry, contributed by plug-ins through the org.eclipse.ui.themes extension point. The Colors and Fonts preference page is the view on that registry, so a definition a stylesheet changes is the one the user sees there. A stylesheet can change existing definitions, register new ones and write preference values when the theme is activated.

The id of a definition is its Eclipse id with . replaced by -, so org.eclipse.jface.textfont becomes #org-eclipse-jface-textfont. Once registered, a definition is used as a value in any rule, e.g. color: '#my-FG';. Preference values are written when the theme is applied and stay in the preference store until the next theme switch, so hand tuned values are overwritten.

category, label, description and editable only affect the preference page, a definition with editable: false is left out of it entirely. Definitions are implemented in org.eclipse.ui.workbench, so they work in an RCP application that ships org.eclipse.ui, but a pure e4 application has none to override.

A pseudo class is evaluated whenever the engine applies styles to a widget. Only :focus, :hover, :checked and :active can also trigger a restyle while the application runs, and only if the org.eclipse.e4.ui.css.dynamic=true system property is set. Without it the engine does not attach the focus, mouse, selection and shell listeners that request the restyle.

:enabled, :disabled and :visible are read from the widget on every run, but no widget change ever starts one, so a later setEnabled() or setVisible() call does not repaint the widget in the new style.

If you need more assistance we offer Online Training and Onsite training as well as consulting

See License for license information.