Introduction

Welcome to Active CSS!

 

It is a no-brainer to use CSS where you can, instead of JavaScript. There are a few exceptions, but on the whole that is a true statement.

Up until now, CSS has been a tool for adding styling properties to objects on the web page, and a little bit of animation. But that's about it. It does a lot in this direction, but it has effectively only existed as the simplest and easiest method to add styling properties to the browser objects, using minimal syntax (try styling just by using JavaScript - it is a very long-winded method).

Historically, in GUI OO languages like Visual Basic, the ability to add methods (or functions) to objects has also been a vital tool in creating UI components and for interactivity. We do this currently in JavaScript by adding event listeners that respond to user or browser-driven events. We currently don't employ the capabilities of CSS syntax to add methods to HTML objects. In theory though, it might be possible. How?

In JavaScript we use "document.querySelector('#myDiv')", but  in CSS we can go straight to "#myDiv {...".

Hmm... so do we really need so much additional coding, for basic interactivity? We don't need special coding for CSS ":hover" and that is a CSS event. Is there a quicker way to add an actual DOM event listener just by utilising the shorter CSS syntax? And then what - what would the syntax look like after that, when we actually want to do things in the event listener?

For that matter, what if common JavaScript functionality for building websites with interactivity was taken over fully by CSS, what would it look like?

Well, this is the goal of Active CSS - to see how far CSS syntax can be pushed in taking over common JavaScript functionality, to encourage simpler coding.

CSS is mostly easy to read, with the exception of some of the more modern and complex commands. Even non-programmers can understand a lot of the commands when they read it. When the CSS commands are one-liners, there is a lot less going on to worry about in comparison to a function or class-based programming language.

A bonus is that CSS focuses your attention directly on the web page itself and doesn't let you meander in programming issues. You don't have to call up an API command just to attach a style (ie. getElementById, etc.). You just type in the selector and away you go. CSS is very direct in applying styling instructions to the web page.

Also, it is easy to customize CSS. You can copy/paste some code from codepen or CSS-tricks and tailor it for your needs. This is arguably easier than trying to tweak or extend a function-based plugin.

Things only get difficult, these days, when the CSS points system ("specificity") is involved (you don't know what that is exactly? You are not alone!). Actually, the CSS points system doesn't exist in ACSS, because it isn't necessary when you are writing events for specific elements.

So how do you make CSS into a fully-fledged programming language?

Any additions to CSS syntax would need to stay compatible with existing CSS syntax, for a start.

Keeping that in mind for all upgrades, the first upgrade is to allow CSS to use all the browser events. The only event in CSS is the "hover" event. That isn't enough for interactivity. We need to at least allow for the "click" event. So let's add ":click", ":mouseover", etc. - all the browser events - following the existing syntax of ":hover".

Next is to add a target selector under the event, so if we click on something we can make something happen somewhere else. All actions on a web page are event-based and make things happen, so in theory this should be a very useful thing to have.

Next, create a bunch of higher-level commands to cater for common webpage actions, like "add-class", "remove-class" - commands like that that can directly manipulate the objects on the page - the elements (HTML tags) on the page.

Ok - so what would that look like following the basic principles of CSS syntax? Let's work out what would be the simplest way to have a button click that adds a class of "buttonHasBeenClicked" to the body tag using CSS syntax using a "target selector" underneath the "event selector":

button:click {
    body {
        add-class: .buttonHasBeenClicked;
    }
}

That appears to be a sensible way to do this. You have the "event selector" at the top, which uses the click event itself (with the same syntax as :hover), and then inside that we place a "target selector" - the element that we want to change when the click event happens. That event can just sit there waiting for something to happen, just like CSS. It needs a little shift in developer viewpoint to fully understand this, but it is essentially a simple concept. Regular CSS syntax applies for selectors, and all the native event bubbling rules for elements are still relevant, and there is a bonus in that you don't have to worry about managing event listeners. It just sits there waiting to fire, whether the element is on the page or is rendered on the page later on.

Just this concept alone would be a major enhancement for CSS if it was ever introduced into the browser. It would be massive news. It opens up huge possibilites for CSS.

Suddenly we can add events to classes of elements without looping through element sets. We no longer have to worry about redeclaring events when elements come and go from the page. Events just sit there in the ACSS config, waiting to happen, looking like CSS.

Then add some control flow, like @if statements, and set up variable handling to use raw JS - there's a great functional language sitting right there which can be used already.

Let's also integrate some tooling for making single-page applications based only on the front-end state and while we're at it let's try and get a simpler front-end web components solution too. We currently use frameworks to handle a lot of this stuff. Could an enhanced CSS syntax also handle that?

Most importantly the whole thing needs to work with native browser functionality so that when improvements are made to the browser everything still works. So web components need to work with regular shadow DOMs and we also cannot have a virtual DOM as that bypasses the inbuilt browser functionality. The DOM is already stored in memory - let's work with that and make targeted DOM updates utilising the reactive variable method.

But wait, there is one more thing. Programmers like to program commands to run one after another, in sequence. CSS commands are static. CSS commands are not designed to run in a particular sequence. Let's make a change here, just for Active CSS declarations. Let's make all the commands run sequentially as they appear.

And voila! We have successfully turned CSS into a proper event-driven language designed specifically for browsers!

Are there performance implications in implementing this natively in the browser? It would be much quicker if natively in the browser, but there may be performance hits that dissuade browser makers to implement functionality. In reality, ACSS is ultra-fast even when written on top of JavaScript, compared to regular frameworks. And UI is something that developers need to do, regardless of performance. It should be up to the developer to decide if performance is fast enough for practical use. If we coded up the core of Active CSS just by using JavaScript, and in real terms it does seem to be "fast enough", then there are no excuses for it not being able to be done natively. It's not an easy problem to solve. The good news is that we've already done a lot of the groundwork for this, and it can only be improved upon.

Once ACSS has evolved more then a formal specification may be started up for W3C use. It may even happen in our lifetime. That depends on you.

The good news is that ACSS can be used right now on real websites in a cross-browser way and is future-compatible, so that even if functionality does get implemented in the browser natively Active CSS should continue to work with your config predictably. It is a completely separate written language to CSS and not connected to the CSS rendering engine directly in any way. Essentially, if the command is found in Active CSS then it runs it there, otherwise it will try and run it as a regular CSS command.

Contribute ideas via github if you want to get involved.

You don't have to be a Level 7 programmer to help. You don't need to know JavaScript very well. We actually need more brave souls to try out ACSS on real-world projects and report any bugs, so that they can be fixed. If you are creative, and want to build some of the best websites in the world, it would be awesome if you could give it a try and give us some feedback.

If you find it useful, give us a star on Github so we know you like it.

What are you waiting for?! Read the rest of the docs!