It has been years since CSS Houdini was revealed in 2016 and admittedly, it has been very slow going. Although, since the W3C task force was announced there have been a few things delivered.
If you’re not aware of CSS Houdini, it is a set of proposals and standards that allow access to lower-level aspects of the layout and CSS parser in web browser engines. It is basically an umbrella term used to describe a tonne of different API’s, some of which have already shipped and you might be familiar with.
As someone who has been developing since Internet Explorer 5.5, I still remember what the web used to be like. We once upon a time in IE6 didn’t have support for transparent PNG’s, custom web fonts required using solutions such as SIFR which relied on Flash and JS, rounded corners with CSS were also not possible, requiring the use of carefully cut out transparent GIF’s.
Since then, we have come a very long way. We can now do shadows, gradients, filter effects, custom fonts, rounded corners and advanced layouts all inside of CSS. It’s easy to forget how far we have come and to see where CSS is heading, CSS is not finished yet.
Surprisingly, Firefox has been dragging the chain on implementation of numerous Houdini features. Mozilla has marked the Layout API as worth prototyping, the same thing for the Paint API, Properties & Values API and finally Typed OM. As for Safari, they’ve gone a little further than Mozilla (which is really surprising).
Understandably, CSS Houdini is ambitious and it has a lot of moving parts. Browser vendors and standards participants are very particular about the ways in which these API’s are implemented and exposed. There are numerous ideas in the issues section on the GitHub repository.
The last big piece of the puzzle before CSS Houdini goes to the next level is the Parser API. When you read up on what this API can do, you’ll understand why it hasn’t been implemented in any browser yet, it’s still in proposal form at the moment.
