
All of the presentational aspects of our site are now in CSS files, and we provide users with the theme, or "skin", which they can use to view the application. Web standards compliance also provides significant benefits for our partners, who see a different page depending on the user-agent supplied by the requesting web browser. The effects of browser-specific sheets are quite minimal and are targeted to specific buggy behavior in each browser. Most likely they will not impact your integrations, but you should be aware of these differences and test your integration in both Internet Explorer 6.0 and Mozilla Firefox 1.x.
Organizations can access the Salesforce user interface theme.
We also provide language-specific sheets to display Asian character sets which may appear too small otherwise. Rules for font-family and font-size are appended to the end of Asian language style sheets.
Each published theme has its own directory. Within those directories, there is a second level of directories for each language code (en, es, de, ko, ja, etc).
Developers mimicking the Salesforce look and feel need to determine the language setting for each user.
The GetUserInfoResult object, returned by calling getUserInfo, includes userLanguage and userUiSkin values.
userLanguage returns the code for the user's selected language:
| userLanguage Value | Language |
|---|---|
| en | English |
| fi | Finnish |
| ja | Japanese |
| de | German |
| fr | French |
| it | Italian |
| sv | Swedish |
| pt_BR | Portuguese (Brazilian) |
| ru | Russian |
| nl | Dutch |
| zh | Chinese (Simplified) |
| zh_TW | Chinese (Traditional) |
| ko | Korean |
| tw | Thai |
userUiSkin returns a value of indicating the CSS path that should be specified:
| userUiSkin Value | CSS Path |
|---|---|
| Salesforce2 | /dCSS/Theme2/{lang}/common.css |
The URL will be of the following form:
/sCSS/{version}/{theme}/{lang}/{sheet}.css
where:
userUiSkin
userLanguage
Examples:
To retrieve common.css for an English speaking user using the Salesforce theme, you would specify:
/sCSS/Theme2/en/common.css
To retrieve setup.css for a Japanese speaking user using the Salesforce theme, you would specify:
/sCSS/Theme2/ja/setup.css
| File | Description |
|---|---|
common.css in version 8.0 and 7.0, dStandard.css in version 9.0 and later | Everything--this is often the only file you need to reference when mimicking Salesforce's look and feel. |
custom.css in version 7.0, /sCSS/8.0/Theme2/allCustom.css in version 8.0 and later. As of the Summer '08 release you should use /sCSS/12.0/Theme2/allCustom.css. | Definitions for palettes and tab colors for custom tabs |
setup.css | Setup pages |
The CSS files below are listed only for completeness. You should never need to reference these files.
| File | Description |
|---|---|
| addUsers.css | Add more trial users |
| advancedForecasting.css | Used only on the Customizable Forecasting page |
| allTabs.css | All Tabs page |
| homeCalendar.css | Calendars (popup and homepage) |
| CampaignManageMembersPage.css | Manage Campaign Members page |
| confirmDelete.css | Confirm Delete |
| confirmForm.css | Confirm Delete |
| customFieldTypeSelect.css | Custom Field Type Selection page |
| customFiscalYear.css | Custom Fiscal Year pages |
| customFiscalYear_print.css | Custom Fiscal Year printable view |
| customizemydisplay.css | Customize My Display page |
| dashboard.css | Dashboards (Dashboard tab and overview page) |
| DesktopPage.css | Agent Console |
| DesktopMainPage.css | Agent Console |
| DesktopMicroPage.css | Agent Console |
| dStandard.css | tab standar from salesforce |
| EditDependencyUICSS.css | Dependent picklists |
| Field Accessibility edit page | |
| integrationServlet.css | Splash Pages for Appforce apps |
| popupWithHeader.css | Hides the tabs and sidebar for use in popups |
| layoutdnd.css | Drag and drop page layouts |
| layoutPreview.css | Page layout preview pages |
| multiforceImport.css | Used on Appforce import wizard pages |
| orderCenter.css | Order Center |
| PreviewDependencyCSS.css | Used on a dependency preview popup |
| printableView.css | Printable views |
| project.css | Used in the custom AppExchange setup area |
| RequestAdvForecastPage.css | Request Customizable Forecasting |
| searchLayoutExample.css | Popup with an example search layout |
A unique feature of the salesforce.com CSS is the use of palettes. Many elements in the page pick up a different color depending on the selected tab: when accounts are selected, the tab background is a saturated blue, the page header and the border of the detail element are a lighter blue, and the subheader bars within the detail element are a slightly lighter blue. In order to avoid assigning different CSS classes to each element on each tab, while also avoiding having different stylesheets for each color of tab, we employ palettes.
There are three CSS classes that can be assigned to any element: primaryPalette, secondaryPalette, and tertiaryPalette. They control the background-color and border-color of any element they are assigned to.
The <body> element of each page has a class assigned to it that reflects the selected tab; for instance, when the Accounts tab is selected, we have <body class='account'>.
NOTE: In previous releases, body class names for standard objects were just the tab name, for example account. Beginning with version 9.0, they include "Tab" at the end of the name, for example accountTab. In previous releases body class names for custom objects were of the form customTabX. Beginning with version 9.0, they are of the form CustomXTab.
By default the color of the page or tab is used throughout. To get a block to use its own color, the class individualPalette should be used in a parent of the element classed with ObjectNameBlock, for example:
<div class="individualPalette">
<div class="accountBlock">
Some text that needed its own color.
</div>
</div>
Finally, there is a set of CSS selectors like this:
body .individualPalette .accountBlock,
.accountTab .primaryPalette {
background-color: #236FBD;
border-color: #236FBD;
}
body .individualPalette .accountBlock,
.accountTab .secondaryPalette {
background-color: #4579B5;
border-color: #4579B5;
}
body .individualPalette .accountBlock,
.accountTab .tertiaryPalette {
background-color: #8A9EBE;
border-color: #8A9EBE;
}
You can assign a palette to the element’s tab color. In general, you will want to use either secondary or tertiary palettes; the primary palette is only used for the tab bar itself. For instance, to create a box with class ’foo,’ with a two pixel border that matches the border around Detail elements, you could specify the following:
CSS
.foo {
border-width: 2px;
border-style: solid;
}
HTML
<div class="foo primaryPalette">Lorem ipsum dolor sit amet...</div>
Note that the div above has two classes; it is legal for an HTML element to have an arbitrary number of classes, which should be separated by spaces in the attribute. Also note that the border color was not set by the .foo selector. In this case, if the border-color were set there, it would be overridden by the palette color due to specificity rules, but in many cases (e.g. a selector (.bar .foo td)) the color would override the palette's color, rendering the palette useless.
Please ensure that you define the following DOCTYPE at the top of your HTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
This must be the very first non-whitespace string in the file (with the exception of <?xml> specifiers).
Serving XHTML or using the strict DOCTYPE should also work fine as long as they are used properly. But in general we recommend specifying the DOCTYPE listed above to avoid idiosyncrasies in rendering the page.
With the Winter '06 release, the application banner will appear differently depending on the selected UI theme. This means that any custom logos uploaded for custom applications may appear misformatted.
To avoid this problem, please modify all of your custom logo images to meet the following specifications--these changes will guarantee custom logos that will look good for any selected UI theme.
In Winter '06, picklists are displayed by modifying the Document Object Model (DOM) after the main page has been loaded. The main page contains only the necessary markup to show the current or default value of the picklist; all other values are cached separately by the browser and added to the page as part of the onLoad event.
The implications for screen scrapers and integrations are:
Note: Screen scraping is not supported by salesforce.com and could break at any time due to application updates.