cepheus

Work In Progress

Cepheus

In this brief document, we present Cepheus, a functional utility class generator. We provide a short history of CSS (Cascading Style Sheets). We describe several methodologies to write CSS and present rationale for choosing functional CSS.

Table Of Contents

• The History of CSS
• Methodologies
  • BEM
  • SMACSS
  • Object-Oriented CSS
  • Functional CSS
• Cepheus
• References

The History Of CSS

The history of CSS starts in 1994. Hakon Wium Lie worked at CERN, and the web was starting to be used as a platform for electronic publishing. A publishing platform requires styling capabilities and documents couldn’t be styled at the time. Hakon noticed that the web needs a style sheet language.

Style sheets in browsers were not a new idea. Separating document structure from layout had been a goal of HTML since the beginning. Tim Berners-Lee added style sheets support his NeXT browser/editor. However, he didn't publish the style sheets syntax, leaving it to browsers to decide how to best display pages to users.

In 1993, NCSA Mosaic, the browser that made the web popular, came out. It only allowed its users to change colors and fonts. Authors complained that they didn't have enough influence over how their pages looked.

Hakon published the first draft of the Cascading HTML Style Sheets proposal. As planned, the initial CSS proposal was presented at the Web conference in Chicago in November 1994. The presentation at Developer's Day caused much discussion. CSS was for criticized for being too simple for the task it was designed for. It was argued that a full programming language was needed to style documents. CSS was the exact opposite of that and made a point of being a simple, declarative format.

Bert Bos was one of the people who responded to the first draft of CSS. Bos was building a customizable browser with style sheets named Argo, and he decided to collaborate with Hakon. The Argo style language was general enough to apply to other markup languages besides HTML. This became a design goal in CSS and HTML was soon removed from the title of the specification.

At one of the next WWW conferences in April 1995, CSS was presented again. Both Bert and Hakon attended the conference. Bert presented Argo, and Hakon showed a version of the Arena browser that he had modified to support CSS.

The World Wide Web Consortium (W3C) became operational in 1995. Workshops on various topics were found to be a successful way for W3C members and staff to meet and discuss future technical development.

At the end of 1995, W3C organized the HTML Editorial Review Board (HTML ERB) to discuss future HTML specifications. The HTML ERB took up the CSS specification to make it into a W3C Recommendation

CSS level 1 finally emerged as a W3C Recommendation in December 1996. CSS1 supports font properties, color of text, backgrounds, text attributes, images, tables, margin, border, padding, positioning for most elements, unique identification and generic classification of groups of attributes, etc.

In February 1997, CSS got its working group inside W3C chaired by Chris Lilley. CSS level 2 became a Recommendation in May 1998. A superset of CSS 1, CSS 2 includes a number of new capabilities like absolute, relative, fixed positioning of elements, z-index, media types, support for aural style sheets and bidirectional text, new font properties and so on.

CSS level 2 revision 1, often referred to as "CSS 2.1", fixes errors in CSS 2, removes poorly supported or not fully interoperable features and adds already implemented browser extensions to the specification.

Unlike CSS 2, which is a single broad specification defining various features, CSS 3 is divided into several separate documents called "modules." The features in CSS3 included borders, box shadow, background size, opacity, outline, HSLA colors, attribute selectors, etc. The earliest CSS 3 drafts were published in June 1999.

There is no single, integrated CSS4 specification because it is split into separate "level 4" modules. CSS4 adds variables, grid, snap points, additional selectors and so on.

Methodologies

CSS methodologies help to deal with the complexity of managing large, rapidly-iterated systems. They are formal, documented systems for authoring CSS in a way that allows developing, maintaining and scaling front-end codebases as a set of small, isolated modules. In this section, we describe four widespread CSS methodologies: SMACSS, BEM, OOCSS, and FCSS.

BEM

BEM stands for Block Element Modifier and originated at Yandex. It provides a rather strict way to arrange CSS classes into independent modules.

• A block represents an object in a website such as a person, login form, menu, search form, etc.
• An element is a component within the block that performs a particular function. It should only make sense in the context of its block. For example, a hand, login button, menu item, search input field and so on.
• Finally, a modifier is how the variations of a block are represented: tall/short person, condensed login form, a menu modified to look differently for a footer or sitemap, a search input field with a particular button style, etc.

SMACSS

“SMACSS is more of a style guide than a rigid framework. There is no specific library implementing it. SMACSS is a way to examine design processes and a way to fit those rigid frameworks into a flexible thought process. It is an attempt to document a consistent approach to site development when using CSS.” Jonathan Snook, author of SMACSS

It focuses on five categories for its rules:

• Base is used for defaults like html, body, a, a:hover. This includes CSS resets and would often be in its base CSS file or at the start of your main CSS.
• Layout divides a page into sections with elements like header, footer, and article. Often developers show layout elements by prefixing the class with l-.
• Module is a reusable, modular element in the design. The SMACSS documentation sees modules as the majority of elements and thus doesn’t require prefixing them.
• State is used for the variations possible for each element (e.g., active, inactive, expanded, hidden). These are prefixed with is-, e.g. is-active, is-inactive, is-expanded, is-hidden or are via pseudo-classes such as :hover and :focus or media queries.
• Theme is similar to state but defines how modules and layouts will look. It is more applicable for larger sites with shared elements that look different throughout. Theme variations would be added on a per page or per section basis.

SMACSS states that it’s all up to the developer’s preference and isn’t as prescriptive as BEM. SMACSS just provides basic guidelines. Each of the categories can be arranged in a developer’s preferred way, as long as they document the approach so that other developers can follow along.

Object-Oriented CSS

OOCSS draws upon many concepts in object-oriented programming, including the single responsibility principle and separation of concerns. The goal is to produce more manageable components that are flexible, modular and interchangeable.

In CSS, the “object” can be any repeating visual pattern that can be specified in snippets of code. Page elements and even groups of elements are given object classes, which are treated as single entities in style sheets.

“There are two main principles [in > object-oriented CSS]: the first is to separate the structure from the skin and the second is to separate the container from the content.” Nicole Sullivan, author of OOCSS

“Invisible” things to the user such as height, width, margins, padding, overflow, etc., comprise the structure of the application. An application’s skin refers to the visual properties of elements such as colors, fonts, shadows, gradients and so on. Essentially, the structure is the instructions for how things are laid out, and the skin defines what the layout looks like. These two concepts are separated on OOCSS.

Separating containers from content makes for more consistent and predictable user experience. In this context, content refers to elements such as images, paragraphs and div tags that are nested within other elements, which serve as containers.

Speed, scalability, and efficiency are often considered advantages of OOCSS, with disadvantages being maintainability, and the increase of the number of classes added to an element.

Functional CSS

Functional CSS (and its variations such as atomic CSS, immutable CSS) is the idea of assembling small, single property, immutable classes into larger components.

Brent Jackson and Adam Morse influences functional CSS. Jackson authored Basscss, a low-level CSS Toolkit, and Morse created Tachyons, a functional CSS framework for quickly building and designing UI.

Functional CSS contains small, clear, easy to read classes that do one thing. These are otherwise known as utility classes. An example from Tachyons would be margin & padding classes — ma1, pl2 (margin-1, padding-left-2) etc.

Functional CSS is composable. Code gets reused a lot, improving improves performance and consistency.

CSS is inherently mutable (the "C" in CSS - the Cascade). Functional CSS classes have a single responsibility, they don’t risk overriding each other. This ensures that changing a property somewhere won't break code elsewhere, so the problems of the cascade are eliminated. Class names express their functionality in a clear manner.

Cepheus

Cepheus is a functional CSS utility class generator. It builds upon functional CSS methodologies. Cepheus utilizes classnames and sensible default values from Tachyons. The type-scale module is modified. Modules providing default baseline rhythm and flexible debug options are added. These single-purpose utility modules cover the whole CSS spectrum — typography to spacing, theming to elements. Cepheus is configurable, meaning that a user can decide which modules to import. Modules, in turn, can be modified with ease.

Installation

npm install -S cepheus

Contributing

Please read our contributing guideline.

License

This program is free software: you can redistribute it and/or modify it under the terms of the MPL 2.0. This program uses third-party libraries or other resources that may be distributed under different licenses. Please refer to the specific files and/or packages for more detailed information about the authors, copyright notices, and licenses.

References