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

A couple CSS tricks for HTML Dialog elements

cassidoo.co

Post reply on HN
Print view View original

31–40 of 48 posts

Re: A couple CSS tricks for HTML Dialog elements

#31

Post by pseudosavant »

hk1337 wrote: post #11

datalist is one I stumbled upon and blew me away. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... It's not a replacement for select as you still need an input to tie it to but it seems to handle filtering a list of options nicely. Also, if you have two selects with the same list in it, you can do it once with datalist and have two inputs, say a list of clients with client_a and client_b for inputs. I…

What a great find! I'll definitely be thinking through where this is appropriate to use.

Re: A couple CSS tricks for HTML Dialog elements

#32

Post by extra88 »

cmgriffing wrote: post #30

Be careful using: dialog::backdrop { backdrop-filter: blur(2px); } If there is frequently updating content on the page like a video, it can kill CPU performance. Restream does this and it punishes my M3 macbook air. It seems you can use the transform3d trick to kick it to the GPU to help fix it.

I'd want to pause any video playing while a dialog with such a backdrop is open.

Re: A couple CSS tricks for HTML Dialog elements

#33

Post by extra88 »

no_wizard wrote: post #26
todotask wrote: post #10

Earlier quoted context omitted.

I still can see my scrollbar and scroll with inert?

Its intended to stop interaction[0] of background elements. It can be used as part of the solution to stop the background scrolling. Per MDN When implementing modal dialogs, everything other than the and its contents should be rendered inert using the inert attribute. [1] `body[inert] { overflow: hidden; }` This would be better, and is what I was getting at. I can't edit the other comment unfortunately. [0]: https://…

Your original message was "Inert should be used instead of overflow" which is incorrect because `inert` doesn't affect scrolling of the viewport. Your CSS rule example is a good way to demonstrate using the presence of an `inert` attribute on the body to determine when `overflow: hidden` should be applied to the body.

That section of the MDN article is somewhat confusing but if the dialog is opened using the `.showModal()` method, there's no need to add an `inert` attribute yourself, the browser automatically makes the rest of the page inert.

If a that's meant to be modal is opened not using `.showModal()`, say by making it a `popover` and the `popovertarget` of a button, then you might set `inert` yourself (and remove it when the is closed). However, you can't simply do if that is inside the because then the dialog itself would be inert.

Re: A couple CSS tricks for HTML Dialog elements

#34

Post by spartanatreyu »

bargainbin wrote: post #27
lelandfe wrote: post #21

Earlier quoted context omitted.

My frown continues to deepen at Apple's UI backslide as they crib more and more junk from iOS/iPadOS. I'm on Sonoma 14.5, and this is Safari 17.5. macOS Safari's : https://imgur.com/a/05YWDCc macOS Safari's : https://imgur.com/a/4f3JwuA There are SO, SO, SO many things wrong with Safari's datalist element here. Esc doesn't close it (close from keyboard by switching tabs...). There's no hover effect on the options. Th…

It does make you wonder, Safari recently had a burst in features where they modernised and even overtook Chromium/FF in some features, and then in the past year or so it’s languishing again. I do wonder if the metrics show the average person downloads Chrome straight away so they’re just not investing heavily in it? I mean anyway, who browses traditional websites any more, right…?

They've purposefully underinvested in Safari to force developers to create native apps for their platforms where Apple makes a sizeable cut of all sales and subscriptions rather than allowing developers to create a web-app that could have done the same thing where the developers reap all the rewards for their work.

The only reason they had that burst of activity is that they needed to quickly catch up and save face in an attempt to prove to EU regulators that they weren't hampering developers.

The EU didn't buy it and forced Apple to open up their devices to allow alternate app stores and browsers on their devices in the EU.

Re: A couple CSS tricks for HTML Dialog elements

#35

Post by andrewmcwatters »

dsmmcken wrote: post #19
KTibow wrote: post #3

Earlier quoted context omitted.

Website authors can set a scrollbar gutter.

scrollbar-gutter: stable; to those unfamiliar. https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...

Man, this makes me feel old.

Re: A couple CSS tricks for HTML Dialog elements

#36

Post by extra88 »

dimaor wrote: post #28

Is it weird that I expected the post to actually have running examples?

From the article:

> If you want to see a decent quick example of them in action, you can check out my game Jumblie and click the Settings gear button at the top.

It has the backdrop filter but it doesn't prevent page scrolling.

BTW, MDN's data on Safari's support for the unprefixed `backdrop-filter` property is wrong, it still sometimes requires using `-webkit-backdrop-filter` (works in iOS Safari 18.2.1, doesn't work in Safari 18.2 on macOS 14.7.1).

Re: A couple CSS tricks for HTML Dialog elements

#38

Post by no_wizard »

extra88 wrote: post #33
no_wizard wrote: post #26

Earlier quoted context omitted.

Its intended to stop interaction[0] of background elements. It can be used as part of the solution to stop the background scrolling. Per MDN When implementing modal dialogs, everything other than the and its contents should be rendered inert using the inert attribute. [1] `body[inert] { overflow: hidden; }` This would be better, and is what I was getting at. I can't edit the other comment unfortunately. [0]: https://…

Your original message was "Inert should be used instead of overflow" which is incorrect because `inert` doesn't affect scrolling of the viewport. Your CSS rule example is a good way to demonstrate using the presence of an `inert` attribute on the body to determine when `overflow: hidden` should be applied to the body. That section of the MDN article is somewhat confusing but if the dialog is opened using the `.showMo…

I was on mobile. I apologize my comment was insufficient

Re: A couple CSS tricks for HTML Dialog elements

#39

Post by FrostKiwi »

spartanatreyu wrote: post #34
bargainbin wrote: post #27

Earlier quoted context omitted.

It does make you wonder, Safari recently had a burst in features where they modernised and even overtook Chromium/FF in some features, and then in the past year or so it’s languishing again. I do wonder if the metrics show the average person downloads Chrome straight away so they’re just not investing heavily in it? I mean anyway, who browses traditional websites any more, right…?

They've purposefully underinvested in Safari to force developers to create native apps for their platforms where Apple makes a sizeable cut of all sales and subscriptions rather than allowing developers to create a web-app that could have done the same thing where the developers reap all the rewards for their work. The only reason they had that burst of activity is that they needed to quickly catch up and save face i…

> They've purposefully underinvested in Safari to force developers to create native apps for their platforms where Apple makes a sizeable cut

Can't speak to how accurate this is, but for WebXR, this hits the nail on the head. Purposeful stagnation on supporting it and thus indirectly bringing down the whole point of the standard, pushing of their own AppStore bound ARKit, and when they released Apple Vision Pro it's magically supported again, because I guess they needed content that badly.

Re: A couple CSS tricks for HTML Dialog elements

#40

Post by [deleted] »

FrostKiwi wrote: post #39
spartanatreyu wrote: post #34

Earlier quoted context omitted.

They've purposefully underinvested in Safari to force developers to create native apps for their platforms where Apple makes a sizeable cut of all sales and subscriptions rather than allowing developers to create a web-app that could have done the same thing where the developers reap all the rewards for their work. The only reason they had that burst of activity is that they needed to quickly catch up and save face i…

> They've purposefully underinvested in Safari to force developers to create native apps for their platforms where Apple makes a sizeable cut Can't speak to how accurate this is, but for WebXR, this hits the nail on the head. Purposeful stagnation on supporting it and thus indirectly bringing down the whole point of the standard, pushing of their own AppStore bound ARKit, and when they released Apple Vision Pro it's…

[deleted]
Post reply on HN