21–30 of 63 posts
Great! But sadly, I must keep working with IE8 compatibility. Government related clients update at glacial speed...
Microsoft support end dates are darn helpful. Kicks people into gear.
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.
Earlier quoted context omitted.
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).
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?
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.
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!
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.
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.
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…
Most of the time it's because they don't know how it works.
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.
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…
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.
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.