Menu Search
Jump to the content X X

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book now →

Houdini: Maybe The Most Exciting Development In CSS You’ve Never Heard Of

Have you ever wanted to use a particular CSS feature but didn’t because it wasn’t fully supported in all browsers? Or, worse, it was supported in all browsers, but the support was buggy, inconsistent or even completely incompatible? If this has happened to you — and I’m betting it has — then you should care about Houdini1.

Houdini is a new W3C task force whose ultimate goal is to make this problem go away forever. It plans to do that by introducing a new set of APIs that will, for the first time, give developers the power to extend CSS itself, and the tools to hook into the styling and layout process of a browser’s rendering engine.

But what does that mean, specifically? Is it even a good idea? And how will it help us developers build websites now and in the future?

In this article, I’m going to try to answer these questions. But before I do, it’s important to make it clear what the problems are today and why there’s such a need for change. I’ll then talk more specifically about how Houdini will solve these problems and list some of the more exciting features currently in development. Lastly, I’ll offer some concrete things we as web developers can do today to help make Houdini a reality.

What Problems Is Houdini Trying To Solve? Link

Any time I write an article or build a demo showing off some brand new CSS feature, inevitably someone in the 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 unconstructive as comments like this are, I understand the sentiment. Historically, it has taken years for feature proposals to gain widespread adoption. And the reason is that, throughout the history of the web, the only way to get a new feature added to CSS was to go through the standards process.

Standards process2

The steps in the standards process. (View large version3)

While I have absolutely nothing against the standards process, there’s no denying it can take a long time!

For example, flexbox4 was first proposed in 2009, and developers still complain that they can’t use it today due to a lack of browser support. Granted, this problem is slowly going away because almost all modern browsers now update automatically; but even with modern browsers, there will always be a lag between the proposal and the general availability of a feature.

Interestingly, this isn’t the case in all areas of the web. Consider how things have been working recently in JavaScript:

Polyfill Process5

The steps in the polyfill process. (View large version6)

In this scenario, the time between having an idea and getting to use it in production can sometimes be a matter of days. I mean, I’m already using the async/await functions in production, and that feature hasn’t been implemented in even a single browser!

You can also see a huge difference in the general sentiments of these two communities. In the JavaScript community, you read articles in which people complain that things are moving too fast. In CSS, on the other hand, you hear people bemoaning the futility of learning anything new because of how long it will be before they can actually use it.

So, Why Don’t We Just Write More CSS Polyfills? Link

At first thought, writing more CSS polyfills might seem like the answer. With good polyfills, CSS could move as fast as JavaScript, right?

Sadly, it’s not that simple. Polyfilling CSS is incredibly hard and, in most cases, impossible to do in a way that doesn’t completely destroy performance.

JavaScript is a dynamic language, which means you can use JavaScript to polyfill JavaScript. And because it is so dynamic, it’s extremely extensible. CSS, on the other hand, can rarely be used to polyfill CSS. In some cases, you can transpile CSS to CSS in a build step (PostCSS7 does this); but if you want to polyfill anything that depends on the DOM’s structure or on an element’s layout or position, then you’d have to run your polyfill’s logic client-side.

Unfortunately, the browser doesn’t make this easy.

The chart below gives a basic outline of how your browser goes from receiving an HTML document to displaying pixels on the screen. The steps colored in blue show where JavaScript has the power to control the results:

Rendering Process8

JavaScript access to the browser’s rendering pipeline. (View large version9)

The picture is pretty bleak. As a developer, you have no control over how the browser parses HTML and CSS and turns it into the DOM10 and CSS object model11 (CSSOM). You have no control over the cascade. You have no control over how the browser chooses to lay out the elements in the DOM or how it paints those elements visually on the screen. And you have no control over what the compositor does.

The only part of the process you have full access to is the DOM. The CSSOM is somewhat open; however, to quote the Houdini website, it’s “underspecified, inconsistent across browsers, and missing critical features.”

For example, the CSSOM in browsers today won’t show you rules for cross-origin style sheets, and it will simply discard any CSS rules or declarations it doesn’t understand, which means that if you want to polyfill a feature in a browser that doesn’t support it, you can’t use the CSSOM. Instead, you have to go through the DOM, find the <style> and/or <link rel="stylesheet"> tags, get the CSS yourself, parse it, rewrite it and then add it back to the DOM.

Of course, updating the DOM usually means that the browser has to then go through the entire cascade, layout, paint and composite steps all over again.

Rendering Process Polyfilled12

Polyfilling the browser’s rendering pipeline with JavaScript. (View large version13)

While having to completely rerender a page might not seem like that big of a performance hit (especially for some websites), consider how often this potentially has to happen. If your polyfill’s logic needs to run in response to things like scroll events, window resizing, mouse movements, keyboard events — really anytime anything at all changes — then things are going to be noticeably, sometimes even cripplingly, slow.

This gets even worse when you realize that most CSS polyfills out there today include their own CSS parser and their own cascade logic. And because parsing and the cascade are actually very complicated things, these polyfills are usually either way too big or way too buggy.

To summarize everything I just said more concisely: If you want the browser to do something different from what it thinks it’s supposed to do (given the CSS you gave it), then you have to figure out a way to fake it by updating and modifying the DOM yourself. You have no access to the other steps in the rendering pipeline.

But Why Would I Ever Want To Modify The Browser’s Internal Rendering Engine? Link

This, to me, is absolutely the most important question to answer in this whole article. So, if you’ve been skimming things so far, read this part slowly and carefully!

After looking at the last section, I’m sure some of you were thinking, “I don’t need this! I’m just building normal web pages. I’m not trying to hack into the browser’s internals or build something super-fancy, experimental or bleeding-edge.”

If you’re thinking that, then I strongly urge you to step back for a second and really examine the technologies you’ve been using to build websites over the years. Wanting access and hooks into the browser’s styling process isn’t just about building fancy demos — it’s about giving developers and framework authors the power to do two primary things:

  • to normalize cross-browser differences,
  • to invent or polyfill new features so that people can use them today.

If you’ve ever used a JavaScript library such as jQuery, then you’ve already benefitted from this ability! In fact, this is one of the main selling points of almost all front-end libraries and frameworks today. The five most popular JavaScript and DOM repositories on GitHub — AngularJS, D3, jQuery, React and Ember — all do a lot of work to normalize cross-browser differences so that you don’t have to think about it. Each exposes a single API, and it just works.

Now, think about CSS and all of its cross-browser issues. Even popular CSS frameworks such as Bootstrap and Foundation that claim cross-browser compatibility don’t actually normalize cross-browser bugs — they just avoid them. And cross-browser bugs in CSS aren’t just a thing of the past. Even today, with new layout modules such as flexbox14, we face many cross-browser incompatibilities15.

The bottom line is, imagine how much nicer your development life would be if you could use any CSS property and know for sure it was going to work, exactly the same, in every browser. And think about all of the new features you read of in blog posts or hear about at conferences and meetups — things like CSS grids16, CSS snap points3217 and sticky positioning3318. Imagine if you could use all of them today and in a way that was as performant as native CSS features. And all you’d need to do is grab the code from GitHub.

This is the dream of Houdini. This is the future that the task force is trying to make possible.

So, even if you don’t ever plan to write a CSS polyfill or develop an experimental feature, you’d probably want other people to be able to do so — because once these polyfills exist, everyone benefits from them.

What Houdini Features Are Currently In Development? Link

I mentioned above that developers have very few access points into the browser’s rendering pipeline. Really, the only places are the DOM and, to some extent, the CSSOM.

To solve this problem, the Houdini task force has introduced several new specifications that will, for the first time, give developers access to the other parts of the rendering pipeline. The chart below shows the pipeline and which new specifications can be used to modify which steps. (Note that the specifications in gray are planned but have yet to be written.)

Spec Coverage19

Where new Houdini specifications fit into the browser’s rendering pipeline. (View large version20)

The next few sections give a brief overview of each new specification and what kinds of capabilities it offers. I should also note that other specifications are not mentioned in this article; for the complete list, see the GitHub repository of Houdini’s drafts21.

CSS Parser API Link

The CSS Parser API22 is currently not written; so, much of what I say could easily change, but the basic idea is that it enables developers to extend the CSS parser and tell it about new constructs — for example, new media rules, new pseudo-classes, nesting, @extends, @apply, etc.

Once the parser knows about these new constructs, it can put them in the right place in the CSSOM, instead of just discarding them.

CSS Properties and Values API Link

CSS already has custom properties, and, as I’ve expressed before23, I’m very excited about the possibilities they unlock. The CSS Properties and Values API24 takes custom properties a step further and makes them even more useful by adding types.

There are a lot of great things about adding types to custom properties, but perhaps the biggest selling point is that types will allow developers to transition and animate custom properties, something we can’t do today.

Consider this example:

body {
  --primary-theme-color: tomato;
  transition: --primary-theme-color 1s ease-in-out;
}
body.night-theme {
  --primary-theme-color: darkred;
}

In the code above, if the night-theme class is added to the <body> element, then every single element on the page that references the --primary-theme-color property value will slowly transition from tomato to darkred. If you wanted to do this today, you’d have to write the transition for each of these elements manually, because you can’t transition the property itself.

Another promising feature of this API is the ability to register an “apply hook,” which gives developers a way to modify the final value of a custom property on elements after the cascade step has completed, which could be a very useful feature for polyfills.

CSS Typed OM Link

CSS Typed OM25 can be thought of as version 2 of the current CSSOM. Its goal is to solve a lot of the problems with the current model and include features added by the new CSS Parsing API and CSS Properties and Values API.

Another major goal of Typed OM is to improve performance. Converting the current CSSOM’s string values into meaningfully typed JavaScript representations would yield substantial performance gains.

CSS Layout API Link

The CSS Layout API26 enables developers to write their own layout modules. And by “layout module,” I mean anything that can be passed to the CSS display property. This will give developers, for the first time, a way to lay out that is as performant as native layout modules such as display: flex and display: table.

As an example use case, the Masonry layout library27 shows the extent to which developers are willing to go today to achieve complex layouts not possible with CSS alone. While these layouts are impressive, unfortunately, they suffer from performance issues, especially on less powerful devices.

The CSS Layout API works by giving developers a registerLayout method that accepts a layout name (which is later used in CSS) and a JavaScript class that includes all of the layout logic. Here’s a basic example of how you might define masonry via registerLayout:

registerLayout('masonry', class {
  static get inputProperties() {
    return ['width', 'height']
  }
  static get childrenInputProperties() {
    return ['x', 'y', 'position']
  }
  layout(children, constraintSpace, styleMap, breakToken) {
    // Layout logic goes here.
  }
}

If nothing in the above example makes sense to you, don’t worry. The main thing to care about is the code in the next example. Once you’ve downloaded the
masonry.js file and added it to your website, you can write CSS like this and everything will just work:

body {
  display: layout('masonry');
}

CSS Paint API Link

The CSS Paint API is very similar to the Layout API above. It provides a registerPaint method that operates just like the registerLayout method. Developers can then use the paint() function in CSS anywhere that a CSS image is expected and pass in the name that was registered.

Here’s a simple example that paints a colored circle:

registerPaint('circle', class {
  static get inputProperties() { return ['--circle-color']; }
  paint(ctx, geom, properties) {
    // Change the fill color.
    const color = properties.get('--circle-color');
    ctx.fillStyle = color;
    // Determine the center point and radius.
    const x = geom.width / 2;
    const y = geom.height / 2;
    const radius = Math.min(x, y);
    // Draw the circle \o/
    ctx.beginPath();
    ctx.arc(x, y, radius, 0, 2 * Math.PI, false);
    ctx.fill();
  }
});

And it can be used in CSS like this:

.bubble {
  --circle-color: blue;
  background-image: paint('circle');
}

Now, the .bubble element will be displayed with a blue circle as the background. The circle will be centered and the same size as the element itself, whatever that happens to be.

Worklets Link

Many of the specifications listed above show code samples (for example, registerLayout and registerPaint). If you’re wondering where you’d put that code, the answer is in worklet28 scripts.

Worklets are similar to web workers, and they allow you to import script files and run JavaScript code that (1) can be invoked at various points in the rendering pipeline and (2) is independent of the main thread.

Worklet scripts will heavily restrict what types of operations you can do, which is key to ensuring high performance.

Composited Scrolling and Animation Link

Though there’s no official specification yet for composited scrolling and animation29, it’s actually one of the more well-known and highly anticipated Houdini features. The eventual APIs will allow developers to run logic in a compositor worklet, off the main thread, with support for modification of a limited subset of a DOM element’s properties. This subset will only include properties that can be read or set without forcing the rendering engine to recalculate layout or style (for example, transform, opacity, scroll offset).

This will enable developers to create highly performant scroll- and input-based animations, such as sticky scroll headers and parallax effects30. You can read more about the use cases31 that these APIs are attempting to solve on GitHub.

While there’s no official specification yet, experimental development has already begun in Chrome. In fact, the Chrome team is currently implementing CSS snap points3217 and sticky positioning3318 using the primitives that these APIs will eventually expose. This is amazing because it means Houdini APIs are performant enough that new Chrome features are being built on top of them. If you still had any fears that Houdini would not be as fast as native, this fact alone should convince you otherwise.

To see a real example, Surma34 recorded a video demo35 running on an internal build of Chrome. The demo mimics the scroll header’s behavior seen in Twitter’s native mobile apps. To see how it works, check out the source code36.

What Can You Do Now? Link

As mentioned, I think everyone who builds websites should care about Houdini; it’s going to make all of our lives much easier in the future. Even if you never use a Houdini specification directly, you’ll almost certainly use something built on top of one.

And while this future might not be immediate, it’s probably closer than a lot of us think. Representatives of all major browser vendors were at the last Houdini face-to-face meeting in Sydney earlier this year, and there was very little disagreement over what to build or how to proceed.

From what I could tell, it’s not a question of if Houdini will be a thing, but when, and that’s where you all come in.

Browser vendors, like everyone else who builds software, have to prioritize new features. And that priority is often a function of how badly users want those features.

So, if you care about the extensibility of styling and layout on the web, and if you want to live in a world where you can use new CSS features without having to wait for them to go through the standards process, talk to members of the developer relations teams for the browser(s) you use, and tell them you want this.

The other way you can help is by providing real-world use cases — things you want to be able to do with styling and layout that are difficult or impossible to do today. Several of the drafts on GitHub37 have use-case docs, and you can submit a pull request to contribute your ideas. If a doc doesn’t exist, you can start one.

Members of the Houdini task force (and the W3C in general) really do want thoughtful input from web developers. Most people who participate in the spec-writing process are engineers who work on browsers. They’re often not professional web developers themselves, which means they don’t always know where the pain points are.

They depend on us to tell them.

Special thanks to Houdini members Ian Kilpatrick42 and Shane Stephens43 for reviewing this article.

(al, vf, jb)

Footnotes Link

  1. 1 https://wiki.css-houdini.org/
  2. 2 https://www.smashingmagazine.com/wp-content/uploads/2016/03/01-standards-process-opt.png
  3. 3 https://www.smashingmagazine.com/wp-content/uploads/2016/03/01-standards-process-opt.png
  4. 4 https://drafts.csswg.org/css-flexbox/
  5. 5 https://www.smashingmagazine.com/wp-content/uploads/2016/03/02-polyfill-process-opt.png
  6. 6 https://www.smashingmagazine.com/wp-content/uploads/2016/03/02-polyfill-process-opt.png
  7. 7 https://github.com/postcss/postcss
  8. 8 https://www.smashingmagazine.com/wp-content/uploads/2016/03/03-rendering-process-opt.png
  9. 9 https://www.smashingmagazine.com/wp-content/uploads/2016/03/03-rendering-process-opt.png
  10. 10 https://dom.spec.whatwg.org/
  11. 11 https://drafts.csswg.org/cssom/
  12. 12 https://www.smashingmagazine.com/wp-content/uploads/2016/03/04-rendering-process-polyfilled-opt.png
  13. 13 https://www.smashingmagazine.com/wp-content/uploads/2016/03/04-rendering-process-polyfilled-opt.png
  14. 14 https://www.smashingmagazine.com/2013/05/centering-elements-with-flexbox/
  15. 15 https://github.com/philipwalton/flexbugs
  16. 16 https://drafts.csswg.org/css-grid/
  17. 17 https://drafts.csswg.org/css-snappoints/
  18. 18 https://drafts.csswg.org/css-position-3/#sticky-pos
  19. 19 https://www.smashingmagazine.com/wp-content/uploads/2016/03/05-spec-coverage-opt.png
  20. 20 https://www.smashingmagazine.com/wp-content/uploads/2016/03/05-spec-coverage-opt.png
  21. 21 https://github.com/w3c/css-houdini-drafts
  22. 22 https://drafts.css-houdini.org/css-parser-api/
  23. 23 http://philipwalton.com/articles/why-im-excited-about-native-css-variables/
  24. 24 https://drafts.css-houdini.org/css-properties-values-api/
  25. 25 https://drafts.css-houdini.org/css-typed-om/
  26. 26 https://drafts.css-houdini.org/css-layout-api/
  27. 27 http://masonry.desandro.com/
  28. 28 https://drafts.css-houdini.org/worklets/
  29. 29 https://github.com/w3c/css-houdini-drafts/blob/master/composited-scrolling-and-animation/Explainer.md
  30. 30 https://www.smashingmagazine.com/2015/06/fitting-after-effects-into-a-ux-workflow/
  31. 31 https://github.com/w3c/css-houdini-drafts/blob/master/composited-scrolling-and-animation/UseCases.md
  32. 32 https://drafts.csswg.org/css-snappoints/
  33. 33 https://drafts.csswg.org/css-position-3/#sticky-pos
  34. 34 https://surma.link
  35. 35 https://www.youtube.com/watch?v=EUlIxr8mk7s
  36. 36 https://github.com/GoogleChrome/houdini-samples/tree/master/twitter-header
  37. 37 https://github.com/w3c/css-houdini-drafts
  38. 38 https://drafts.css-houdini.org/
  39. 39 https://github.com/w3c/css-houdini-drafts
  40. 40 https://github.com/GoogleChrome/houdini-samples
  41. 41 http://lists.w3.org/Archives/Public/public-houdini/
  42. 42 https://twitter.com/bfgeek
  43. 43 https://twitter.com/komradshaneski

↑ Back to top Tweet itShare on Facebook

Advertisement

Philip Walton is an engineer at Google working on improving developer platforms. He's been building websites professionally for over ten years, and has a passion for teaching others about software development and the web. You can read more of his writing on his website and follow his open source projects on Github.

  1. 1

    Martin Spierings

    March 24, 2016 12:16 pm

    Interesting article and i’m looking forward to the result.

    But still poses a problem: we also need to wait for this too and for it to be supported by enough browsers. It doesn’t really seem to fix the problem in the short term (or any term if we’re unlucky), so i’m still wondering how this will pan out. Seems to me that we still have an issue of browsers not getting the appropriate updates on platforms, which would eliminate the issues in the first place. So why aren’t they also working on that too?

    11
  2. 3

    Jon Hobbs-Smith

    March 24, 2016 2:31 pm

    I recently spent a little while thinking about how some common CSS problems could be solved by allowing properties to reference the current calculated values of properties on other elements. So for example making elements equal heights (even if they are not siblings and can’t be contained in a flexbox) could be as simple as:

    myelement{
    height: largest(.element1:height, .element2:height, .element3:height);
    }

    Fixed positioning could be as simple as:

    myelement{
    position: absolute;
    top: calc(body:scrollTop + 100px );
    }

    Yeah, the syntax is horrible and I know that problems would have to be solved like cyclical references, but my point is that I realised that so many common problems could be solved if CSS could be a little more expressive and we wouldn’t have to use javascript to do tasks like this and onscroll, onresize events etc. Of course, none of this is possible to do at the moment and I doubt any of the vendors are even planning it.

    So, I read this article with interest and it seemed like it might make my ideas redundant. It sounds like houdini may make a lot of these seemingly simple things possible by writing new layout methods, or have I got the wrong end of the stick?

    Either way, I’m going to be following this closely.

    11
    • 4

      Philip Walton

      March 24, 2016 3:17 pm

      You’re exactly correct. And ideas like yours are a great example of the problems Houdini is trying to solve and the power its trying to give developers.

      2
    • 5

      You may be interested in some of the work Philip Zastrow is into. He does a lot with element-based responsive web design with container queries. Check it out here:

      http://codepen.io/collection/nZMGEe/

      1
    • 6

      I must be missing something in your fixed example. Why wouldn’t you just use position: fixed; top: 100px?

      2
      • 7

        I know I am late but I think if you don’t want to be the horizontal position
        of the fixed element be relative to the window, then something like that could make
        lives simpler.

        0
  3. 8

    Bryan Sullivan

    March 24, 2016 4:30 pm

    This sounds interesting. But it sounds like we’re talking about giving the developers the opportunity to roll their own CSS rendering engine (in simplified terms).

    I shudder at the thought of inheriting some over-engineered hack job that I would then have to reverse-engineer to support.

    There isn’t much anyone can do about waiting for language specs to be recommended. But the browser vendors have historically been horrible at implementing recommended specs in a timely manner. It shouldn’t take years to implement new functionality. That is the primary issue in my opinion. I hope that as the auto-updates and faster update cycles continue that this won’t be as much of an issue going forward.

    Having said that, I’m still interested to see where this goes. Maybe if certain CSS pollyfills become popular, they will become part of the recommended specs and no longer needed as pollyfills. And maybe that could push the language forward at a faster rate?

    7
    • 9

      Ian Kilpatrick

      March 24, 2016 6:18 pm

      Re: polyfills: That is definitely a large motivating factor. A lot of standards development is driven by existing polyfills for JS/DOM.

      For example document.querySelectorAll was motivated by jQuery. Similarly story with many of the new JS features (String.prototype.startsWith for example).

      CSS is fundamentally hard to polyfill, and you end up with non-performant results often. I hope that Houdini can fix that. :)

      0
  4. 10

    The word ‘performant’ is an ugly neologism that needs to die – especially since it got used four times in this article alone. Try something else, like ‘high-performing’ (one more syllable, much less ugly), ‘efficient’ or simply ‘fast’.

    -7
  5. 11

    Aidan Foster

    March 24, 2016 7:34 pm

    So Houdini sounds like it extends CSS’s functionality in a similar way to how Web Components extend html & the Dom. Is this a fair analogy?

    4
  6. 12

    Derek Shanks

    March 24, 2016 7:44 pm

    Web dev is already hard enough with tooling, transpilers, dependencies and their dependencies and using tomorrow’s syntax today attitude. If anything we need to stop trying to duct tape things into working and really fix the serious problems that are already here.

    You can’t buy and drive a 2020 model car until it’s built. Yet we have developers hacking browsers far into the future until either the web breaks or people burn out from trying to learn yet another tool.

    The NPM debacle yesterday is a clear indication that things are kind of going a little wrong with how developers are building things today.

    25
    • 13

      Agreed. The web needs a more standardized framework with which to build around that doesn’t leave gaping holes that rely on the browser developers to fill however they please, or if they please.

      2
    • 14

      Yes, but imagine all 2016 cars being sold with the same features from 2000 … but we’re promised in 2020 that we’ll finally get that iPod classic dock we all so passionately desire!

      2
  7. 16

    Martin Chaov

    March 25, 2016 7:26 am

    POWER TO THE PEOPLE :)

    -1
  8. 17

    The term “polyfill” needs to go somewhere and die. Seriously.

    5
  9. 18

    This reminds a bit of Active and that freaks me out. Yes is not code that can affect your computer but if that’s the case then it does need to be interpreted by the browser so who is to say we won’t have differences there? You still will have to write one per browser much in the way we do now with some CSS features.

    And if the code is not interpreted bur rather compiled and used as binary, then wth, that IS active.

    1
  10. 19

    Chris Samoiloff

    March 25, 2016 4:55 pm

    This is very exciting! The web may be moving too slowly for us but putting it into the perspective of being in the business for 20 years, it’s flying these days!

    -1
  11. 21

    I was curious about Apple’s take on this, so I read some of the meeting notes https://wiki.css-houdini.org/planning and this document https://trac.webkit.org/wiki/FiveYearPlanFall2015

    It looks like the scrolling enhancements are a priority for them. I couldn’t really tell with the rest of the proposals.

    0
  12. 22

    Marco Scannadinari

    March 26, 2016 12:02 am

    Just like to point out that in the variable reference here:

    transition: –primary-theme-color 1s ease-in-out

    --primary-theme-color should be surrounded with a var() function

    0
    • 23

      Philip Walton

      March 26, 2016 12:49 am

      In this example --primary-theme-color is being referenced by its property name and not used, so it doesn’t need the var() function.

      0
      • 24

        In `–primary-theme-color` example section. Do you mean if I use in other place like


        p {
        color: var(--primary-theme-color);
        }

        will change when `.night-theme` is added

        0
  13. 26

    So I do understand my friend, who abandonned front end in favour of java. He was plain tired with learning. Got great job with great salary in a technology where he does not need to relearn all the stack he works with every three months. Eventually the web dev world will divide to 300 people creating bootstrap-like libraries and 99.99% developers using them with no actual understanding of thousands APIs on hundreds of levels between their code and browser window…

    3
  14. 27

    Alistair Tweedie

    March 27, 2016 10:39 am

    Interesting article and concept.

    This stood out to me: “Once the parser knows.” Does this mean we are again relying on JavaScript to render layout? – the same way using Masonry results in poor performance, will this give the same overheads? If so it that sits a little uneasy.

    I can see the potential for this to be very powerful when using a framework like Angular or React to build an application and page speed and support may not be such a focus. I love the concept but is relying on yet more JS to bring standards inline the best future for CSS?

    3
  15. 28

    Jason Khanlar

    March 28, 2016 8:08 am

    It would be interesting to see deployable web browser environments that function similar as compiled docker containers.

    0
  16. 29

    The W3C is really going to pot these days: WHY would you let the developer reign free over the presentation layer like this? Surely allowing programming of any nature inside the presentation layer destroys the abstraction between the markup (HTML), client-side code (JavaScript) and presentation layer (CSS)?

    This will also open up multiple security vulnerabilities for phishing attacks, etc?

    The other big recent mistake is add DRM to HTML5: http://freeculture.org/blog/2013/04/23/dont-let-the-myths-fool-you-the-w3cs-plan-for-drm-in-html5-is-a-betrayal-to-all-web-users/

    2
  17. 30

    I look forward to the day when browsers become inter-operable, I’ve been waiting for it for 20 years. If this would solve it, it’s hard to be against it.

    But it’s also hard not to be skeptical. I assume that Houdini itself cannot be polyfilled, meaning it can only be used once ALL relevant browsers support it. So ironically, wouldn’t this yet be another “meh, I’ll check back in 7 years” feature?

    (side note, I work in e-commerce, where still full IE8 support is needed, just to give a taste of the real world)

    Furthermore, what reason do we have to believe that browser vendors will all be on board this time, given that in the past 2 decades, such interoperability was not achieved?

    Sorry to be this cynical, I genuinely support your hard work in improving the life of web developers and this is very much needed.

    Rather than giving rendering control to the community, I’m also thinking of another angle. Perhaps controversial, but I really fail to see the added value of all these different rendering engines nowadays. They compete, but compete on what exactly? From a developer’s perspective, a rendering engine first and foremost should be CORRECT. Speed matters but increasingly rendering engines are matching in that area. The only thing they differ in now is how buggy they are and which experimental features they do or do not support. The added value of that “diversity” is a plain negative.

    Yes, I said it, what if the W3C would not only standardize the spec, but also the implementation?
    (not going to happen, but since we’re in crazy idea mode, why not?)

    2
    • 31

      Yep – have to agree with Ferdy’s comment.

      I read a lot of these “here’s the next new thing in CSS/HTML/browsers/etc/etc!!!!”, then I sigh, and go back to my web app where my clients are all still using IE8 and worse. This isn’t because they are oblivious to the fact the IE8 is out-dated and a security risk (we have told them repeatedly), it’s that their business doesn’t see upgrading as a priority task, rightly or wrongly…and I am talking about some very large, well-known, even global, companies. This really hurts when the client then comes to us and says “oh, we want the app to be available on mobiles and tablets but we still have to support IE8 for the desktops”.

      Of course, Houdini is designed to help all that but then:
      a. as per Ferdy’s comment, Houdini would only be as good as whichever bits of the recommendations that the browser manufacturer chose to implement at the time based on their own business/technical reasons. There is no consistency here and I don’t see any way of enforcing a manufacturer to do this unless you could somehow impact their bottom line.
      b. at the end of the day, my clients don’t see any business reason for THEM to upgrade from IE8, which will not be “houdini-compatible” (to coin a term) so my web app does not benefit from the Houdini goodness.

      I think there are greater issues outside of the development arena that if addressed, could negate the need for something like Houdini. The wider business world doesn’t generally care about this stuff – the perception would be that “Houdini would be another shiny toy for us (the dev community) to play with but there’s nothing in it for them so why would they be bothered?”.

      I know I’m coming across as pretty cynical, but after over 15 years in this game and constantly juggling browser inconsistencies and client expectations and limitations, I’m afraid that should the Houdini Concept ever see the light of day, we will see “Chrome Houdini”, “Firefox Houdini”, “IE Houdini”, “Safari Houdini”, etc and it will be yet another plate that we need to keep spinning

      1
  18. 32

    I really don't like advertising

    March 31, 2016 6:53 am

    “Hey, guys! Let’s give the advertisers a way to inject ads directly into the browser’s rendering pipeline!”

    9
  19. 33

    This a wonderful technology idea for developers and content providers but terrible for users.
    Giving a content provider procedural control over how they content they deliver is consumed is tantamount to saying, “You can receive data from this web-page but only if you also utilise it in this particular way.” This breaks the extensibility philosophy that was at the heart of what Tim Berners-Lee intended for the world wide web – the user is no-longer in control.
    Houdini would also be unreasonably supportive of the advert supported web which, whilst an acceptable business model, should not be having additional technological support that a user cannot be control of.
    I guess the question really is where you draw the information transaction boundary between the user and the content provider. Should it stay at its current point of once data leaves a web server the user gets to decide what they do with it or go with the methodology that Houdini could provide of once the data is rendered into pixels the user gets to decide what they do with it.

    2
    • 34

      That was my thought as I read the article. Tools like AdBlock Plus and FB Purity rely on standard CSS. Some people need to manually increase the font-size. Sorry developer, but you’re still in your twenties (and good for you, enjoy them, I remember them fondly). Don’t take it personally but I also need to add Bold and take those serifs off your font choice so that I can read your content. Houdini could make that impossible.

      Also – why the hell am I installing a web browser on my machine if every web site is going to include a rendering engine in their HTML anyway? I like web pages with about a 300K footprint so you can imagine how I feel about these 3MB click bait pages. Houdini won’t make those downloads any smaller – or use less RAM or CPU on my machine.

      All in all, it seems like a bad idea, but good effort, keep trying.

      1
  20. 35

    So its like IE 6 behavior css property?
    https://msdn.microsoft.com/en-us/library/ms530723(v=vs.85).aspx

    0

↑ Back to top