Notes on Codecademy “Learn CSS: Variables and Functions”

Following responsive design in Codecademy’s CSS curriculum is “Learn CSS: Variables and Functions“. I was intrigued by the title of this course, as “variables” and “functions” were features unexpected in a visual appearance style description syntax. I associate them with programming languages! Does their presence mean CSS has evolved to become a programming language in its own right? After this class, I now know the answer is a definite “no”.

First of all, CSS “variables” are far less capable than their programming language counterparts. The name isn’t even really accurate, as a value does not vary (hence not variable) after it is set. A value declared by one CSS rule can be overridden by a more specific CSS rule declaring something with the same name, but that’s more analogous to variable scope than actually varying its value. This mechanism is also known as CSS custom properties, and I think that is a much more accurate name than “variable” which oversells its capabilities.

That said, CSS custom properties have their uses. This course showed several cases where custom properties can be overridden by CSS rules to good effect. The first example I found very powerful is combining custom properties and media queries. It makes for a far cleaner and more maintainable way to adjust a stylesheet based on screen size changes. The second significant example is in the exercise project, where we could create multiple themes on a web page (Light Mode/Dark Mode/Custom Mode) using custom properties.

Moving on to “CSS functions”, I was disappointed to learn that we’re talking about a fixed set of data processing/calculation functions implemented by the runtime environment. We can’t actually declare our own functions in CSS. CSS functions are nowhere as powerful as C++ functions. They’re not even as powerful as Microsoft Excel functions, as CSS style sheets are not spreadsheets.

Like almost every standard associated with HTML, we see a specification that tried to rationalize a lot of ad-hoc evolution and failing to hide all of the seams. The one inconsistency that annoys me is the fact some function parameters must be separated by commas, and other functions require parameters to be separated by spaces. It is especially jarring when the two styles are used together, as in this example used in the course:

filter: drop-shadow(10px 5px 0.2rem rgba(236, 217, 203, 0.7));

The drop-shadow() parameters are separated by spaces, while the rgba() parameters are separated by commas. What a mess! How can we be expected to keep this straight? Still, these functions should suffice to cover most of the intelligence we’d want to put in a style sheet. I was most impressed that calc() tries to handle so much, including the capability to mix and match CSS units. I know the intent is to allow things like subtracting a pixel count from a percentage of width, but I see a debugging nightmare. The course covered only a subset of the set of functions, but of those that were covered my favorite is clamp(). I expect to use that a lot.

One unanswered mystery is the class recommends that we set global custom properties using :root pseudo-class as the specifier. The instruction said this is usually the <html> tag, without explaining exceptions to that rule. When is :root not <html>? The MDN documentation unfortunately doesn’t answer that question either. I’ll have to leave it as a mystery as I proceed to learn about web accessibility.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s