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

21–30 of 48 posts

Re: A couple CSS tricks for HTML Dialog elements

#21

Post by lelandfe »

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…

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. 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 element looks: https://imgur.com/a/Vpu536j

And this is : 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.

Re: A couple CSS tricks for HTML Dialog elements

#22

Post by Lvl999Noob »

skgough wrote: post #20
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_...

In addition to `position: fixed`, shouldn't it be top, left, height, width, instead of top, left, bottom, right? In the second case, it would follow the top and left instructions then take the necessary amount of space, ignoring right and bottom?

Re: A couple CSS tricks for HTML Dialog elements

#24

Post by hk1337 »

lelandfe wrote: post #21
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…

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…

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.

Re: A couple CSS tricks for HTML Dialog elements

#25

Post by culi »

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.

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

Re: A couple CSS tricks for HTML Dialog elements

#26

Post by no_wizard »

todotask wrote: post #10
no_wizard wrote: post #9

Earlier quoted context omitted.

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

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

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

Re: A couple CSS tricks for HTML Dialog elements

#27

Post by bargainbin »

lelandfe wrote: post #21
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…

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

Re: A couple CSS tricks for HTML Dialog elements

#29

Post by nicoburns »

Lvl999Noob wrote: post #22
skgough wrote: post #20

Earlier quoted context omitted.

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

In addition to `position: fixed`, shouldn't it be top, left, height, width, instead of top, left, bottom, right? In the second case, it would follow the top and left instructions then take the necessary amount of space, ignoring right and bottom?

For absolutely positioned elements, if you set all four sides then the height and width will be automatically computed.

Re: A couple CSS tricks for HTML Dialog elements

#30

Post by cmgriffing »

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.

Post reply on HN