Approach

While the getting started pages provide an introductory tour of the project and what it offers, this document focuses on why we do the things we do in OUDS Web. It explains our philosophy to building on the web so that others can learn from us, contribute with us, and help us improve.

See something that doesn’t sound right, or perhaps could be done better? Open an issue—we’d love to discuss it with you.

Summary

We’ll dive into each of these more throughout, but at a high level, here’s what guides our approach.

• Components should be responsive and mobile-first
• Components should be built with a base class and extended via modifier classes
• Component states should obey a common z-index scale
• Whenever possible, prefer an HTML and CSS implementation over JavaScript
• Whenever possible, use utilities over custom styles
• Whenever possible, avoid enforcing strict HTML requirements (children selectors)

Responsive

OUDS Web’s responsive styles are built to be responsive, an approach that’s often referred to as mobile-first. We use this term in our docs and largely agree with it, but at times it can be too broad. While not every component must be entirely responsive in OUDS Web, this responsive approach is about reducing CSS overrides by pushing you to add styles as the viewport becomes larger.

Across OUDS Web, you’ll see this most clearly in our media queries. In most cases, we use min-width queries that begin to apply at a specific breakpoint and carry up through the higher breakpoints. For example, a .d-none applies from min-width: 0 to infinity. On the other hand, a .d-md-none applies from the medium breakpoint and up.

At times we’ll use max-width when a component’s inherent complexity requires it. At times, these overrides are functionally and mentally clearer to implement and support than rewriting core functionality from our components. We strive to limit this approach, but will use it from time to time.

Classes

Aside from our Reboot, a cross-browser normalization stylesheet, all our styles aim to use classes as selectors. This means steering clear of type selectors (e.g., input[type="text"]) and extraneous parent classes (e.g., .parent .child) that make styles too specific to easily override.

As such, components should be built with a base class that houses common, not-to-be overridden property-value pairs. For example, .btn and .btn-strong. We use .btn for all the common styles like display, padding, and border-width. We then use modifiers like .btn-strong to add the color, background-color, border-color, etc.

Modifier classes should only be used when there are multiple properties or values to be changed across multiple variants. Modifiers are not always necessary, so be sure you’re actually saving lines of code and preventing unnecessary overrides when creating them. Good examples of modifiers are our theme color classes and size variants.

Bootstrap compatibility

OUDS Web is built on the basis of design tokens that capture all the design decisions utilized within our design system. They ensure the consistency of components between them and facilitate the configuration of the library.

These tokens are specific to OUDS Web. They are notably used as a basis for the construction of utilities. This is why the names (and not only the values) of the OUDS Web utilities differ from the Bootstrap utilities.

The option $enable-bootstrap-compatibility, if set to true, allows to keep in the library the Bootstrap elements in addition to the OUDS Web elements (like helpers, utilities, variables, components variants, etc.). In this case, we made a best-effort attempt to style the Bootstrap elements to resemble those of OUDS.

However, we recommend not to enable this option, even if it is enabled for the OUDS Web site itself, for obvious documentation reasons. You should not need it to build Orange branded sites with OUDS Web. It should only be useful whenever a project relies on external Bootstrap-based libraries or plugins used in combination with OUDS Web CSS.

HTML and CSS over JS

Whenever possible, we prefer to write HTML and CSS over JavaScript. In general, HTML and CSS are more prolific and accessible to more people of all different experience levels. HTML and CSS are also faster in your browser than JavaScript, and your browser generally provides a great deal of functionality for you.

This principle is our first-class JavaScript API using data attributes. You don’t need to write nearly any JavaScript to use our JavaScript plugins; instead, write HTML.

Lastly, our styles build on the fundamental behaviors of common web elements. Whenever possible, we prefer to use what the browser provides.

The same goes for more complex components. While we could write our own form validation plugin to add classes to a parent element based on an input’s state, thereby allowing us to style the text say red, we prefer using the :valid/:invalid pseudo-elements every browser provides us.

Utilities

Utility classes are a powerful ally in combating CSS bloat and poor page performance. A utility class is typically a single, immutable property-value pairing expressed as a class (e.g., .d-block represents display: block;). Their primary appeal is speed of use while writing HTML and limiting the amount of custom CSS you have to write.

Specifically regarding custom CSS, utilities can help combat increasing file size by reducing your most commonly repeated property-value pairs into single classes. This can have a dramatic effect at scale in your projects.

Flexible HTML

While not always possible, we strive to avoid being overly dogmatic in our HTML requirements for components. Thus, we focus on single classes in our CSS selectors and try to avoid immediate children selectors (>). This gives you more flexibility in your implementation and helps keep our CSS simpler and less specific.

Code conventions

Code Guide (from Bootstrap co-creator, @mdo) documents how we write our HTML and CSS across OUDS Web. It specifies guidelines for general formatting, common sense defaults, property and attribute orders, and more.

We use Stylelint to enforce these standards and more in our Sass/CSS. Bootstrap custom Stylelint config is open source and available for others to use and extend.

We use vnu-jar to enforce standard and semantic HTML, as well as detecting common errors.