Have you ever learned a CSS feature that you wanted to start using but couldn’t because it wasn’t supported by all browsers, or they didn’t all implement it the same way? We’ve all been there.
Using new CSS features has historically been a process that takes years, and this means it doesn’t move at the speed the web moves. This is a problem that Project Houdini is here to solve.
The current state of CSS
CSS today is really complex and powerful, able to completely change the experience of a page by changing just a few properties. But the reality is that as developers, we don’t have much control over how CSS works.
On the left, the second and third editions of CSS: The Definitive Guide. On the right, the fourth edition.
The only thing we really have control over is the DOM, so if we want to create a polyfill for a CSS feature, what we do today is parse the styles, find and modify them, and then insert them into the DOM.
This causes the page to repaint and very likely leads to performance issues.
What is Project Houdini?
Project Houdini is a joint effort by Mozilla, Apple, Opera, Microsoft, HP, Intel, and Google to expose APIs that allow us to work with certain parts of the CSS engine.
What are the implications of Houdini?
As I said before, using new features is a very time-consuming process. Something that doesn’t happen in the JavaScript community with Babel, which lets us write new JS today. We’d achieve something similar with Houdini.
Historically, the way to use new CSS features has been to wait through the entire standardization process by the W3C and standardization by browser vendors.
Why would we want control over how CSS works?
Having control over how browsers paint the page isn’t just about creating pretty pages. Some of the possibilities we’d have include:
- Being able to normalize how browsers implement certain features.
- Creating plugins or polyfills to implement new features that haven’t been implemented yet or are just proposals.
If you work as a web developer, you know this is pretty powerful, and it would take us to a new era on the web where the possibilities are limitless.
What APIs are being developed?
To truly have control over the painting process, the project’s idea is to create a set of APIs that allow us to manipulate certain parts of the browser’s painting process.
Here are some of the APIs, though many are still just drafts.
List of APIs
- Worklets: A lot of the code for these APIs will run every time the page repaints, which is why a feature similar to web workers is planned.
- Layout API: Adds the ability to create custom display values like
display: layout('myflex'). We could create our own versions of flex or grid, for example. - Painting API: Allows painting borders and images. Could add the ability for filters, alphas, etc.
- Parser API: Would let us parse code the way Babel does internally.
- Typed API: Adds a type system to control measurements and similar things.
- Font Metric API: Provides methods for working with fonts.
- Properties and Values API: Register new properties.
Current state of Houdini
Many of the APIs proposed by Houdini are still in draft, but work has already begun on them. Chrome 65 already has support for the Paint API. It’s only a matter of time before using all these APIs becomes a reality, and we can track progress at:
Final words
As a developer, I’m really excited about the development of Houdini and its possibilities. I believe that in the not-too-distant future, we won’t have to wait years to use new CSS features and will have real control over how one of the fundamental parts of the web works.
Content you can’t miss: