What I Learned Today 💡 May 27, 2017

The CSS Standardization Process

My recent posts have been about git and Unix stuff. I love DevOps/sysadmin/tooling and whatnot, but I want to discuss web development stuff much more.

In particular, I want to tackle CSS.

I don’t know CSS as well as I’d like to. I love web development, both the technologies and the communities surrounding it. I want to improve at it. Therefore, I must master CSS, one of the core web technologies (along with HTML and JavaScript, of course).

Specifically, I would like to attain a razor-sharp, pedantic understanding of CSS. Not so that I would be a pedant, because nobody likes a pedant. Rather, so that I could be a pedant if necessary.

My experience with CSS has been shallow at best. My learnings have been bite-sized pieces from blog posts and videos. This has allowed me to hobble along, hacking together CSS as needed. But it’s always left me feeling dirty, because I don’t really understand why my CSS is working.

No more.

It’s time I start learning CSS for real. The entire thing — not just fragments of working knowledge.

I will start my CSS discussions with The CSS Standardization Process, the “birthplace” of CSS.

Standards and Implementations

There are 2 kinds of CSS: CSS — The Standard and CSS — The Implementation.

This is a key distinction. What’s described in the CSS specifications is not necessarily what’s implemented in rendering engines.

In the past, “certain browsers” were not so keen on following the specifications. Of course, I am talking about Internet Explorer.

But in the modern era among evergreen web browsers, the specifications do match the implementations for the most part.

Therefore, reading the specifications is of great practical use.

The Original Plan

CSS was meant to be a temporary stand-in. It was not meant to last.

HTML was first released in 1993. Upon release, the W3C (an authority on web technologies) had noticed/encouraged the manipulation of HTML for aesthetic purposes. For example, the <font> tag and display: table layouts.

Soon after, they decided that HTML should focus exclusively on the content of a document — not its appearance.

So in 1994–1995, the W3C planned to create a single CSS specification to address the manipulation of a document’s appearance.

This monolithic CSS specification was of comparable size to the sum of current CSS level 1 and CSS level 2, with a few exceptions (e.g. no absolute positioning)

This CSS specification was intended to be temporary — lasting only ~10 years. The plan was that the W3C would use the experience, feedback, and wisdom gained during these 10 years to create a better, permanent solution to the document-appearance problem.

What Went Wrong

2 things went wrong with this plan.

  1. The monolithic CSS specification was too complex for browser vendors to fully implement at-the-time. In response to this, the monolithic specification was refactored into two sub-specifications: CSS Level 1 and CSS Level 2. CSS Level 1 was released first — in 1996. Browser vendors then implemented this first-half of the original monolithic specification. CSS Level 2 was released later — in 1998. Browser vendors then implemented this second-half of the original monolithic specification.
  2. People ended up liking CSS so much that they didn’t want to replace it, but extend it.

A New Approach: Modules and Snapshots

After CSS Levels 1 and 2 had been specified, the W3C utilized a different approach to extending standard CSS.

Instead of writing single, monolithic specifications encompassing all new CSS features/revisions, new CSS is specified in Modules.

A module encompasses a specific feature. For example, flexbox is specified by the CSS Flexible Box Layout Module. These modules have levels, like the non-modular specifications CSS Level 1 and CSS Level 2. The CSS Flexible Box Layout Module is currently at Level 1, hence its full name is CSS Flexible Box Layout Module Level 1.

In addition to modules, occasional snapshots are published. Snapshots are wholesome documents that describe the current, entire state of standard CSS. In terms of the modules they include, they only contain modules that the W3C CSS Working Group consider to be stable.

The latest snapshot was published on January 31st, 2017.

You can basically think of these snapshots as CSS State of the Union Addresses.

Document Statuses

The terms Module and Snapshot are relative to the W3C’s CSS Working Group(s). As they say on their website, other working groups may use these terms differently.

But all working groups of the W3C use the same terminology to describe the statuses of specifications. These terms are both the spec-statuses and the names of the corresponding reports:

  • Working Draft (WD): WDs are published by the responsible working group during the drafting of the given specification. They are published to elicit feedback from the rest of the W3C and the public. Specifications at this stage are generally unstable and incomplete.
  • Last Call Working Draft (LC or LCWD): LCWDs are published when the responsible working group considers the given specification complete and error-free. The publication of a LCWD signals that the given specification will move-on to the next stage (Candidate Recommendation) unless a significant issue arises. This is essentially a “last-call” for the W3C and the public to provide feedback before the publication moves on to Candidate Recommendation.
  • Candidate Recommendation (CR): CRs are published by the responsible working group when all known issues for the spec are resolved. At this stage, they are asking someone to actually implement the spec to see how it goes. As the name implies, specifications at this stage are only potential candidates for Recommendation (the final frontier)
  • Proposed Recommendation (PR): PRs are published by the responsible working group when the given spec’s functionality has a comprehensive test suite and that all specified functionality is successfully implemented in at least 2 production implementations.
    W3C members are asked to review the spec 1 last time.
  • Recommendation (REC): RECs are published by the responsible working group when everything’s good-to-go. In other words, the specification is complete, stable, implemented, and well-tested.
    It is a standard.

Some examples:

  • Flexbox (CSS Flexible Box Layout Module Level 1) is currently at the Candidate Recommendation (CR) stage.
  • CSS Selectors Level 3 is currently at the Recommendation (REC) stage.
  • CSS Selectors Level 4 is currently at the Working Draft (WD) stage.
  • Media Queries Level 3 is currently at the Recommendation (REC) stage.
  • Media Queries Level 4 is currently at the Working Draft (WD) stage.

I couldn’t find any specifications @ the Last Call Working Draft stage or the Proposed Recommendation stage.

Final Note

Many specifications do not progress linearly from WD to REC. Typically, many reach CR, only to reveal major issues that would need an entire redraft of the spec. Thus, they are pushed back to WD, then re-enter CR. Upon 2nd entry into CR, many specs progress linearly from there.

Some die out entirely in the process.

Source: https://www.w3.org/Style/2011/CSS-process

Opinions expressed in these articles do not reflect those of my employer.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.