Houdini: The most exciting development in CSS you’ve never seen

Have you ever wanted to use a special CSS feature but did not because it was not fully supported in all browsers? Or worse, it has been supported in all browsers, but support is buggy, inappropriate or even completely incompatible? If this happens to you – and I bet it already – then you should care about Houdini.

Houdini is a new W3C task force whose ultimate goal is to make this issue go away forever. They plan to do that by introducing a new set of APIs that will, for the first time, give developers the power to expand their own CSS, and tools to hook into styles and Process layout of browser rendering tool. But that means, specifically is it even a good idea? And how will it help us develop construction sites now and in the future?

In this article, I will try to answer these questions. But before I do, it is important to make it clear the current problems and why there is such a need to change. I will then talk more specifically about how Houdini will solve these problems and list some of the more interesting features being developed. Finally, I will provide some specific things we like the web developers can do today to help make Houdini a reality.

What problem Houdini Trying to solve?

Any time I write a post or build a demo of some new CSS features, make sure someone comments or on Twitter will say something like, "This is awesome! Too bad, we won't be able to use it for another 10 years. ”As annoying and destructive, I understand. In the past, it has proposed features to achieve widespread adoption. And the reason is that, throughout the history of the website, the only way to get a new feature added to CSS is to go through the standard process.

Steps in the standard process.

While I have absolutely nothing against the standard process, undeniably it may take a long time! For example, flexbox was first proposed in 2009, and developers still complain that they cannot use it today due to lack of browser support. Urgently, this problem is gradually going away because almost all modern browsers now update automatically; But even with modern browsers, there will always be a delay between the suggestions and the general availability of a feature. Interestingly, this is not a case in all areas of the web. Let's look at how things have been working recently in JavaScript:

Steps in the polyfill process.

In this scenario, the time between an idea and getting to use it in production can sometimes be a matter of many days. I mean, I used the async / wait function in production, and that feature was not implemented even in a single browser! You can also see a huge difference between these two communities. In the JavaScript community, you read the article in which people complain that things are moving too fast. In CSS, on the other hand, you hear people lament the futility of learning anything new, for how long it will be before they can actually use it.


First, writing multiple CSS polyfills seems like the answer. With good polyfills, CSS can move as fast as JavaScript, right? Sadly, it is not that simple. Polyfilling CSS is extremely difficult, and in most cases, can not do in a way that does not completely cancel performance.

JavaScript is a dynamic language, which means you can use JavaScript to polyfill JavaScript. And because it is very dynamic, it has a very wide open ability. CSS, on the other hand, may rarely be used to polyfill CSS. In some cases, you can transpile CSS into CSS in a build step (PostCSS does this); but if you want to polyfill anything that depends on the structure of the DOM or the layout or position of an element, then you will have to run the client-side logic of your polyfill. Unfortunately, the browser does not make this easy. The chart below allows a basic outline of how your browser goes from receiving an HTML document to displaying pixels on the screen. The blue steps in the show where JavaScript has the power to control the results:

Access the Javascript to rendering pipeline of the browser.

The picture is quite bleak. As a developer, you have no control over how the browser parses HTML and CSS and turns it into DOM and CSS object models (CSSOM). You have no control over the floors. You do not have control over how the browser chooses to set elements in the DOM or how it draws the visual elements on the screen. And you can't control what compositors do.

The only part of this process you can access is the DOM. The CSSOM is somewhat open; However, to cite Houdini's website, it is "underspecified, inappropriate on browsers, and lacks important features."

For example, CSSOMs in current browsers will not tell you the rules for cross-style style sheets, and it will simply remove any CSS rules or declare it does not understand, that has means that if you want a polyfill feature in the browser that doesn't support it, you can't use CSSOM. Instead, you must go through the DOM, find <style> and / or <link rel = "stylesheet"> tags, have your CSS, analyze it, rewrite it and then add it back to the DOM. Of course, updating the DOM often means that the browser has to then go through the whole cascade, layout, drawing and composite steps on again.

The browser's Polyfilling rendering pipeline with JavaScript.

While having to completely rerender a page may not seem to be great in terms of performance (especially for some sites), considering this frequency could potentially occur. If your polyfill logic needs to run in response to things like moving events, window resizing, mouse scrolling, keyboard events – really anytime anything at all change – then everything will get noticed, sometimes even cripplingly, slowly. This gets even worse when you realize that most of the CSS polyfills out there today include their own CSS parser and their own cascade logic. And because analytics and layers are really very complicated, polyfills are often too big or too faulty. To summarize everything I just said more succinctly: If you want the browser to do something different from what it thinks it's supposed to do (for CSS you gave it), then you must find a way to fake by updating and modifying the DOM. You do not have access to other steps in the rendering pipeline.


This, to me, is the most important question to answer this whole article. So if you have surfed the game so far, read this section slowly and carefully!

After looking at the last part, I'm sure some of you are thinking, "I don't need this! I just need to build normal websites. I'm not trying to hack into the browser internals or build something super-fancy, experimental or dramatic. "

If you are thinking, then I am forced to ask you to step back in a second and really check the technologies you have used to build websites over the years. Wanting to access and hook into the browser creation process is not just about building fancy demo – it is for developers and frameworks authors to do two main things:

  • to normalize the differences between browsers,
  • to p smart songs or polyfill new features so that users can use them.

If you've ever used a JavaScript library like jQuery, you've benefited from this ability! In fact, this is one of the main sellings points of almost all front-end libraries and frameworks today. The most popular year JavaScript and repository DOM on GitHub – AngularJS, D3, jQuery, React and Ember – all do a lot of work to normalize the differences between browsers so you don't have to think about it. Each exposes a single API, and it only works. Now, think about CSS and all cross-browser issues. Even CSS frameworks like Bootstrap and cross-browser compatible platforms don't really normalize cross-browser errors – they just need to avoid them. And the cross browser error in CSS is not just a thing of the past. Even today, with new layout modules like flexbox, we face many incompatibilities between browsers. The bottom line is, imagine your life will be better because you can use any CSS and know for sure it will work, exactly the same, in every browser. And think about all the new features, read your blog posts or listen to them at conferences and meetings – things like CSS grids, CSS snap points and sticky positioning. Imagine if you could use all of them now and in a way that is as powerful as CSS features. And what you need to do is get the code from GitHub.

This is Houdini's dream. This is the obligatory future trying to make good. So even if you never plan to write a polyfill CSS or develop an experimental feature, you may want others to do so – because once these polyfills exist, everyone Benefit from them.

ITZone via Gramy.vn

Share the news now