>One of the most powerful and in some ways controversial items in e4 is the ability to use CSS for styling SWT/XWT components. Many demonstrations have shown the ability to apply custom theming to the items, but nothing has shown native integration.
I ran across an interesting blog post the other day by Craig Butler, How to Use Operating System Styles in CSS. If your web browser supports CSS2.1 you will see in the examples columns your operating system defaults. Examples taken from his blog, see his full blog for details on how to implement these in CSS.
Fonts:
The following font values are available. The ‘Example’ column shows the current font set by your OS.
| Property | Description | Example |
|---|---|---|
| caption | Controls font (buttons, drop-downs, etc.) | ABC abc 123 |
| icon | Icon label font | ABC abc 123 |
| menu | Menu font | ABC abc 123 |
| message-box | Dialog box font | ABC abc 123 |
| small-caption | Small control labels | ABC abc 123 |
| status-bar | Status bar font | ABC abc 123 |
Operating System Colors:
| Property | Description | Example |
|---|---|---|
| ActiveBorder | Active window border | |
| ActiveCaption | Active window caption | |
| AppWorkspace | Background color of multiple document interface | |
| Background | Desktop background | |
| ButtonFace | Face color for 3D display elements | |
| ButtonHighlight | Dark shadow for 3D display elements (facing away from light) | |
| ButtonShadow | Shadow color for 3D display elements | |
| ButtonText | Text on push buttons | |
| CaptionText | Text in caption, size box, and scrollbar arrow box | |
| GrayText | Grayed (disabled) text (#000 if not supported by OS) | |
| Highlight | Item(s) selected in a control | |
| HighlightText | Text of item(s) selected in a control | |
| InactiveBorder | Inactive window border | |
| InactiveCaption | Inactive window caption | |
| InactiveCaptionText | Color of text in an inactive caption | |
| InfoBackground | Background color for tooltip controls | |
| InfoText | Text color for tooltip controls | |
| Menu | Menu background | |
| MenuText | Text in menus | |
| Scrollbar | Scroll bar gray area | |
| ThreeDDarkShadow | Dark shadow for 3D display elements | |
| ThreeDFace | Face color for 3D display elements | |
| ThreeDHighlight | Highlight color for 3D display elements | |
| ThreeDLightShadow | Light color for 3D display elements (facing the light) | |
| ThreeDShadow | Dark shadow for 3D display elements | |
| Window | Window background | |
| WindowFrame | Window frame | |
| WindowText | Text in windows |
intellectualcramps 
>surprisingly in CSS 3 draft, system colors are depreciated.
>Guess now is the time to comment on the CSS 3 draft, since that is what draft specifications are released. I think it is critical that the CSS styling by default keeps the system colors, and then allows the plugin developer to override with their own CSS where necessary.
>I think the issue over whether to use system colors (and fonts) is controversial, but that's not to say that e4 CSS won't provide access to them. For example, see bug #284488. Ideally the CSS support in e4 should allow you to do everything you used to, and more. While my personal belief is that with more web based applications, our collective design goals are moving away from platform L&F. However, as a framework, we shouldn't dictate that.
>Correction to previous comment, bug is #278498.To add…I thought your post provided an interested direction, which is SWT interpretation of (semi) standard CSS color names. Bug #278498 takes a different approach, wherein we could use SWT color names (like SWT.COLOR_LIST_FOREGROUND) in CSS. The advantage to the CSS 2.1 approach you mentioned is you could use the exact same CSS in desktop and web, a CSS 2.1 edito might provide correct value code completion, etc. The advantages to the SWT named color approach though are that it's clear to the developer exactly what they're getting, and there's no semantic mapping from CSS names to SWT names. Both are interesting approaches, but I tend to favor the latter.
>@Kevin: The point of CSS though is to separate the look and feel from the underlying implementation. SWT may be used to choose the colors, but there needs to be the higher level abstraction from a UI designers point of view. The person doing the styling isn't necessarily going to be the developer writing the code. Too much of SWT and eclipse ties styling and code together too much currently.That is the huge advantage of using Declarative UI and styling languages, that separation of the look and feel from the underlying content.If supporting CSS, you should support what the standard provides.