[Proposal] Expand CSS syntax so it handles DOM manipulation

Hey there,

By introducing the concept of a target selector into CSS syntax, and by adding some higher-level one-liner commands to handle common JavaScript functionality, full DOM manipulation for interactivity becomes possible with CSS alone.

This could potentially fill the need for a higher-level alternative and companion for JavaScript amongst developers, without changing the existing development structure of the internet.

This would be an addition branch to CSS, rather than changing any current styling-oriented direction of CSS. A branch for the syntax itself.

I humbly present a working prototype that I’ve spent the last couple of years on:

https://activecss.org

I would love to know what you guys think. Personally I love it - for me it’s a very intuitive way to code. I hope that it might spark some ideas at least.

Rob Galbraith, Software designer, River Zend Dynamics Ltd.

3 Likes

This is interesting. Can you describe how it is better than custom elements in JS (f.e. with respect to the tic-tac-toe example)? It’d be nice to see a comparison of the two approaches and how using activeCSS improves the experence.

First, thanks for checking it out! It is a different way of coding for sure, so I think a walkthrough comparison would be a good thing, especially for web components, as you suggest. What I’ll do is set up a page on the website that compares the two approaches step by step, something like that.

I will say here though, the main DX improvement though is the intuitivity of coding. I’ll do a comparison with CSS.

With CSS, you don’t have to think particularly to assign a style - you just write it, you know? CSS is very quick and intuitive once you know your selectors, commands and the hierachical rules. CSS is generally pleasant to code in. Fun even!

An analogy, would be to imagine a world in which if CSS didn’t exist and you had to write all your styling and cascading in JavaScript. It would take ages to write, would get messy in the scripts pretty quickly, and this ultimately would put people off from native styling. Imagine tweaking that code - nightmare! So you’d do the minimum or use a CSS framework that someone else had done and leave it at that. You wouldn’t bother with tweaking CSS so much, as it wouldn’t be productive and not best practice to “reinvent the wheel” on styles, etc. etc. Everyone would use something like bootstrap, and CSS styling would be left to the CSS framework developers, “who knew what they were doing”. Or a lot of websites would look like old windows programs, with the default grey styles assigned to objects.

CSS solves the styling complexity by providing a direct way to assign a property to an element, and provides sufficient styling properties to handle all the common requirements necessary to style elements and make things look nice. CSS syntax looks a bit weird - it doesn’t look like regular code - but it surprisingly is very good at what it does. It abstracts out the JavaScript styling API, so you can style in a very quick and direct way. There is no more direct way to style an element - it gets the job done very quickly.

CSS makes things a lot quicker. CSS wins every time - no argument. No one is out there trying to reinvent CSS.

Currently, we have a similar situation with DOM manipulation. Anything too complex is left to the plugin or framework developers, and best practices become “use a framework” and “don’t reinvent the wheel”. Right now, you’d need some sort of recent CS degree to keep up with progress in UI frameworks. We have the same symptoms in the community that would exist for styling if CSS did not exist.

For what? Adding and removing elements? Changing styles and properties? Updating content in an element? It shouldn’t be rocket-science.

The thing is, these current over-engineering symptoms only really exist because doing complex interactivity yourself on a webpage is currently a lengthy process, and practically it’s not worth doing it without some plugin or framework to help out. Even if the reality is that native JavaScript is often all you need. It is still too lengthy a process for many developers to bother with. So we end-up with clunky one-page websites.

But all that is needed to solve it is some higher-level abstraction.

So Active CSS solves the same problem that CSS did, in exactly the same way that CSS did. It really isn’t anything new - it is just an extension of CSS.

With Active CSS, you feel you can tweak interactivity, add a bit more interactivity, like you can add more CSS, or tweak CSS. It feels exactly the same as CSS when you code with it, as it is quick and so direct. There is no waffling about with the JavaScript API.

So in practice, that is probably the most notable DX improvement.

But it only handles what it handles. Active CSS has its limitations in the same way CSS has its limitations. It only addresses interactivity - not general programming. You still need JavaScript.

1 Like

that would be sweet! It’ll really help the average web developer understand how the paradigm compares to the vast majority of framework out there (f.e. we have custom elements, but those are similar to all the other frameworks like React, Angular, Vue, Svelte, etc, that all give you a way of encapsulating pieces of UI in classes or functions so to compose them together). So web devs familiar with this all-to-familiar pattern across many frameworks and libs would benefit from having a clear understanding of how this new paradigm compares to the component class/function paradigm (where CSS is encapsulated withing the class/function comonents).

ActiveCSS looks neat, but the DX improvement may not be immediately obvious if newcomers that step into it aren’t already thinking in another direction than they do with all the existing libs/frameworks.

Yes, I agree. It’s a major paradigm shift. So from your last comment I started writing a full tutorial on an enhanced version of the React tutorial, so Tic Tac Toe with time travel, plus some other cool things. It’s taking a bit longer that I thought it would - there’s quite a lot to it, as you can imagine. It’s on its way… I’ve had to digress onto fixing a couple of bugs and setting up inline “styling” functionality, but hopefully that will be all wrapped up soon. I’ll aim for next week to get the tutorial and paradigm comparison up, or thereabouts. Having said that, there’s a couple of syntax changes I want to make, like having a @command function for creating a command, as it looks strange having full JS embedded within a CSS command, and the same @ function treatment is needed for creating a conditional and running a JS function. So I may knock these out before publishing the tutorial. Anyway, thanks for the feedback so far - it all helps to keep things moving. :slight_smile: Really appreciated.

1 Like

This looks really interesting. Some prior art here is the Decorators proposal as part of the original web component specs. It allowed some DOM manipulation via CSS but this seems to go quite a bit further. Reference: https://www.w3.org/TR/2013/WD-components-intro-20130606/#decorator-section

1 Like

Interesting, so <decorator> was sort of to HTML as what <defs> is to SVG.

Cool, looking forward to that demo!

Cool :slight_smile: Sorry for the delay. Got half-way through the demo - modelling it on the React one, then found a major bug with deep-referencing reactive Active CSS variables, fixed that, then realised components needed to be codable without a shadow DOM as I suddenly had a relatively non-techy client at work on one of my CMS’es that used Active CSS complain that everything (basically the Active CSS core) was broken on the old Edge which was his main browser (obviously - the old Edge doesn’t support shadow DOM), and as that version of Edge doesn’t update itself I had to quickly make a version of the core that worked on non-shadow DOM browsers, and then realised this whole thing may put people off using shadow DOM for a couple of years and not want to build components at all. So it really depends on the user base and the type of website whether the shadow DOM solution for components can be used or not.

I fixed basic old Edge support in the core but I’m aiming to put a release live at the end of Sunday that allows the same components without a shadow DOM and will work on the old Edge. Obviously all CSS is global - can’t do anything about that, and that’s not particularly a bad thing anyway. But there are now private components with isolated variables and also generally scoped components that can be hosted inside private components or whatever. Any events assigned to any component are always isolated. These components are then able to be hosted to custom elements or regular divs or whatever.

For simplicity’s sake, the only difference in the implementation of the components is that private components have a “private” parameter, shadow DOM components have a “shadow” parameter, and “global” components have no parameter at all. Otherwise everything is coded pretty much exactly as it is at the moment on the current release, with the @component {} wrapping syntax. I’m just wrapping up a “button counter” example page where all the different types of component combinations can be compared, so it should become clear what the difference is.

It all works offline except that the global components don’t allow isolated events yet. Hopefully sorting that out today - the docs are mostly updated, then will be back onto the bloomin’ Tic Tac Toe tutorial.

Will post back on here when there’s something to look at - as I say, hopefully by the end of Sunday. I didn’t want to do a full tutorial on components without having this functionality stable, hence the delay.

Thanks for the interest trusktr and matthewp!