remix logo

Hacker Remix

A couple CSS tricks for HTML Dialog elements

162 points by surprisetalk 1 week ago | 45 comments

hk1337 4 days ago

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.

lelandfe 4 days ago

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 <select>: https://imgur.com/a/05YWDCc

macOS Safari's <datalist>: 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. The active background color is more saturated than the system's accent color (typical for iPadOS/Catalyst junk). There's no left/right margin, and no border radius, on the options. Option text isn't vertically centered. The font is different (it seems differently aliased? Perhaps just larger). The datalist element itself lacks the same border-radius of select. On select elements, selection does not wrap (down arrow with the last option active); on datalist it does.

Here's an egregious one - when you zoom in with Cmd-+ a few times, this is how the <select> element looks: https://imgur.com/a/Vpu536j

And this is <datalist>: https://imgur.com/a/JrfXLW9

Argh! I used to revere Apple for sweating the details. Their UI/UX quality inspired me to become a frontend dev.

Today, they ship things that wouldn't pass Q/A at my worst jobs.

bargainbin 4 days ago

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…?

spartanatreyu 4 days ago

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.

FrostKiwi 4 days ago

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

hk1337 4 days ago

Yeah, the more I dig into it the more I see it's not all that great. It has some potential for some things but not necessarily for an autocomplete list.

https://jsfiddle.net/nhu4zef2/

This is one occurs in every browser when if you want to have a list but send the ID for the item instead of the value, it shows the value in the list and you can search by the ID or the value but the result in the input shows just the ID. User's should be not be required to know the ID of something. Like say a list of clients where user's know them by name but necessarily by ID but the database links them by ID.

lelandfe 4 days ago

This just got so much worse with scrollbars.

Select: https://imgur.com/a/fi1SPBJ

Datalist: https://imgur.com/a/sTiQhPF

This looks exactly like an iOS control now. The multiply effect on the scrollbar is comically out of place.

bob1029 4 days ago

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 <select> element with an "Other" option + conditional input element is much more predictable.

hk1337 4 days ago

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.

Sateeshm 14 hours ago

Doesn't seem to work on Firefox Android

pseudosavant 4 days ago

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

vintagedave 1 week ago

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 to keep the scroll bar onscreen, just not enabled?

andrewmcwatters 4 days ago

It's been a while since I've tested this, but an explicit overflow-y: scroll used to keep the scrollbar there, so that when you needed to change the property, the user-agent controls wouldn't pop in or out.

badlibrarian 4 days ago

yes, "html { overflow-y: scroll }" works.

KTibow 1 week ago

Website authors can set a scrollbar gutter.

dsmmcken 4 days ago

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

andrewmcwatters 4 days ago

Man, this makes me feel old.

culi 4 days ago

This is only recently supported by all major browsers thanks to the interop efforts. pre-2024 browser versions will not support this

rado 4 days ago

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/

simonw 4 days ago

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.

kevinsync 4 days ago

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)

no_wizard 4 days ago

Inert should be used instead of overflow. Achieves the same thing but is also compliant with accessibility in a way overflow isn’t

todotask 4 days ago

I still can see my scrollbar and scroll with inert?

no_wizard 4 days ago

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 <dialog> 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://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

extra88 4 days ago

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 <dialog> 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 <dialog> is closed). However, you can't simply do <body inert> if that <dialog> is inside the <body> because then the dialog itself would be inert.

no_wizard 4 days ago

I was on mobile. I apologize my comment was insufficient

SquareWheel 4 days ago

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.