[HN Gopher] A couple CSS tricks for HTML Dialog elements
___________________________________________________________________
A couple CSS tricks for HTML Dialog elements
Author : surprisetalk
Score : 120 points
Date : 2025-01-11 00:59 UTC (3 days ago)
(HTM) web link (cassidoo.co)
(TXT) w3m dump (cassidoo.co)
| vintagedave wrote:
| 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?
| KTibow wrote:
| Website authors can set a scrollbar gutter.
| dsmmcken wrote:
| scrollbar-gutter: stable; to those unfamiliar.
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/scrollbar-g...
| culi wrote:
| This is only recently supported by all major browsers thanks
| to the interop efforts. pre-2024 browser versions will not
| support this
| andrewmcwatters wrote:
| 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 wrote:
| yes, "html { overflow-y: scroll }" works.
| rado wrote:
| 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/
| starikovs wrote:
| 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; }
| askew wrote:
| You can shorthand the last four declarations with a single
| `inset: 10px;` (or maybe `inset: .625rem;`?
| skgough wrote:
| 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_...
| Lvl999Noob wrote:
| 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?
| nicoburns wrote:
| For absolutely positioned elements, if you set all four
| sides then the height and width will be automatically
| computed.
| simonw wrote:
| 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.
| no_wizard wrote:
| Inert should be used instead of overflow. Achieves the same
| thing but is also compliant with accessibility in a way
| overflow isn't
| todotask wrote:
| I still can see my scrollbar and scroll with inert?
| no_wizard wrote:
| 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...
| kevinsync wrote:
| 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)
| SquareWheel wrote:
| 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.
| hk1337 wrote:
| 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.
| bob1029 wrote:
| 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 wrote:
| 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.
| stronglikedan wrote:
| It looks like the UI would clash with the browser's autofill
| recommendations.
| lelandfe wrote:
| 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.
| hk1337 wrote:
| 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.
| bargainbin wrote:
| 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...?
| pseudosavant wrote:
| What a great find! I'll definitely be thinking through where
| this is appropriate to use.
| Alifatisk wrote:
| A demo of each trick would be nice to see
| dimaor wrote:
| Is it weird that I expected the post to actually have running
| examples?
| cmgriffing wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-14 23:00 UTC)