Live data from Hacker News

Houdini: Maybe the Most Exciting Development in CSS

smashingmagazine.com

31–40 of 63 posts

Re: Houdini: Maybe the Most Exciting Development in CSS

#31

Earlier quoted context omitted.

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…

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#32
post #27
post #24

Earlier quoted context omitted.

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 tru…

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#33
post #28
post #19

Earlier quoted context omitted.

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#34

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#35
post #2

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 langu…

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#36
post #16

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.

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#37

Earlier quoted context omitted.

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…

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…

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

Re: Houdini: Maybe the Most Exciting Development in CSS

#38
post #32
post #27

Earlier quoted context omitted.

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#39
post #32
post #27

Earlier quoted context omitted.

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.

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#40
post #24
post #16

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.

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 tru…

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.
Post reply on HN