Houdini: Maybe the Most Exciting Development in CSS | Hacker News Reader

Houdini: Maybe the Most Exciting Development in CSS

smashingmagazine.com

159 pointsmattiemass62 comments

> 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).

I'm frankly skeptical of most of Houdini, but I'm especially not happy with this one. This is baking the limitations of current browser engines into the platform for all time. The provided justification seems pretty flimsy to me, because effort that goes into this (which is something that native has no concept of, for good reason) could instead go into fixing the problems that make it seem like this is necessary.

Don't just complain about it on HN, tell the developers directly (via GitHub or otherwise).

A fair point, but pointing out a perceived flaw on Hackernews often leads to good discussion, and is sometimes followed by the authors themselves. I can see both sides of it, but I'd personally like to start it here then carry it over to filing an issue afterwards (if it still feels it has merit).

Okay, let's start the discussion here. The premise is that the design decisions being made for Houdini now will hold back CSS functionality in the long run. Two questions:

1. What is an example of a new stylesheet feature that couldn't be implemented with Houdini in its current design?

2. Why will the current decisions being made on the Houdini APIs hold back further evolution of these APIs? In other words, why can't we go with a MVP and evolve as required?

The Paint API is a poor match for GPUs, so we're going to encourage people to write poorly performing features with the API as designed.

The compositing API is overly tailored to existing browser engine details. It's forcing complexity onto Web developers when the problem should be solved at the engine level. Having to do all the compositing logic in a worker is terribly inconvenient anyway. If main thread animations are untenable due to random main thread jank, let's fix that instead of adding difficult-to-use workarounds. We're not doing the Web any favors when competing against native by saying "you can get native performance, but only if you contort your program".

An "MVP" that is poorly designed is not an "MVP". There are designs that are flawed due to not having enough features; this is a reasonable candidate for an MVP. But there are also designs that are flawed due to fundamental design problems. Releasing these kinds of designs onto the Web is not releasing an MVP; it's making another mistake.

Good, so you have something concrete to share with the developers before they make that mistake: https://github.com/w3c/css-houdini-drafts

I really liked the video last month about webrender, which really looked like the future of rendering web content. It sounds like this Houdini stuff would not work so well with a webrender type infrastructure? That would be a real shame and sounds like short sighted thinking in this proposal.

That's right; Houdini does not work well with WebRender. It's designed for the traditional browser architecture.

The CSS Compositing API is basically creating a separate tiny DOM that runs on its own thread because the main thread is supposedly too slow. (It has event handling and everything!) This is counterproductive in my view: it's just poorly reinventing the DOM we already have. If you want to multithread the rendering engine, multithread the rendering engine. Let's not introduce a new tiny multithreaded part off to the side that badly replicates 1% of the functionality of the DOM; that's not a nice way to treat Web authors.

I suspect that most of the advantage of this API in practice would be that it's a thread for the main content to play in that ads can't get to. Until the ads start using it, and then we're back to square one. If the main thread is getting hogged by ads or whatever, let's fix that problem (perhaps via off main thread iframes and off main thread layout). The Web will always be worse than native unless we fix that, no matter how many hacks we pile on top of it.

1. Not supporting any features that trigger a layout recalculation is a pretty major drawback, I'd say. The complaint I hear most about CSS is that it's actually terrible for layouts, and while flex is a step in the right direction it still has a long way to go.

2. Houdini is specifically proposed to address the issue of browsers not implementing specs quickly enough. Now they'll have yet another spec to implement, and it's intended to "just work" in all the browsers, except it'll depend on what version of the spec the various browsers have implemented, taking us right back to square one.

Browser engineer here (Microsoft Edge). We read HN too. ;-)

Welp, what do you guys think about houdini?

Very interesting, and oddly reminiscent of the shift from fixed-function to programmable graphics APIs, right down to the restricted "worklets" being sort-of-analogous to shader programs.

I do wonder whether "as performant as native CSS features" is setting up unrealistic expectations. Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize, even leaving aside the language/runtime differences (C++/Rust versus JS/WASM).

> Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize

It will be. And things like the CSS Paint API are based on APIs that are poor matches for GPUs (but are easy for browsers of today to implement). I expect that those who are looking for Houdini for performance reasons will end up quite disappointed.

More broadly, I have seen the "replace the native implementation with a JavaScript implementation for better performance" idea tried many times, and I can't think of a single time it's actually worked.

I didn't get the impression from that article that "replace the native implementation with a JavaScript implementation for better performance" was the goal at all. Rather, the goal seems to be "move away from a situation where one holdout browser (traditionally IE, more recently Safari/iOS) could scupper a new feature completely, and toward one where holdouts are just slower if they don't support that feature natively". There have been lots of examples of that strategy working - jQuery/QSA, asm.js etc.

Is that a misleading impression? Does Houdini have another agenda not covered by the article?

That's a reasonable use case for Houdini, yes. But I also think that if that's the goal CSS Paint and CSS Compositing should be redesigned...

No, that is an accurate impression. The ultimate goal of Houdini is to give developers the tools to innovate; unlike the current situation were all innovation happens at the spec level, and devs have to wait (often years) for browser adoption.

That's accurate, and totally reasonable. If the web is going to move forward, there needs to be a certain acceptance that older browsers should work, but they don't deserve to work well.

And definitely not as well as the latest and greatest.

The target market is for library/framework authors, especially those wishing to make polyfills for future layout algos that haven't been adopted by everyone else yet.

Most things should be within the same ballpark. The trouble is at the moment that CSS polyfills are an order of magnitude (or two) off native performance. Example: Current CSS layout polyfills (like grid, regions etc) suffer from this.

Where you will see performance improvements is when developers create more expressive layouts/paints/etc. For example you can implement a grid layout with a bunch of nested flexboxes. You could also do it with the CSS Layout API. Because by using the CSS Layout API requires fewer divs, and maybe no N^2 layout passes, chances are it'll be faster.

But this really gets at the point of Houdini is to inform browsers/specs what is important. If a grid/masonary polyfill becomes widely used, then it will help inform CSS work.

What we need is a "strict mode" HTML. Number of APIs available to web platform is getting out of hand. Using ES6 module system we can clean up the web API landscape.

Here is the idea: you declare your document to be in strict mode:

    <!DOCTYPE strict>

In this mode you don't have access to any API unless you import it. You need to import CSS layout systems like regular box model or basic APIs like query selector. You also need to import each html element you use. This way browsers don't have to take into account every possible CSS property or html element when doing layout or painting.

After we got that, then you can import your own implementation of standard modules that is written using APIs introduced by Houdini

Here is an example:

    import "html/div"
    import  "css/flex"
    import  "dom/query"

> After we got that, then you can import your own implementation of standard modules that is written using APIs introduced by Houdini

Reinventing the platform using JavaScript in that way is not going to be good for performance. At least right now, until at the very least shared memory multithreading is available.

I also want to call attention to this:

> This way browsers don't have to take into account every possible CSS property or html element when doing layout or painting.

But in order to get good performance we want to take every possible CSS property into account. Performance is about being able to make simplifying assumptions (especially on the GPU, where state changes are costly). We want to make global optimizations based on the contents of the whole page instead of having everything painted using programmatic APIs, which are black boxes to us.

Maybe we should just transpile Flash into ASM.js and be done with it.

And yes, I am being sarcastic here. I understand the motivation underpinning such projects, but the approach of introducing yet another complicated API with dubious cross-browser support is not something that will move the web forward in a meaningful way.

Behold the inexorable advance of the Atwood Law.

Next step would be having an ability to entirely reprogram the layout engine in newly-performant JS. And then more and more, until we have built an entire OS (again).

See HTML5 canvas.

That's what Google Docs switched to so they could guarantee a consistent UI across different browser platforms.

For the full OS implementation see NodeOS and Runtime.js. NodeOS is a V8 runtime built on top of a very minimal linux kernel. Runtime.js is a full OS implementation from scratch written entirely in Javascript.

Quick question, what's to stop someone from reimplementing, say "float: right" to also spin up a banner ad? That is, this sounds great in principal but much like Microsoft's Tay taught us, the internet is full of *-holes.

Well that's already possible now just by reading the CSSOM and patching new things into the DOM like how the article described the current state of affairs. If you just want to shunt another banner ad in there, that's not something that will hurt performance too much.

I'd expect that anyone who has access to the page/app enough to extend CSS to spin up ads would also have enough access to the app/page to just put ads on it anyway, in much easier ways.

I'm not sure I understand the question. Are you suggesting that someone might use this tech to bypass adblockers by integrating ads into a CSS property? Or is it something else?

Currently, custom web components don't have a way to add styling hooks specific to the component, so solutions include hacks to pipe styles into the guts of the web component, or use pre-defined attributes to style the component, just like the late 90s. Perhaps Houdini would provide a way to give custom web components first class css styling.

Seems like a band-aid for CSS, which needs to go away. Styling the DOM in the fashion we have been for the last 15+ years needs to end. JavaScript has evolved, but we still need to use LESS and SASS and Modernizr and other tools.

CSS doesn't need abstractions. It needs to be replaced.

It does not need to be replaced, and it's highly impractical for it to be replaced since it's such a core part of all web browsers that's not going away anytime soon.

Are you suggesting we style with JavaScript?

Flash was also once a core part of the web browsing experience.

CSS is a big warty blob, and a relic of the "semantic web."

"Styling with JavaScript" is probably too verbose of a solution, but it's one option.

I'd be curious how styling with Javascript would work. Almost every example I've ever seen of such ideas comes down to actually just writing CSS in Javascript. Which is just silly.

Right. We need a better solution. Actual inheritance would be a good step.

And you're going to have much worse performance. CSS is actually not slow for what it does.

CSS has almost nothing to do with the semantic web. It has been associated with the use of "semantic markup", but those two things are only weakly related.

In my work doing frontend web development CSS is the primary language I use. I don't use Less or SASS, I just write straightforward CSS.

The only limitation I've run up against as far as responsive styling goes was that @media queries were always scoped to the browser's width/height, and I figured I could build much more advanced layouts if I had a way of scoping styles to individual elements. It turns out that's true, I have a plugin that lets me do this, so between regular CSS and these extra 'element queries' I have no issue styling anything I want. My plugin works down including IE8, so there's nowhere I need to write CSS where I can't use it.

I'm not aware of how/why CSS needs to be fixed or replaced, it's a great solution for what it does.

What do you propose instead of CSS? When you have well written HTML, it takes surprisingly few CSS declarations to add a good style!

Most of the time when I see people complain about CSS it's because either they don't know how CSS works, or they want it to do something it wasn't designed to do in the first place.

Most of the time it's because they don't know how it works.

Lack of ability to nest rules in CSS makes it harder to organize styles. Not being able to create mixins and such makes all too easy to have to copy-paste and memorize cross-browser solutions & vendor specific rules for certain browsers.

In short, there is a lot of inefficiency with the current system that preprocessors help alleviate.

They truthfully do help alleviate such things, but none of this is impossible nor too terribly difficult to handle with plain old CSS.

Oddly enough, I've seen a number of people recently complaining about nesting in SASS claiming it creates problems. You just can't make everybody happy.

Simply indent child rules one step to the right. This even allow you to use code folding to easily see what goes with what.

Minify the code before it goes into production and you are ready to go.

Why do you need to nest things? The 'C' in CSS stands for 'cascading'.

Don't fear the cascade!

Well, it does clean up the code a bit, depending on your point of view. But it wouldn't necessarily interfere with cascade.

It's just right now, because CSS doesn't support it, that SASS code gets compiled into large selectors if you aren't careful.

It helps a little in the code organization, however, it creates new problems.

It makes deep nested code hard or impossible to reuse. It tightly couples style and markup, so a change in the latter can break the former, etc.

So while it is a nice feature to have, I'd recommend using it scarcely and with great care.

That's not a problem, that's not understanding how it works.

Any nested SCSS is impossible to reuse outside of its parent scope. If someone is using nested SCSS and expecting to reuse that code elsewhere then they are doing it wrong. It's the same problem that exists if one were to create a class as a child of an ID and then expect to use that class outside of the ID's scope.

Who needs code organization when Inspect Element gives you the filename and line-number, and all editors have Control-F :)

You can edit minified code if you've had enough coffee!

If you frequently see people not knowing how CSS works, then that could be a sign that CSS is fundamentally broken, over engineered, etc for what it does...

(rather than those devs being "stupid", "ignorant", "incompetent" etc).

Curious question from one frontend dev to another. Why don't you use Less or SASS? If server side compilation / javascript mode are a problem, you can simply set up a watch locally on your files using grunt or gulp.

I think there's a short list of situations where using a higher level language to describe CSS makes sense:

- when demonstrating a pattern present in CSS at a higher level, to educate people who write CSS

- when dealing with CSS animations where different browsers also use different properties

- when it's your job to output lots of different pieces of CSS based off the same pattern

Most of the time I'm either building new websites from scratch, or retrofitting old existing websites with responsive CSS and fixing problems. The web is written in three languages and only three languages: HTML, CSS, and JavaScript. If you're not writing one of those, you aren't writing the web. I can never be sure of the stack of the projects I'm going to be asked to fix, so if my requirement is: "Well I can fix it, but only as long as you use SASS" I'm going to be very hungry in life.

I can (and do write) CSS from my phone, tablet, and multiple computers - but if I had a SASS/Less workflow, that would severely limit the situations where I could write new code. Frontend web shouldn't need to be compiled!

Also, unless/until things like colour variables can also be used from JavaScript, I don't how useful CSS-only variables can really be.

In my experience, specializing specifically in responsive CSS - I've just never run into a situation where I needed or could make use of the features of SASS or Less (or Stylus, or others) where it didn't create more work for me, plus introduce technical debt into my projects, while simultaneously restricting which devices I could work from and on which sites I could work.

I could work that way, but I feel like I'd get 'Less' work done compared to the flexibility of pure CSS.

Frontend to frontend dev: what is it you reach for in SASS or Less that can't be done by CSS, JavaScript, and HTML?

I understand where you stand from, I've done quite a lot of work on support / upgrades of existing websites. I still think you may benefit from a workflow that uses a local build system... and once you use a build system, why not throw a preprocessor in?

I can give you an exemple of my workflow for simple websites using Gulp.js (I used to use grunt.js, but really, it's all the same)

I have a frontend folder structure that I carry around projects. There's a components folder and a build folder. The build folder is for minified files only.

The components folder is split between components of the website, a bundle folder and a common folder. So I have /frontend/bundles, /frontend/common and let's say, /frontend/core-navigation.

Under frontend/core-navigation, I have /styles (and scripts but let's ignore scripts for now). Under /styles, I have a main-menu.scss file. This allow me to have in there only the styles of the menu of the website. However, I don't want to burden this stylesheet with font-sizes, browser hacks, media queries definitions, etc.

That's where the /frontend/common/styles folder come into play. In this folder, I have a config.scss file. This is where the preprocessor really shines. All the reusable and common variables, styles and mixins are there.

Let's say $brand-color: #b41e3c; which is a blood red. Then, I have all the colors that starts from this color. The color for the titles of my website has to be the brand color but a bit lighter. That would be $light-title-color: adjust-hue(desaturate(lighten($brand-color, 20.58824%), .47553%), -4.28571deg);. Repeat for every color.

Then, I have my font variables, $text-font: 'pier sans', sans-serif; $light-weight: 300; $extrabold-weight: 800; $letter-spacing-normal: .05em;

I also have a bunch of mixins that are going to be used all over the website. @mixin icon-bag-white {@include scalable-icon-mixin('icon_bag.svg', 'common', $color: $white);} %hover-transition {transition: all #{$konstan-transition-hover}ms ease-out, z-index 1ms;} %form-label { display: inline-block; font-size: rem-calc(11); text-transform: uppercase; &.required em, .required { float: right; color: $brand-palette; } } etc.

My media queries are also all predefined. $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})"; which allow me to easily use mediaqueries this way: @media #{$xlarge-up} { /styles for xlarge-up/}

Back to frontend/core-navigation/main-menu.scss. Now that I have all those variables, I can easily style my main menu using the existing variables and styles definition that are in my config file. If I want to have a form label, I can simply @extend %form-label and I don't have to rewrite all those style definitions. I work in team with other developers, so it really help to have those definitions written only once so that we don't end up with code duplication.

All of those styles sheets are bundles under the /frontend/bundles folder. In this folder, I have multiple files filled with @import definitions. All those are bundles and using Gulp.js, I can output them wherever I want. Most of the time that's going to be under /frontend/build/stylescore.css. However, if I'm working on a CMS website, I can output the minified stylesheet in let's say, /magento/skin/styles.

I use gulp.js to minify my stylesheets, to compress my images, to generate multiple versions of my share icon for every device out there, etc.

Something really cool too is a task which write browser prefix and browser hacks for me. I simply write display: flex; and when I save the file, it's going to put display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; in the build file for me. There's one for polyfills too, so you can use rounded corners on IE7, etc.

All of my files are put under a watch task, so whenever I save a file, the workflow starts by itself. If make changes to main-menu.scss and save it, it's automatically going to minify the file and send it in the right folder. I can work as if my .scss file is a normal .css file. And the beauty of it? It's all done locally, no dependancy on a server or a backend guy. I don't need to install any php module on the server or anything. I simply throw the /build file on the production server and everything is going to work the way I want it to.

I have a similar workflow that use the same folder structure for my scripts.

That's a pretty elaborate setup.

I have my own toolbox of scripts and plugins, but they're all written in CSS, HTML, and JS. I have CSS files like http://staticresource.com/basic.css upon which I can layer other colour styles like: http://staticresource.com/template/css/themes/swiss.css

I also have plugins that I've written like http://staticresource.com/notifications.html

But this year I decided to do something crazy and put them all together in a really simple site layout: http://staticresource.com/template (source https://github.com/tomhodgins/template-factory)

In the Template Factory you can test all of the themes and the plugins, and add theme support so they work together.

For me to define a new 'brand' on top of this would just mean to author one more CSS stylesheet on top of basic.css and the various plugins used.

Still, if I've gotten this far without Less or Sass - where should I add them where it would benefit me?

I find I do end up hacking on iPad a lot, I can just write HTML, CSS, and JS and create things, then move it to a computer for further work. Here's a super simple HTML utility I made last week to help me build mailto URLS: http://staticresource.com/mailto.html It uses basic.css and the notifcations plugin, but check out the source. You could write a little HTML page like that anywhere, on any device.

For me to introduce some kind of a build process with all these different moving parts would severely restrict the situations when and where I can get work done! I'm a freelancer, I don't get paid by the hour, I get paid for the amount of value I can provide, so it's always in my be$t intere$t to break down any barrier that stops me from being able to work.

I'm able to do a surprising amount of work from mobile, despite mobile browsers lacking a lot of development features desktop browser make available. I have a little app that lets me test responsively on mobile: http://staticresource.com/speedtest.html and another that lets me view the source of any site on: http://staticresource.com/inspect/?

So for me to abandon this freedom and flexibility to only be able to work from one machine, with all these processes running and up to date sounds like a massive step back in productivity for me.

It does sound like you have a beautifully amazing system set up, but it feels full of potential points of failure that don't need to exist. If you need to update one line of text on a website, you should be able to open up a text file on any device, edit one line, and save. Having to do anything else to get something updated seems like intentionally going out of your way to create work for yourself, no?

Also, doing a lot of responsive stuff I've been turned off the idea of using pre-defined breakpoints for responsive design. Your @media (or other) queries need to respond to the elements in your layout and when you feel they need to adapt, which means those breakpoints are defined more by the design than the device. I use a solution that lets me scope responsive styles to the elements themselves, which is an even better solution for high precision responsiveness! Check out http://elementqueries.com It doesn't work so well with SASS, but here's an example of something I built with it recently: http://staticresource.com/reports.html

This design isn't responsive, it's designed to be printed 8.5x11 actually, but you'll notice in my code I have defined color variables in JavaScript and used them both in the JavaScript I send off to Google Charts, as well as in my styles. You wouldn't be able to do that with SASS/Less variables, but this is a real-world use case where I thought using variables might be better than not using them :)

I like all those tools, plugins, etc. you have going. They are great.

As for the build system that I use, I can update it via the command line and I can also install it on any machine via npm install. I do agree that with this, I couldn't work on an iPad, but I have that 11inch macbook air for that job already.

Here's the open sourced version that is the base of my workflow (this one is the one we use where I work, my own is a bit simpler but based on the same concepts). Take a look: https://github.com/absolunet/nwayo/tree/master/src

As for the breakpoints, I use the variables as a starting point (small mobile, large mobile, tablet, desktop, big desktop, etc.) but do end up using hardcoded breakpoints for small components or in betweens.

edit: Mail me if you want to chat more, contact info in profile!

- Importing modules with zero performance impact. - Variables! Think how they help you in other languages. $primary is much more readable than some random hex code. - Functions! darken($primary, 10%), again much more readable than hex codes. - Helps avoiding duplication through several means, like mixins, loops and so on. - Forever forgetting vendor prefixes and effortlessly keeping up to date. - Creating sprites or base64 images automatically, never having to "craft" those by hand ever again.

The list goes on and on. And the best thing, SCSS and Less are CSS backwards compatible, so you can choose whatever features you want and pretend you're writing just CSS.

I was super anti-preprocessors for pretty much the same reasons you are. But the one day I tried them out and never looked back.

Ignore gulp, grunt, webpack and whatever people tell you to use. Start super easy, with just the "compiler", and once something annoys you, look for a solution.

Also pick up the features you want. I started using only variables and ignored the rest, and added more tricks to my repertoire as needed.

If you target IE, sure. But that's hardly a fault with CSS.

Every replacement I've seen proposed for CSS has been worse. CSS has tons of mistakes, but the common complaints people have with it are mostly just fundamental tradeoffs CSS made and aren't fixable by just complaining--we need real proposals, ones that understand deeply how CSS is the way it is and how it works at an implementation level.

I think it's not very exciting at all. Browser support for Houdini will be a new issue in the future if they manage to release anything.

XKCD 927.

https://xkcd.com/927/ For the lazy

Great! But sadly, I must keep working with IE8 compatibility. Government related clients update at glacial speed...

Government contractor here on site at somewhat large gov't facility, we're fully updated to IE11 on Win 7 now. Before that, we had a lot of people on IE9.

Microsoft support end dates are darn helpful. Kicks people into gear.

Yeah... Microsoft standing firm on support dates and actively encouraging people to upgrade seems to have really made a huge difference. I'm sure it also makes them a pretty penny to maintain support contracts for entities that refuse to upgrade past the official EOL.

Microsoft engineer here. I would assert we want people upgraded more than anybody else on the planet. Our extended support contracts were designed to be cost prohibitive to encourage this point and were nowhere near a money-making venture. The engineering matrix (cost) for a fix across old versions was insane: IE6, 7, 8, 10, 10 touch; 32bit, 64bit, ARM; Windows XP, Vista, 7, 8, Server, Mobile, etc.; 5.5/7/8/9/10 browser document modes; etc. A "single" fix often meant weeks of porting work for engineers after the initial fix was written.

Note that the Jan 12, 2016 End of Support date means there are no more security updates, non-security updates, free or paid assisted support options, or online technical content updates. https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-I...

Reply on news.ycombinator.com