Hacker News Reader

Comment by vagrantJin | Hacker News Reader

I feel like I work on a different web.

> Note: With great power comes great responsibility! With Houdini you could invent your own masonry, grid, or regions implementation, but doing so is not necessarily the best idea. The CSS Working group does a lot of work to ensure every feature is performant, handles all edge cases, and considers security, privacy, and accessibility.

Sounds like a lot of work to display a bloody list.

View on HN

My understanding is that these Houdini features are aimed more at big library/framework authors. It's not for "every day users".

It's more expected that you'll use things that use Houdini under the hood as an implementation detail.

A new layout mode (like CSS Grid) isn't available yet? This allows someone to write a polyfill for it. That's neat!

> A new layout mode (like CSS Grid) isn't available yet? This allows someone to write a polyfill for it. That's neat!

this was my first thought, too. We have polyfills for js features that don't yet exist in a lot of browsers, but polyfills for css are either very complicated or just don't exist in some cases.

Will there be a JS polyfill for Houdini?

Probably not a practical one, for the same reasons that discourage CSS polyfills. I think this feature is aimed not at developers who have to support legacy browsers but those who want to use newer CSS standards in self updating browsers without having to wait for the laggards. Safari is (was?) often criticized for being very slow to implement adopted CSS standards so that might have been the impetus. Once Houdini Paint/Layout/Animation APIs lands and enough clients update, devs can switch to Houdini and use any new/experimental CSS standards that has an open source implementation.

https://github.com/GoogleChromeLabs/css-paint-polyfill

Seems there is for parts of it already

> A new layout mode (like CSS Grid) isn't available yet? This allows someone to write a polyfill for it. That's neat!

Hopefully this won't be used as an excuse for new standards proposals to never move forward and/or browser teams to slow-roll implementing new standards natively..

> Sounds like a lot of work to display a bloody list.

UI is complex? Who knew!

If <ul> meets the needs of your application, there's no reason you'd have to do more work than that.

Masonry is a <ul>.

https://www.youtube.com/watch?v=1W79T2ibd5Y

Sounds like possible security and privacy nightmare for users

I constantly wonder why so much work on CSS and absolutely zero work on implementing basic primitives like <input type="slider" min="0" max="1000" step="10"> and <input type="toggle"> and <tabviewpager><tab></tab><tab></tab></tabviewpager> and <input pinchzoom="true" src="foo.jpg"> and other utterly basic UI elements with full support for swipe gestures.

It's 2021 and people still do div and javascript hell to implement these things.

There are primitives like that, such as https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

There's even a color picker in native html now.

Oh cool! maybe they are finally getting with the beat.

What about spinners, pull to refresh and other things ... would be nice to standardize all of these such that they display with your system's native widgets. The code for those CSS spinners is horrifying spaghetti code whereas I should be able to just do <spinner> and get an Android native spinner on Android and an iOS native spinner on iOS.

input types like range were introduced in 2014, here's a tutorial from then: https://css-tricks.com/datalists-different-input-types/

I think I get the point you're trying to make, and I find it difficult that someone could make a list of all the things that "should be in by default" vs providing the building blocks.

Maybe they could just start by providing all the Android layout XML components as native in HTML6?

your response suggests that you think that the list needs to be 100% consistent with the shape of reality at all times, but the reality of it is that standards are fluid things and they are developed and honed iteratively in response to the pressures that gave rise to their existence in the first place. it's less about trying to make sure to accommodate every last possibility, and more about making sure to provide a reasonably fundamental and useful set of resources that can be used in union to build the more complex ones. the map of absolute choices is not the terrain of contextual variation and nuance, and there's no reason to ever expect a 100% concordance because a 1:1 map is basically equivalent to directly experiencing noumena and seeing past qualia, and that's just not usually a thing that is, by definition, directly apprehended, but rather indirectly inferred from the phenomena that result from interpreting it.

tl;dr they'll get it in the next patch

Most of these inputs are very limited though. For example, range only allows one handle, so it doesn't work in most instances. For example, you might want a slider for a range of prices ($10-20), sizes (TVs that are 32-40"), or dates (products released between 2010-2013). It doesn't work in these situations, which is disappointing because they seem like the most basic use cases.

It's a start at least. And I also find hardly anyone ever uses them because they want their UI to match. I still like that I can quickly whip up form validation and some controls with just html.

Have you seen lion[0]? It is a stylable/white label set of web components. It also has a switch/toggle.

[0]https://lion-web.netlify.app/components/interaction/switch/o...

Yeah, I mean there are lots of web components out there, but under the hood they are div hell and css hell.

"npm i --save @lion/input-amount"

This isn't directed at you, but I shouldn't have to use npm to build a webpage. Also, building web components out of css/div hell severely impacts performance when you have a long scrollable list of them.

And most of these web components might look nice but they don't support native touch/swipe gestures in exactly the same way that the OS does.

I tried the Lion tabs component on my phone and I can't swipe between tabs. Probably the most utterly basic UI gesture. Fail.

> but under the hood they are div hell and css hell.

And? That's what all the "native" web inputs are as well.

It’s not, and hasn’t been since at least ES6 and the engine normalization’s that came with that leap (DOM APIs got normalized in that transition across browsers)

Web components is one way to add re-usable functionality naked into modern browsers. There is also a slew of new elements nobody seems to use for no good reason like: picture, figure, section, article, main, header, footer, the new input types, details and I’m sure I’m missing more.

Why does this industry think it’s okay to just be well educated with JS but doesn’t care that developers also know CSS and HTML just as well, I’ll never know

There's now an attempt being made to start an exploration into this: https://open-ui.org

I wouldn't hold my breath though.

Reply on news.ycombinator.com