Introduction
This Style Guide contains examples of all the modules included in IceGroupWeb Styles. Click the show markup button beneath an example to see the HTML structure. Important class names are listed at the top of each module.
Changelog on ICESpace—includes a link to the most recent version
Using the style sheets
ICE Styles are split among five different stylesheets. The first two are required and should be included on all pages. Only add the other three to pages when needed, to prevent additional requests slowing down the user experience in the browser.
- font—This contains the web font (required)
- core—All the most common styles. (required)
- extended—An extended set of styles
- lists—Enhanced list and nav styles in addition to those included in the core
- tables—Enhanced table styles in addition to those included in the core
Throughout this style guide, the tags extended, lists, and tables are used to indicate when a module requires inclusion of a stylesheet beyond the font and core stylesheets.
The URLs for all stylesheets are as follows. Be sure to replace the [version] as appropriate:
ICE
ICE styles use the font “Suisse Int’l”.
As of version 4.0, a font tracking script is no longer required on the page
NYSE
NYSE styles use the font “Gotham”, which we also host.
An example set of links in your page's <head> is below. This includes the mandatory font & core styles, as well as the extended table classes:
<link rel="stylesheet" type="text/css" href="https://static.theice.com/font-suisse-intl/1.0.1/fonts.css">
<link rel="stylesheet" type="text/css" href="https://static.theice.com/icegroupweb-styles/4.0.0/css/ice-core.min.css">
<link rel="stylesheet" type="text/css" href="https://static.theice.com/icegroupweb-styles/4.0.0/css/ice-tables.min.css">
CSS philosophy
These are some of the distinctive principles behind the IceGroupWeb CSS:
One-way contract
The typical approach to CSS involves a tight coupling between HTML and its CSS. To update one often means the other needs to be updated as well. We believe this leads to unmaintanable code; spaghetti code does exist in CSS—in fact, most CSS on the internet today is spaghetti code.
To mitigate this problem, IceGroupWeb Styles dictates how the HTML must be structured. This creates a unilateral relationship between the two, instead of a two-way coupling. This leads to cleaner code, easier maintenance, and fewer headaches for everyone.
Modular
Every CSS component is an atomic, reusable piece. Instead of styling each page one at a time, we define a set of modules which can be pieced together any way we like to define a page the way we need it. Modules are not styled according to their context (#sidebar .btn) but rather "sub-classed" for extended or alternate treatments (.btn-inverse).
Opt-in styling
Few styles are applied universally to common elements like <input> or <ul>. Instead, classes are used to opt-in to a specific style. This prevents us from having to write additional CSS later to override a bunch of generically-applied styles.
Bottom margins
Most modules use bottom margins to provide appropriate spacing. The use of <br>s for spacing should be entirely unecessary. We use <p> tags around each paragraph and generally do not put raw content inside of generic (i.e. unclassed) <div>s.
Top margins are almost always avoided. Our grid system and some other components rely on clearfixes, which prevents margin collapsing is some contexts. With top-margins, this would often result in too much space between page elements.
In instances where the standard margins aren't appropriate, spacer classes are available to explicitly set them.
Working with modular CSS
To build a page, follow the instructions in page layout to create the high-level page structure. Then fill it in with any modules you like. They are designed to be, well, modular: you can mix and match them however you need. The pages of this documentation detail out dozens of modules for you to choose from; find the ones that meet your need best. Use the grid system to structure your page into smaller containers where necessary, and place modules inside them.
At times, this list of modules may seem restricting—you may want a larger module here or a different colored module there—but this restriction is what keeps our branding consistent. Try to work within it as much as possible.
Each module is documented along with example markup, showing the module in action. Key class names and tags are highlighted in bold. Some modules have variations available. These work by adding additional class names. For instance, you create a button by using the btn class; create the "success" variant by using both the btn and btn-success class on the same element.
If you think you find a bug, report it to the WebDev team. If you think you have a strong case for a new module or a new variation of an existing module, let us a know, and we’ll see what we can do. We want this CSS toolset to be useful to a large number of projects at ICE/NYSE.
JavaScript
Some modules require the addition of JavaScript to enable interactive behavior. This is called out for each module where this is the case. These scripts are not provided by IceGroupWeb Styles; instead of attempting to write scripts that work across a wide variety of libraries and frameworks, we leave it up to you to develop something that fits into your application architecture.
For each module that requires JavaScript, instructions are provided for the functionality you will need to provide. Where possible, links to standard libraries that can perform this are included.