This is an experiment that creates social media icons using CSS and semantic HTML. It uses progressive enhancement to turn an unordered list of text links into a set of icons without the use of images or JavaScript.

Demo: Pure CSS social media icons

Support: Firefox 3.5+, Safari 4+, Chrome 4+, Opera 10+, IE8+.

CSS social media icons

The image below shows you the final appearance in modern browsers.

This experiment starts with a simple list of links, with each link using meaningful text, and then progressively styles each link to take on the appearance of the relevant social media icon. As a result, there should be support for screenreaders or users with CSS disabled.

I’ve also included basic text in the title attribute of each link to provide information for users who may not be familiar with what service a specific icon represents.

This is an experiment that uses CSS 2.1 and CSS3 that is not supported by Internet Explorer 6 and 7, therefore, you shouldn’t expect it to work in those browsers. CSS is not necessarily the most appropriate tool for this kind of thing either.

Example code

The technique I’ve used is much the same as the one used for the Pure CSS speech bubbles.

The HTML is just a basic unordered list of links to various social networking websites or services.

<ul>
   <li class="facebook"><a href="#non" title="Share on Facebook">Facebook</a></li>
   <li class="twitter"><a href="#non" title="Share on Twitter">Twitter</a></li>
   <li class="rss"><a href="#non" title="Subscribe to the RSS feed">RSS</a></li>
   <li class="flickr"><a href="#non" title="Share on Flickr">Flickr</a></li>
   <li class="delicious"><a href="#non" title="Bookmark on Delicious">Delicious</a></li>
   <li class="linkedin"><a href="#non" title="Share on LinkedIn">LinkedIn</a></li>
   <li class="google"><a href="#non" title="Bookmark with Google">Google</a></li>
   <li class="orkut"><a href="#non" title="Share on Orkut">Orkut</a></li>
   <li class="technorati"><a href="#non" title="Add to Technorati">Technorati</a></li>
   <li class="netvibes"><a href="#non" title="Add to NetVibes">NetVibes</a></li>
</ul>

I’ve applied some general styles to the elements that make up this list.

ul {
   list-style:none;
   padding:0;
   margin:0;
   overflow:hidden;
   font:0.875em/1 Arial, sans-serif;
}

ul li {
   float:left;
   width:66px;
   height:66px;
   margin:20px 20px 0 0;
}

ul li a {
   display:block;
   width:64px;
   height:64px;
   overflow:hidden;
   border:1px solid transparent;
   line-height:64px;
   text-decoration:none;
   /* css3 */
   text-shadow:0 -1px 0 rgba(0,0,0,0.5);
   -moz-border-radius:5px;
   -webkit-border-radius:5px;
   border-radius:5px; /* standards version last */
}

ul li a:hover,
ul li a:focus,
ul li a:active {
   opacity:0.8;
   border-color:#000;
}

Each icon uses it’s own set of styles. This is the CSS that created the RSS icon.

.rss a {
   position:relative;
   width:60px;
   padding:0 2px;
   border-color:#ea6635;
   text-transform:lowercase;
   text-indent:-186px;
   font-size:64px;
   font-weight:bold;
   color:#fff;
   background:#e36443;

   /* css3 */
   -moz-box-shadow:0 0 4px rgba(0,0,0,0.4);
   -webkit-box-shadow:0 0 4px rgba(0,0,0,0.4);
   box-shadow:0 0 4px rgba(0,0,0,0.4);
   background:-webkit-gradient(linear, left top, left bottom, from(#f19242), to(#e36443));
   background:-moz-linear-gradient(top, #f19242, #e36443);
   background:linear-gradient(top, #f19242, #e36443);
}

.rss a:before,
.rss a:after {
   content:"";
   position:absolute;
   bottom:10px;
   left:10px;
}

/* create circle */
.rss a:before {
   width:12px;
   height:12px;
   background:#fff;
   /* css3 */
   -moz-border-radius:12px;
   -webkit-border-radius:12px;
   border-radius:12px;
}

/* create the two arcs */
.rss a:after {
   width:22px;
   height:22px;
   border-style:double;
   border-width:24px 24px 0 0;
   border-color:#fff;
   /* css3 */
   -moz-border-radius:0 50px 0 0;
   -webkit-border-radius:0 50px 0 0;
   border-radius:0 50px 0 0;
}

Acknowledgements

This post was inspired by an experiment on insicdesigns that producing a few social media icons using CSS.

This toad jumped out of the long grass near a pond and kindly let me take a few photographs of it.

The following is an interesting extract from Straw Dogs by John Gray (pp. 109–116) discussing some of the differences between Western and Taoist philosophical traditions.

The fetish of choice

For us, nothing is more important than to live as we choose. This is not because we value freedom more than people did in earlier times. It is because we have identified the good life with the chosen life.

For the pre-Socratic Greeks, the fact that our lives are framed by limits was what makes us human. Being born a mortal, in a given place and time, strong or weak, swift or slow, brave or cowardly, beautiful or ugly, suffering tragedy or being spared it – these features of our lives are given to us, they cannot be chosen. If the Greeks could have imagined a life without them, they could not have recognised it as that of a human being.

The ancient Greeks were right. The ideal of the chosen life does not square with how we live. We are not authors of our lives; we are not even part-authors of the events that mark us most deeply. Nearly everything that is most important in our lives is unchosen. The time and place we are born, our parents, the first language we speak – these are chance, not choice. It is the casual drift of things that shapes our most fateful relationships. The life of each of us is a chapter of accidents.

Personal autonomy is the work of our imagination, not the way we live. Yet we have been thrown into a time in which everything is provisional. New technologies alter our lives daily. The traditions of the past cannot be retrieved. At the same time we have little idea of what the future will bring. We are forced to live as if we were free.

The cult of choice reflects the fact that we must improvise our lives. That we cannot do otherwise is a mark of our unfreedom. Choice has become a fetish; but the mark of a fetish is that it is unchosen.

Animal virtues

The dominant Western view…teaches that humans are unlike other animals, which simply respond to the situations in which they find themselves. We can scrutinise our motives and impulses; we can know why we act as we do. By becoming ever more self-aware, we can approach a point at which our actions are the results of our choices. When we are fully conscious, everything we do will be done for reasons we can know. At that point, we will be authors of our lives.

This may seem fantastical, and so it is. Yet it is what we are taught by Socrates, Aristotle and Plato, Descartes, Spinoza and Marx. For all of them, consciousness is our very essence, and the good life means living as a fully conscious individual.

…

Western thought is fixated on the gap between what is and what ought to be. But in everyday life we do not scan our options beforehand, then enact the one that is best. We simply deal with whatever is at hand. …Different people follow different customs; but in acting without intention, we are not simply following habit. Intentionless acts occur in all sorts of situations, including those we have never come across before.

Outside the Western tradition, the Taoists of ancient China saw no gap between is and ought. Right action was whatever comes from a clear view of the situation. They did not follow moralists – in their day, Confucians – in wanting to fetter human beings with rules or principles. For Taoists, the good life is only the natural life lived skillfully. It has no particular purpose. It has nothing to do with the will, and it does not consist in trying to realise any ideal. Everything we do can be done more or less well; but if we act well it is not because we translate our intentions into deeds. It is because we deal skillfully with whatever needs to be done. The good life means living according to our natures and circumstances. There is nothing that says that it is bound to be the same for everybody, or that it must conform with ‘morality’.

In Taoist thought, the good life comes spontaneously; but spontaneity is far from simply acting on the impulses that occur to us. In Western traditions such as Romanticism, spontaneity is linked with subjectively. In Taoism it means acting dispassionately, on the basis of an objective view of the situation at hand. The common man cannot see things objectively, because his mind is clouded by anxiety about achieving his goals. Seeing clearly means not projecting our goals into the world; acting spontaneously means acting according to the needs of the situation. Western moralists will ask what is the purpose of such action, but for Taoists the good life has no purpose. It is like swimming in a whirlpool, responding to the currents as they come and go. ‘I enter with the inflow, and emerge with the outflow, follow the Way of the water, and do not impose my selfishness upon it. This is how I stay afloat in it,’ says the Chuang-Tzu.

In this view, ethics is simply a practical skill, like fishing or swimming. The core of ethics is not choice or conscious awareness, but the knack of knowing what to do. It is a skill that comes with practice and an empty mind. A.C. Graham explains:

The Taoist relaxes the body, calms the mind, loosens the grip of categories made habitual by naming, frees the current of thought for more fluid differentiations and assimilations, and instead of pondering choices lets the problems solve themselves as inclination spontaneously finds its own direction. …He does not have to make decisions based on standards of good and bad because, granted only that enlightenment is better than ignorance, it is self-evident that among spontaneous inclinations the one prevailing in the greatest clarity of mind, other things being equal, will be best, the one in accord with the Way.

Few humans beings have the knack of living well. Observing this, the Taoists looked to other animals as their guides to the good life. Animals in the wild know how to live, they do not need to think or choose. It is only when they are fettered by humans that they cease to live naturally.

As the Chuang-Tzu puts it, horses, when they live wild, eat grass and drink water; when they are content, they entwine their necks and rub each other. When angry, they turn their backs on each other and kick out. This is what horses know. But if harnessed together and lined up under constraints, they know how to look sideways and to arch their necks, to career around and try to spit out the bit and rid themselves of the reins.

For people in thrall to ‘morality’ , the good life means perpetual striving. For Taoists it means living effortlessly, according to our natures. The freest human being is not the one who acts on reasons he has chosen for himself, but one who never has to choose. Rather than agonising over alternatives, he responds effortlessly to situations as they arise. He lives not as he chooses but as he must. Such a human has the perfect freedom of a wild animal – or a machine. As the Lieh-Tzu says: ‘The highest man at rest is as though dead, in movement is like a machine. He knows neither why he is at rest nor why he is not, why he is in movement nor why he is not.’

The idea that freedom means becoming like a wild animal or machine is offensive to Western religious and humanist prejudices, but it is consistent with the most advanced scientific knowledge. A.C. Graham explains:

Taoism coincides with the scientific worldview at just those points where the latter most disturbs westerners rooted in the Christian tradition – the littleness of man in a vast universe; the inhuman Tao which all things follow, without purpose and indifferent to human needs; the transience of life, the impossibility of knowing what comes after death; unending change in which the possibility of progress is not even conceived; the relativity of values; a fatalism very close to determinism; even a suggestion that the human organism operates like a machine.

Autonomy means acting on reasons I have chosen; but the lesson of cognitive science is that there is no self to do the choosing. We are far more like machines and wild animals than we imagine. But we cannot attain the amoral selflessness of wild animals, or the choiceless automatism of machines. Perhaps we can learn to live more lightly, less burdened by morality. We cannot return to a purely spontaneous existence.

An experiment that uses pseudo-elements to create 84 simple GUI icons using CSS and semantic HTML. Shared as an exercise in creative problem solving and working within constraints. This is not a “production ready” CSS icon set.

Demo: Pure CSS GUI icons

Known support: Firefox 3.5+, Safari 5+, Chrome 5+, Opera 10.6+.

An exercise in constraint

Several months ago I was experimenting with the creation of common GUI icons with CSS. The HTML is very simple and it relies on CSS pseudo-elements rather than extraneous HTML elements. The technical aspects of this exercise might be of interest to others, so I’ve decided to share it.

Pseudo-elements provide many possibilities to developers interested in enhancing existing semantic HTML.

Example code

The technique behind this experiment is an expansion of the basic shape-creation that was used to make Pure CSS speech bubbles. Some of these GUI icons can only be created in browsers that support CSS3 transforms.

The HTML is a basic unordered list of links.

<ul>
  <li class="power"><a href="#non">Power</a></li>
  <li class="play"><a href="#non">Play</a></li>
  <li class="stop"><a href="#non">Stop</a></li>
  <li class="pause"><a href="#non">Pause</a></li>
</ul>

Each icon uses its own set of styles. For example, the key parts of the CSS responsible for the “expand” icon are as follows:

.expand a:before {
  content: "";
  position: absolute;
  top: 50%;
  left: 1px;
  width: 5px;
  height: 0;
  border-width: 7px 7px 0;
  border-style: solid;
  border-color: transparent #c55500;
  margin-top: -4px;
  /* css3 */
  -webkit-transform: rotate(-45deg);
  -moz-transform: rotate(-45deg);
  -o-transform: rotate(-45deg);
  transform: rotate(-45deg);
}

.expand a:after {
  content: "";
  position: absolute;
  top: 50%;
  left: 5px;
  width: 8px;
  height: 8px;
  border-width: 3px 0 0 3px;
  border-style: solid;
  border-color: #c55500;
  margin-top: -6px;
}

.expand a:hover:before,
.expand a:focus:before,
.expand a:active:before {
  border-color: transparent #730800;
}

.expand a:hover:after,
.expand a:focus:after,
.expand a:active:after {
  border-color: #730800;
}

The demo page contains a full set of user interaction and media player control icons, as well as other common icons. For now, several icons actually require more than one element as CSS 2.1 only specifies 2 pseudo-elements per element that can contain generated content. The CSS3 Generated and Replaced Content Module allows for an unlimited number of pseudo-elements but has yet to be fully implemented in any modern browser.

The clearfix hack is a popular way to contain floats without resorting to using presentational markup. This article presents an update to the clearfix method that further reduces the amount of CSS required.

Demo: Micro clearfix hack

Known support: Firefox 3.5+, Safari 4+, Chrome, Opera 9+, IE 6+

The “micro clearfix” method is suitable for modern browsers and builds upon Thierry Koblentz’s “clearfix reloaded”, which introduced the use of both the :before and :after pseudo-elements.

Here is the updated code (I’ve used a shorter class name too):

/**
 * For modern browsers
 * 1. The space content is one way to avoid an Opera bug when the
 *    contenteditable attribute is included anywhere else in the document.
 *    Otherwise it causes space to appear at the top and bottom of elements
 *    that are clearfixed.
 * 2. The use of `table` rather than `block` is only necessary if using
 *    `:before` to contain the top-margins of child elements.
 */
.cf:before,
.cf:after {
    content: " "; /* 1 */
    display: table; /* 2 */
}

.cf:after {
    clear: both;
}

/**
 * For IE 6/7 only
 * Include this rule to trigger hasLayout and contain floats.
 */
.cf {
    *zoom: 1;
}

This “micro clearfix” generates pseudo-elements and sets their display to table. This creates an anonymous table-cell and a new block formatting context that means the :before pseudo-element prevents top-margin collapse. The :after pseudo-element is used to clear the floats. As a result, there is no need to hide any generated content and the total amount of code needed is reduced.

Including the :before selector is not necessary to clear the floats, but it prevents top-margins from collapsing in modern browsers. This has two benefits:

• It ensures visual consistency with other float containment techniques that create a new block formatting context, e.g., overflow:hidden
• It ensures visual consistency with IE 6/7 when zoom:1 is applied.

N.B.: There are circumstances in which IE 6/7 will not contain the bottom margins of floats within a new block formatting context. Further details can be found here: Better float containment in IE using CSS expressions.

The use of content:" " (note the space in the content string) avoids an Opera bug that creates space around clearfixed elements if the contenteditable attribute is also present somewhere in the HTML. Thanks to Sergio Cerrutti for spotting this fix. An alternative fix is to use font:0/0 a.

Legacy Firefox

Firefox < 3.5 will benefit from using Thierry’s method with the addition of visibility:hidden to hide the inserted character. This is because legacy versions of Firefox need content:"." to avoid extra space appearing between the body and its first child element, in certain circumstances (e.g., jsfiddle.net/necolas/K538S/.)

Alternative float-containment methods that create a new block formatting context, such as applying overflow:hidden or display:inline-block to the container element, will also avoid this behaviour in legacy versions of Firefox.

The git-checkout command can be used to update specific files or directories in your working tree with those from another branch, without merging in the whole branch. This can be useful when working with several feature branches or using GitHub Pages to generate a static project site.

The git-checkout manual page describes how the git checkout command is not just useful for switching between branches.

When <paths> or --patch are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named <tree-ish> (most often a commit)…The <tree-ish> argument can be used to specify a specific tree-ish (i.e. commit, tag or tree) to update the index for the given paths before updating the working tree.

In git, a tree-ish is a way of referring to a particular commit or tree. This can be a partial sha or the branch, remote, and tag name pointers.

The syntax for using git checkout to update the working tree with files from a tree-ish is as follows:

git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>…

Therefore, to update the working tree with files or directories from another branch, you can use the branch name pointer in the git checkout command.

git checkout <branch_name> -- <paths>

As an example, this is how you could update your gh-pages branch on GitHub (used to generate a static site for your project) to include the latest changes made to a file that is on the master branch.

# On branch master
git checkout gh-pages
git checkout master -- myplugin.js
git commit -m "Update myplugin.js from master"

The need to update my gh-pages branch with specific files from my master branch was how I first found out about the other uses of the checkout command. It’s worth having a read of the rest of the git-checkout manual page and experimenting with the options.

What is the cascade?

The cascade is a mechanism for determining which styles should be applied to a given element, based on the rules that have cascaded down from various sources.

The cascade takes importance, origin, specificity, and source order of style rules into account. It assigns a weight to each rule. When multiple rules apply to a given element, the rule with the greatest weight takes precedence. The result is an unambiguous way to determine the value of a given element/property combination.

Browsers apply the following sorting logic:

• Find all declarations that apply to a given element/property combination, for the target media type.

• Sort declarations according to their importance (normal or important) and origin (author, user, or user agent). From highest to lowest precedence:

  1. user !important declarations
     
  2. author !important declarations
     
  3. author normal declarations
     
  4. user normal declarations
     
  5. user agent declarations

• If declarations have the same importance and source, sort them by selector specificity.

• Finally, if declarations have the same importance, source, and specificity, sort them by the order they are specified in the CSS. The last declaration wins.

What is specificity?

Specificity is a method of conflict resolution within the cascade.

Specificity is calculated in a very particular way, based on the values of 4 distinct categories. For explanatory purposes, the CSS2 spec represents these categories using the letters a, b, c, and d. Each has a value of 0 by default.

• a is equal to 1 if the declaration comes from a style attribute in the HTML (“inline styles”) rather than a CSS rule with a selector.
• b is equal to the number of ID attributes in a selector.
• c is equal to the number of other attributes and pseudo-classes in a selector.
• d is equal to the number of elements and pseudo-elements in a selector.

The specificity is given by concatenating all 4 resulting numbers. More specific selectors take precedence over less specific ones.

For example, the selector #id .class[href] element:hover contains:

• 1 ID (b is 1)
• 1 class, 1 attribute selector, and 1 pseudo-class (c is 3)
• 1 element (d is 1)

Therefore, it has a specificity of 0,1,3,1. Note that a selector containing a single ID (0,1,0,0) will have a higher specificity than one containing any number of other attributes or elements (e.g., 0,0,10,20). This is one of the reasons why many modern CSS architectural patterns avoid using IDs for styling purposes.

What is inheritance?

Inheritance is distinct from the cascade and involves the DOM tree.

Inheritance is the process by which elements inherit the the values of properties from their ancestors in the DOM tree. Some properties, e.g. color, are automatically inherited by the children of the element to which they are applied. Each property defines whether it will be automatically inherited.

The inherit value can be set for any property and will force a given element to inherit its parent element’s property value, even if the property is not normally inherited.

About !important

The above should make it apparent that !important is a separate concept to specificity. It has no effect on the specificity of a rule’s selector.

An !important declaration has a greater precedence than a normal declaration (see the previously mentioned cascade sorting logic), even declarations contained in an element’s style attribute.

[CSS terminology reference]

Translations

• CSS: каскад, специфика и наследование

A collection of thoughts, experiences, ideas that I like, and ideas that I have been experimenting with over the last year. It covers HTML semantics, components and approaches to front-end architecture, class naming patterns, and HTTP compression.

About semantics

Semantics is the study of the relationships between signs and symbols and what they represent. In linguistics, this is primarily the study of the meaning of signs (such as words, phrases, or sounds) in language. In the context of front-end web development, semantics are largely concerned with the agreed meaning of HTML elements, attributes, and attribute values (including extensions like Microdata). These agreed semantics, which are usually formalised in specifications, can be used to help programmes (and subsequently humans) better understand aspects of the information on a website. However, even after formalisation, the semantics of elements, attributes, and attribute values are subject to adaptation and co-option by developers. This can lead to subsequent modifications of the formally agreed semantics (and is an HTML design principle).

Distinguishing between different types of HTML semantics

The principle of writing “semantic HTML” is one of the foundations of modern, professional front-end development. Most semantics are related to aspects of the nature of the existing or expected content (e.g. h1 element, lang attribute, email value of the type attribute, Microdata).

However, not all semantics need to be content-derived. Class names cannot be “unsemantic”. Whatever names are being used: they have meaning, they have purpose. Class name semantics can be different to those of HTML elements. We can leverage the agreed “global” semantics of HTML elements, certain HTML attributes, Microdata, etc., without confusing their purpose with those of the “local” website/application-specific semantics that are usually contained in the values of attributes like the class attribute.

Despite the HTML5 specification section on classes repeating the assumed “best practice” that…

…authors are encouraged to use [class attribute] values that describe the nature of the content, rather than values that describe the desired presentation of the content.

…there is no inherent reason to do this. In fact, it’s often a hindrance when working on large websites or applications.

• Content-layer semantics are already served by HTML elements and other attributes.
• Class names impart little or no useful semantic information to machines or human visitors unless it is part of a small set of agreed upon (and machine readable) names – Microformats.
• The primary purpose of a class name is to be a hook for CSS and JavaScript. If you don’t need to add presentation and behaviour to your web documents, then you probably don’t need classes in your HTML.
• Class names should communicate useful information to developers. It’s helpful to understand what a specific class name is going to do when you read a DOM snippet, especially in multi-developer teams where front-enders won’t be the only people working with HTML components.

Take this very simple example:

<div class="news">
    <h2>News</h2>
    [news content]
</div>

The class name news doesn’t tell you anything that is not already obvious from the content. It gives you no information about the architectural structure of the component, and it cannot be used with content that isn’t “news”. Tying your class name semantics tightly to the nature of the content has already reduced the ability of your architecture to scale or be easily put to use by other developers.

Content-independent class names

An alternative is to derive class name semantics from repeating structural and functional patterns in a design. The most reusable components are those with class names that are independent of the content.

We shouldn’t be afraid of making the connections between layers clear and explicit rather than having class names rigidly reflect specific content. Doing this doesn’t make classes “unsemantic”, it just means that their semantics are not derived from the content. We shouldn’t be afraid to include additional HTML elements if they help create more robust, flexible, and reusable components. Doing so does not make the HTML “unsemantic”, it just means that you use elements beyond the bare minimum needed to markup the content.

Front-end architecture

The aim of a component/template/object-oriented architecture is to be able to develop a limited number of reusable components that can contain a range of different content types. The important thing for class name semantics in non-trivial applications is that they be driven by pragmatism and best serve their primary purpose – providing meaningful, flexible, and reusable presentational/behavioural hooks for developers to use.

Reusable and combinable components

Scalable HTML/CSS must, by and large, rely on classes within the HTML to allow for the creation of reusable components. A flexible and reusable component is one which neither relies on existing within a certain part of the DOM tree, nor requires the use of specific element types. It should be able to adapt to different containers and be easily themed. If necessary, extra HTML elements (beyond those needed just to markup the content) and can be used to make the component more robust. A good example is what Nicole Sullivan calls the media object.

Components that can be easily combined benefit from the avoidance of type selectors in favour of classes. The following example prevents the easy combination of the btn component with the uilist component. The problems are that the specificity of .btn is less than that of .uilist a (which will override any shared properties), and the uilist component requires anchors as child nodes.

.btn { /* styles */ }
.uilist { /* styles */ }
.uilist a { /* styles */ }

<nav class="uilist">
    <a href="#">Home</a>
    <a href="#">About</a>
    <a class="btn" href="#">Login</a>
</nav>

An approach that improves the ease with which you can combine other components with uilist is to use classes to style the child DOM elements. Although this helps to reduce the specificity of the rule, the main benefit is that it gives you the option to apply the structural styles to any type of child node.

.btn { /* styles */ }
.uilist { /* styles */ }
.uilist-item { /* styles */ }

<nav class="uilist">
    <a class="uilist-item" href="#">Home</a>
    <a class="uilist-item" href="#">About</a>
    <span class="uilist-item">
        <a class="btn" href="#">Login</a>
    </span>
</nav>

JavaScript-specific classes

Using some form of JavaScript-specific classes can help to reduce the risk that thematic or structural changes to components will break any JavaScript that is also applied. An approach that I’ve found helpful is to use certain classes only for JavaScript hooks – js-* – and not to hang any presentation off them.

<a href="/login" class="btn btn-primary js-login"></a>

This way, you can reduce the chance that changing the structure or theme of components will inadvertently affect any required JavaScript behaviour and complex functionality.

Component modifiers

Components often have variants with slightly different presentations from the base component, e.g., a different coloured background or border. There are two mains patterns used to create these component variants. I’m going to call them the “single-class” and “multi-class” patterns.

The “single-class” pattern

.btn, .btn-primary { /* button template styles */ }
.btn-primary { /* styles specific to save button */ }

<button class="btn">Default</button>
<button class="btn-primary">Login</button>

The “multi-class” pattern

.btn { /* button template styles */ }
.btn-primary { /* styles specific to primary button */ }

<button class="btn">Default</button>
<button class="btn btn-primary">Login</button>

If you use a pre-processor, you might use Sass’s @extend functionality to reduce some of the maintenance work involved in using the “single-class” pattern. However, even with the help of a pre-processor, my preference is to use the “multi-class” pattern and add modifier classes in the HTML.

I’ve found it to be a more scalable pattern. For example, take the base btn component and add a further 5 types of button and 3 additional sizes. Using a “multi-class” pattern you end up with 9 classes that can be mixed-and-matched. Using a “single-class” pattern you end up with 24 classes.

It is also easier to make contextual tweaks to a component, if absolutely necessary. You might want to make small adjustments to any btn that appears within another component.

/* "multi-class" adjustment */
.thing .btn { /* adjustments */ }

/* "single-class" adjustment */
.thing .btn,
.thing .btn-primary,
.thing .btn-danger,
.thing .btn-etc { /* adjustments */ }

A “multi-class” pattern means you only need a single intra-component selector to target any type of btn-styled element within the component. A “single-class” pattern would mean that you may have to account for any possible button type, and adjust the selector whenever a new button variant is created.

Structured class names

When creating components – and “themes” that build upon them – some classes are used as component boundaries, some are used as component modifiers, and others are used to associate a collection of DOM nodes into a larger abstract presentational component.

It’s hard to deduce the relationship between btn (component), btn-primary (modifier), btn-group (component), and btn-group-item (component sub-object) because the names don’t clearly surface the purpose of the class. There is no consistent pattern.

In early 2011, I started experimenting with naming patterns that help me to more quickly understand the presentational relationship between nodes in a DOM snippet, rather than trying to piece together the site’s architecture by switching back-and-forth between HTML, CSS, and JS files. The notation in the gist is primarily influenced by the BEM system‘s approach to naming, but adapted into a form that I found easier to scan.

Since I first wrote this post, several other teams and frameworks have adopted this approach. MontageJS modified the notation into a different style, which I prefer and currently use in the SUIT framework:

/* Utility */
.u-utilityName {}

/* Component */
.ComponentName {}

/* Component modifier */
.ComponentName--modifierName {}

/* Component descendant */
.ComponentName-descendant {}

/* Component descendant modifier */
.ComponentName-descendant--modifierName {}

/* Component state (scoped to component) */
.ComponentName.is-stateOfComponent {}

This is merely a naming pattern that I’m finding helpful at the moment. It could take any form. But the benefit lies in removing the ambiguity of class names that rely only on (single) hyphens, or underscores, or camel case.

A note on raw file size and HTTP compression

Related to any discussion about modular/scalable CSS is a concern about file size and “bloat”. Nicole Sullivan’s talks often mention the file size savings (as well as maintenance improvements) that companies like Facebook experienced when adopting this kind of approach. Further to that, I thought I’d share my anecdotes about the effects of HTTP compression on pre-processor output and the extensive use of HTML classes.

When Twitter Bootstrap first came out, I rewrote the compiled CSS to better reflect how I would author it by hand and to compare the file sizes. After minifying both files, the hand-crafted CSS was about 10% smaller than the pre-processor output. But when both files were also gzipped, the pre-processor output was about 5% smaller than the hand-crafted CSS.

This highlights how important it is to compare the size of files after HTTP compression, because minified file sizes do not tell the whole story. It suggests that experienced CSS developers using pre-processors don’t need to be overly concerned about a certain degree of repetition in the compiled CSS because it can lend itself well to smaller file sizes after HTTP compression. The benefits of more maintainable “CSS” code via pre-processors should trump concerns about the aesthetics or size of the raw and minified output CSS.

In another experiment, I removed every class attribute from a 60KB HTML file pulled from a live site (already made up of many reusable components). Doing this reduced the file size to 25KB. When the original and stripped files were gzipped, their sizes were 7.6KB and 6KB respectively – a difference of 1.6KB. The actual file size consequences of liberal class use are rarely going to be worth stressing over.

How I learned to stop worrying…

The experience of many skilled developers, over many years, has led to a shift in how large-scale website and applications are developed. Despite this, for individuals weaned on an ideology where “semantic HTML” means using content-derived class names (and even then, only as a last resort), it usually requires you to work on a large application before you can become acutely aware of the impractical nature of that approach. You have to be prepared to disgard old ideas, look at alternatives, and even revisit ways that you may have previously dismissed.

Once you start writing non-trivial websites and applications that you and others must not only maintain but actively iterate upon, you quickly realise that despite your best efforts, your code starts to get harder and harder to maintain. It’s well worth taking the time to explore the work of some people who have proposed their own approaches to tackling these problems: Nicole’s blog and Object Oriented CSS project, Jonathan Snook’s Scalable Modular Architecture CSS, and the Block Element Modifier method that Yandex have developed.

When you choose to author HTML and CSS in a way that seeks to reduce the amount of time you spend writing and editing CSS, it involves accepting that you must instead spend more time changing HTML classes on elements if you want to change their styles. This turns out to be fairly practical, both for front-end and back-end developers – anyone can rearrange pre-built “lego blocks”; it turns out that no one can perform CSS-alchemy.

This is how I am deploying the build of my static website to staging and production domains. It requires basic use of the CLI, Git, and SSH. But once you’re set up, a single command will build and deploy.

TL;DR: Push the static build to a remote, bare repository that has a detached working directory (on the same server). A post-receive hook checks out the files in the public directory.

Prerequisites

• A remote web server to host your site.
• SSH access to your remote server.
• Git installed on your remote server (check with git --version).
• Generate an SSH key if you need one.

On the server

Set up password-less SSH access

First, you need to SSH into your server, and provide the password if prompted.

ssh user@hostname

If there is no ~/.ssh directory in your user’s home directory, create one: mkdir ~/.ssh.

Next, you need to copy your public SSH key (see “Generate an SSH key” above) to the server. This allows you to connect via SSH without having to enter a password each time.

From your local machine – assuming your public key can be found at ~/.ssh/id_rsa.pub – enter the following command, with the correct user and hostname. It will append your public key to the authorized_keys file on the remote server.

ssh user@hostname 'cat >> ~/.ssh/authorized_keys' < ~/.ssh/id_rsa.pub

If you close the connection, and then attempt to establish SSH access, you should no longer be prompted for a password.

Create the remote directories

You need to have 2 directories for each domain you want to host. One for the Git repository, and one to contain the checked out build.

For example, if your domain were example.com and you also wanted a staging environment, you’d create these directories on the server:

mkdir ~/example.com ~/example.git

mkdir ~/staging.example.com ~/staging.example.git

Initialize the bare Git repository

Create a bare Git repository on the server. This is where you will push the build assets to, from your local machine. But you don’t want the files served here, which is why it’s a bare repository.

cd ~/example.git
git init --bare

Repeat this step for the staging domain, if you want.

Write a post-receive hook

A post-receive hook allows you to run commands after the Git repository has received commits. In this case, you can use it to change Git’s working directory from example.git to example.com, and check out a copy of the build into the example.com directory.

The location of the working directory can be set on a per-command basis using GIT_WORK_TREE, one of Git’s environment variables, or the --work-tree option.

cat > hooks/post-receive
#!/bin/sh
WEB_DIR=/path/to/example.com

# remove any untracked files and directories
git --work-tree=${WEB_DIR} clean -fd

# force checkout of the latest deploy
git --work-tree=${WEB_DIR} checkout --force

Make sure the file permissions on the hook are correct.

chmod +x hooks/post-receive

If you need to exclude some files from being cleaned out by Git (e.g., a .htpasswd file), you can do that using the --exclude option. This requires Git 1.7.3 or above to be installed on your server.

git --work-tree=${WEB_DIR} clean -fd --exclude=<pattern>

Repeat this step for the staging domain, if you want.

On your local machine

Now that the server configuration is complete, you want to deploy the build assets (not the source code) for the static site.

The build and deploy tasks

I’m using a Makefile, but use whatever you feel comfortable with. What follows is the basic workflow I wanted to automate.

1. Build the production version of the static site.

   make build
   

2. Initialize a new Git repo in the build directory. I don’t want to try and merge the new build into previous deploys, especially for the staging domain.

   git init ./build
   

3. Add the remote to use for the deploy.

   cd ./build
   git remote add origin ssh://user@hostname/~/example.git
   

4. Commit everything in the build repo.

   cd ./build
   git add -A
   git commit -m "Release"
   

5. Force-replace the remote master branch, creating it if missing.

   cd ./build
   git push -f origin +master:refs/heads/master
   

6. Tag the checked-out commit SHA in the source repo, so I can see which SHA’s were last deployed.

   git tag -f production
   

Using a Makefile:

BUILD_DIR := ./build
STAGING_REPO = ssh://user@hostname/~/staging.example.git
PROD_REPO = ssh://user@hostname/~/example.git

install:
    npm install

# Deploy tasks

staging: build git-staging deploy
    @ git tag -f staging
    @ echo "Staging deploy complete"

prod: build git-prod deploy
    @ git tag -f production
    @ echo "Production deploy complete"

# Build tasks

build: clean
    # whatever your build step is

# Sub-tasks

clean:
    @ rm -rf $(BUILD_DIR)

git-prod:
    @ cd $(BUILD_DIR) && 
    git init && 
    git remote add origin $(PROD_REPO)

git-staging:
    @ cd $(BUILD_DIR) && 
    git init && 
    git remote add origin $(STAGING_REPO)

deploy:
    @ cd $(BUILD_DIR) && 
    git add -A && 
    git commit -m "Release" && 
    git push -f origin +master:refs/heads/master

.PHONY: install build clean deploy git-prod git-staging prod staging

To deploy to staging:

make staging

To deploy to production:

make prod

Using Make, it’s a little bit more hairy than usual to force push to master, because the cd commands take place in a sub-process. You have to make sure subsequent commands are on the same line. For example, the deploy task would force push to your source code’s remote master branch if you failed to join the commands with && or ;!

I push my site’s source code to a private repository on BitBucket. One of the nice things about BitBucket is that it gives you the option to prevent deletions or history re-writes of branches.

If you have any suggested improvements, let me know on Twitter.

Using SVG is currently the best way to create icon libraries for apps. Icons built with SVG are scalable and adjustable, but also discrete, which allows them to be incrementally loaded and updated. In contrast, icons built as fonts cannot be incrementally loaded or updated. This alone makes SVG icons the better choice for high-performance apps that rely on code-splitting and incremental deploys.

This post describes how to make a package of React components from a library of SVG icons. Although I’m focusing on React, making any other type of package is also possible. At Twitter I used the approach described here to publish the company’s SVG icon library in several different formats: optimized SVGs, plain JavaScript modules, React DOM components, and React Native components.

Using the icons

The end result is a JavaScript package that can be installed and used like any other JavaScript package.

yarnpkg add @acme/react-icons

Each icon is available as an individually exported React component.

import IconCamera from '@acme/react-icons/camera';

This allows your module bundler to package only the icons that are needed, and icons can be efficiently split across chunks when using code-splitting. This is a significant advantage over icon libraries that require fonts and bundle all icons into a single component.

// entire icon library is bundled with your app
import Icon from '@acme/react-icons';
const IconCamera = <Icon name='camera' />;

Each icon is straightforward to customize (e.g., color and dimensions) on a per-use basis.

import IconCamera from '@twitter/react-icons/camera';
const Icon = (
  <IconCamera
    style={{ color: 'white', height: '2em' }}
  />
);

Although the icons render to SVG, this is an implementation detail that isn’t exposed to users of the components.

Creating components

Each React component renders an inline SVG, using path and dimensions data extracted from the SVG source files. A helper function called createIconComponent means that only a few lines of boilerplate are needed to create a component from SVG data.

import createIconComponent from './utils/createIconComponent';
import React from 'react';
const IconCamera = createIconComponent({
  content: <g><path d='...'></g>,
  height: 24,
  width: 24
});
IconCamera.displayName = 'IconCamera';
export default IconCamera;

This is an example of what the createIconComponent function looks like when building components for a web app like Twitter Lite, which is built with React Native for Web.

// createIconComponent.js
import { createElement, StyleSheet } from 'react-native-web';
import React from 'react';

const createIconComponent = ({ content, height, width }) =>
  (initialProps) => {
    const props = {
      ...initialProps,
      style: StyleSheet.compose(styles.root, initialProps.style),
      viewBox: `0 0 ${width} ${height}`
    };

    return createElement('svg', props, content);
  };

const styles = StyleSheet.create({
  root: {
    display: 'inline-block',
    fill: 'currentcolor',
    height: '1.25em',
    maxWidth: '100%',
    position: 'relative',
    userSelect: 'none',
    textAlignVertical: 'text-bottom'
  }
});

Setting the fill style to currentcolor allows you to control the color of the SVG using the color style property instead.

All that’s left is to use scripts to process the SVGs and generate each React component.

Creating icon packages

A complete example of one way to do this can be found in the icon-builder-example repository on GitHub.

The project structure of the example tool looks like this.

.
├── README.md
├── package.json
├── scripts/
    ├── build.js
    ├── createReactPackage.js
    └── svgOptimize.js
└── src/
    ├── alerts.svg
    ├── camera.svg
    ├── circle.svg
    └── ...

The build script uses SVGO to optimize the SVGs, extract SVG path data, and extract metadata. The example packager for React then uses templates to create a package.json and the React icon components shown earlier.

import createIconComponent from './utils/createIconComponent';
import React from 'react';
const ${componentName} = createIconComponent({
  height: ${height},
  width: ${width},
  content: <g>${paths}</g>
});
${componentName}.displayName = '${componentName}';
export default ${componentName};

Additional packagers can be included to build other package types from the same SVG source. When the underlying icon library changes, it only takes a couple of commands to rebuild hundreds of icons and publish new versions of each package.

The industrial hub faces a massive shortfall in revenues amid growing cost of combating the pandemic

The previous night, they had called up relatives in Madhya Pradesh to say they were in a helpless state

1,300 students of the varsity leave for home by special train

A special National Investigation Agency (NIA) court on Friday extended the judicial custody of academician Dr. Anand Teltumbde, arrested on April 14 i

Court wants decision on levying costs for transport of migrant workers

He is wanted for murder, attempt to murder and smuggling of weapons and drugs