A couple CSS tricks for HTML Dialog elements • Hacker News Board

Re: A couple CSS tricks for HTML Dialog elements

#11

Post by hk1337 » Tue, Jan 14, 2025, 4:34 PM UTC

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 don't quite care for how it displays the value, like if you put the ID as the value and the client name in the option element, you can filter by the ID or the name but the input will show the ID only.

Re: A couple CSS tricks for HTML Dialog elements

#12

Post by askew » Tue, Jan 14, 2025, 4:37 PM UTC

starikovs wrote: post #6

Thanks for the article! I remember I had a hard time trying to stretch dialog to full screen for mobile devices, but it actually didn't want to work. The code was something like this: dialog { position: absolute; top: 10px; right: 10px; bottom: 10px; left: 10px; }

You can shorthand the last four declarations with a single `inset: 10px;` (or maybe `inset: .625rem;`?

Re: A couple CSS tricks for HTML Dialog elements

#13

Post by kevinsync » Tue, Jan 14, 2025, 4:51 PM UTC

simonw wrote: post #8

This is a neat piece of modern CSS: body:has(dialog[open]) { overflow: hidden; } https://caniuse.com/css-has confirms the has() selector has had widespread browser support since December 2023.

YMMV / be careful with this, body:has() and html:has() can be extremely expensive (and introduce severe lag visible to the user) if you have dynamic components on the page that are constantly altering the DOM (ex. react/vue apps)

Re: A couple CSS tricks for HTML Dialog elements

#14

Post by bob1029 » Tue, Jan 14, 2025, 4:55 PM UTC

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…

I've tried using datalist with text inputs and it never quite worked out from a UX perspective. Users would always complain about weird quirks with how it populates & clears values. A normal element with an "Other" option + conditional input element is much more predictable.

Re: A couple CSS tricks for HTML Dialog elements

#15

Post by hk1337 » Tue, Jan 14, 2025, 5:06 PM UTC

bob1029 wrote: post #14

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…

I've tried using datalist with text inputs and it never quite worked out from a UX perspective. Users would always complain about weird quirks with how it populates & clears values. A normal element with an "Other" option + conditional input element is much more predictable.

Yeah, for autocomplete it has a weird UX feel to it.

Some of the other examples like using it with the slider and the color picker seem like they're useful.

Re: A couple CSS tricks for HTML Dialog elements

#16

Post by [deleted] » Tue, Jan 14, 2025, 5:20 PM UTC

rado wrote: post #5

Freezing the page isn't so simple, as overflow: hidden messes up things like the sticky header on that page. I had so much trouble with it, I decided to just let users scroll and hide the modal during scrolling: https://radogado.github.io/n-modal/

[deleted]

Re: A couple CSS tricks for HTML Dialog elements

#17

Post by SquareWheel » Tue, Jan 14, 2025, 5:22 PM UTC

simonw wrote: post #8

This is a neat piece of modern CSS: body:has(dialog[open]) { overflow: hidden; } https://caniuse.com/css-has confirms the has() selector has had widespread browser support since December 2023.

I used this same approach in a recent web app and it worked great. You can also use scrollbar-gutter: stable, which disables scrolling but maintains the preserved space to avoid content reflows.

Re: A couple CSS tricks for HTML Dialog elements

#18

Post by stronglikedan » Tue, Jan 14, 2025, 5:25 PM UTC

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…

It looks like the UI would clash with the browser's autofill recommendations.

Re: A couple CSS tricks for HTML Dialog elements

#19

Post by dsmmcken » Tue, Jan 14, 2025, 5:27 PM UTC

KTibow wrote: post #3

vintagedave wrote: post #2

The trick to prevent scrolling by setting overflow: hidden unfortunately results in visual page jumping for me. The reason is I have macOS set up to always show scroll bars, instead of hiding them. At least one browser (I forget which, but I test on Safari, Firefox and Chrome) doesn’t have a disabled scroll bar but removes it altogether. This makes the page wider and causes it to reflow and move. Does anyone know how…

Website authors can set a scrollbar gutter.

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

Re: A couple CSS tricks for HTML Dialog elements

#20

Post by skgough » Tue, Jan 14, 2025, 6:25 PM UTC

starikovs wrote: post #6

Thanks for the article! I remember I had a hard time trying to stretch dialog to full screen for mobile devices, but it actually didn't want to work. The code was something like this: dialog { position: absolute; top: 10px; right: 10px; bottom: 10px; left: 10px; }

this is most likely due to the absolute positioning. position: absolute will use the top-left corner of the closest ancestor that is "positioned" as the origin for it's layout [1]. If you want that origin to be the top-left corner of the viewport, use position: fixed.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_...