What if CSS was imperative?

Many developers (especially back-end developers) often dismiss web development in general (and CSS in particular) as a lesser branch of software development. I find interesting that the people that diminish it as something easy or simple are often the same people that make comments such as, "CSS is too difficult."

How can something be too easy and too difficult at the same time?

And we see it every day in web programming. New tools are created to get rid of CSS's difficulty/complexity, and those tools end up adding new layers of complexity (although maybe not in the eyes of the user.)

There are many reasons why this mismatch with CSS could happen: misconception, threat response, lack of interest, lack of understanding...

This last reason came as a realistic possibility: maybe people that are used to a more imperative language syntax have issues understanding a different type or approach to programming.

This is a declarative approach with some CSS code to add color to a post and to show/hide an element when an action (mouse over) is performed by the user:

#post {
  color: blue;
}

.socialLink {
  display: none;
}

#post:hover .socialLink {
  display: block;
}

Imagine that you could get the same code written in a more imperative way. Say something like the pseudo-JavaScript-ish code below. It has the same number of lines, but it is quite more verbose:

if (this.id === "post") {
  this.color("blue");
}

if (this.className === "socialLink") {
  this.hide();
  if (this.parent().id === "post") {
    this.parent()
        .addEvent("mouseover", function() { this.show(); });
        .addEvent("mouseout",  function() { this.hide(); });
  }
}

Ignoring performance/syntax of this pseudo-language, would you consider this more imperative approach easier?

Comments

[@nobody]

interesting solution to the data v code issue with CSS.

I might suggest a LISP-lists approach since StyleSheets follow the same schema as XML or LISP.
Clojure for example

(ns imperativeStyles.example
  (:require [imprtve.styls :refer [id? class? hide show addEvents color]])

(def stlyes
  `(id? 'post'
    (color :blue))

   (class? 'socialLink' 
    (hide 
     (id? [:parent] 'post'
      (addEvents { :mouseover (show) 
                           :mouseout (hide) }))`

[Isaac Hagoel]

I think css is hard to master because:

1. There is a lot of it (a lot of attributes, selectors etc)
2. Non locality: there are a lot of explicit and implicit relationships potentially between seemingly unrelated parts of the page

[Alvaro Montoro]

I think point 1 should not count. JavaScript (or any language for that matter) has a ton of classes and properties, they are just distributed differently.

Point 2 is a good one. With the cascading and the value inheritance, it is not obvious what some things are going to do. CSS has specs for nested rules (a la Sass/Less) which could help with that, but they are not supported yet.

[Cory Tanner]

From my experience the lack of interest/understanding of CSS comes from developer convenience. How many JS developers are on a dev team compared to CSS devs? 9 times out of 10 you will be lucky to find a CSS developer.

As a result the JS developers will want to write solutions in a language that is fluent to them. Resulting in lazy CSS solutions, CSS solutions that fill the lack of knowledge (CSS in JS). But 9 times out of 10 these CSS solutions are taxing the user in favor of developer convenience. As a whole I hope web developers can go back to a HTML/CSS first approach. If you can't build something with HTML/CSS then you introduce JS, not JS for everything.

[Alvaro Montoro]

I couldn't agree more.

Cory Tanner 2020!

[Cory Tanner]

haha thank you. My first order when in office will be to have every developer look up a packages weight via bundlephobia.com/ before they add it into their project. Then justify the weight of the package. :)

[Alvaro Montoro]

I wrote this post in May last year... and just realized I never hit the publish button :S

[Mihail Malo]

Things that are easy about CSS:

• Overall grammar/syntax
• Selectors (pseudo, combinators, whatever)
• Variables
• "Media Queries" (Jesus, what a name)

Things that are hard about CSS:

• Specificity
• ::before &::after (content?)
• margin vs padding
• Box model (particularly that old box model is the default and you have to opt out)
• Syntax of individual properties (eg: how do I apply transition with a given time and function, but to two properties? Oh, it's just a shorthand? Oh, if I then write out just the "transition-property" it will overwrite?)
• Specificity
• All these properties, and they're not even namespaced. How do I know justify-content, align-items and align-content are about flexbox? (ok, they're also in grid now)
• Specificity !important

I avoided most of these by gratuitous RTFM, having the luxury not to use CSS frameworks, and having the luxury to use component frameworks that namespace classes, but I still have to admit that CSS is hard. With editor tooltips and everything, it still requires a lot of reading.

The only thing I'd be interested in being "imperative" at any point would be sizing using a constraint solver. flex and grid are great, but min-width: calc($(:prev).width + 1vw) could be just as fast :v

calc is frustratingly limited, too.

html{
    font-size: 8rem;
}
@media screen and (min-width: 800px){
  html{
    font-size: calc(8rem + (9rem-8rem) * (100vw - 800px) / (1100px - 800px));
  }
}
@media screen and (min-width: 1100px){
  html{
    font-size: 9rem;
  }
}

I know this should make the font go from 8 to 9 rem as vw goes from 800 to 1000 px.
You know it.
Why can't calc understand that <length>/<length> is <number>? No one knows.
Oh well, time to insert some magic numbers instead.

[Saurabh Sharma]

It depends on how much imperative you want to get.

For ex: maybe you want to control colors to the lowest level, then you might have to write different code for different kinds of displays (LCD, LED, CRT, TFT). Let's just not hope you also have to write the driver for the display 🙈

Will it be productive? no way.