There are no tracking or monitoring cookies on this site. There are only cookies used for documentation examples related to cookies.
Close

Processing...
This may take a few seconds.

Introduction

Welcome to Active CSS!

 

It's a no-brainer to use CSS where you can, instead of JavaScript.

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 objects, using minimal syntax (try styling just by using JavaScript - it's 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 it for ":hover" - that's a CSS event. Is there a quicker way to add an actual DOM event listener just by utlising 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 didn't know what that was either? You are not alone!). Actually, the CSS points system doesn't exist in this experimental branch of CSS, because you don't need a points system for a programming language.

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.

With that in mind, 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 of event listener handling being done automatically in the background.

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

Now we don't want any rules being overwritten or anything like that here. CSS only applies one style rule at a time and there can be a lot of mucking about trying to get a style to work sometimes. Every piece of code written in an event-driven programming language must be applicable, otherwise it's going to be unnecessarily complex. So let's remove the points system of static CSS to make coding a bit easier and make every command count.

And for now we should probably also allow some inline JavaScript for those times when CSS isn't enough on it's own.

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.

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 if they appear in action declarations.

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? Of course! But UI is something that developers need to do, regardless of performance. Ultimately, performance will be quicker if written natively in the browser, rather than the developer doing it in JavaScript. It can then 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 by smarter people.

Everything documented on this site works in the test cases that it has been used on. It does need more testing, as only a few people are actively working with it, but results are looking good so far. There are a lot of features currently in ACSS that would be great if introduced right now into the wild, in the browser itself. Some others need further refinement.

Once it has evolved more then a formal specification will be started up for the W3C. Only when no further syntax changes are deemed necessary and the language has remained stable for a long while can it be even considered for incorporating into the browser. It is very unwise and practically impossible to make breaking syntax changes to a language once it hits the browser, as once thousands of people have used a particular syntax, changing it will break their websites. So it is important to get it right. That is the main reason it takes so long for changes to be made to CSS and JavaScript. Functionality can be added to the browser, but it is rare that anything is ever taken away. Hence this working prototype is designed to speed the process up a bit and provide a full solution, rather than having a massive written spec which is harder to visualize. Actual working syntax can then be analyzed and tweaked in the prototype before implementation into the browser.

The good news is that the prototype can be used 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 via github if you want to get involved! Help is needed in the area of testing and suggestions if you get a great idea or if you think something can be done in a better or easier way.

(PS. If you think Active CSS is a cool idea, please consider giving it a star on github. It gives encouragement, gives the project more credibility, and lets us know people are interested. Thank you!)