Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Houdini: Maybe the Most Exciting Development in CSS

smashingmagazine.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Houdini: Maybe the Most Exciting Development in CSS

#41

Post by gtjrossi »

ZenoArrow wrote: post #9
pcwalton wrote: post #4

> 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, becau…

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

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

Re: Houdini: Maybe the Most Exciting Development in CSS

#42

Post by gtjrossi »

JoblessWonder wrote: post #34
michaelbuddy wrote: post #21

Earlier quoted context omitted.

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

Re: Houdini: Maybe the Most Exciting Development in CSS

#43

Post by mindcrime »

debacle wrote: post #19
davidkpiano wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#44

Post by msoad »

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:
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"

Re: Houdini: Maybe the Most Exciting Development in CSS

#45

Post by colordrops »

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#46

Post by err4nt »

Bahamut wrote: post #32
talmand wrote: 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.

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

Don't fear the cascade!

Re: Houdini: Maybe the Most Exciting Development in CSS

#48

Post by err4nt »

Raphmedia wrote: post #40
err4nt wrote: 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…

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?

Re: Houdini: Maybe the Most Exciting Development in CSS

#49

Post by EvanPlaice »

nine_k wrote: post #47

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.

Re: Houdini: Maybe the Most Exciting Development in CSS

#50

Post by hencq »

pcwalton wrote: post #29
ZenoArrow wrote: post #23

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…

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