6 ms·

It doesn't seem to prevent scrolling? https://jsfiddle.net/46nha7v3/ https://jsfiddle.net/46nha7v3/ I enjoy native elements when they are there. You can do re

by mg 4y ago

It doesn't seem to prevent scrolling? https://jsfiddle.net/46nha7v3/ https://jsfiddle.net/46nha7v3/ I enjoy native elements when they are there. You can do really nice interactive trees with the <details> element for example: https://twitter.com/marekgibney/status/1593950777739218947 https://twitter.com/marekgibney/status/1593950777739218947 But I am not sure if it is a good idea to bake more and more of them into the browsers. Couldn't well made JavaScript modules provide the same functionality without making browsers more and more complex?

AprilArcus 4y ago
Try this: body:has(dialog[open]) { overflow: hidden } body:has(dialog[open])::before { content: ""; position: fixed; top: 0; left: 0; width: 100%; height: 100%; backdrop-filter: blur(4px); background-color: rgb(0, 0, 0, 0.5); }
- mg 4y ago
  Have you tried it? Here in Firefox, it does not work. https://jsfiddle.net/t34wz6kx/ https://jsfiddle.net/t34wz6kx/ Also, using "position: fixed" will fail when the dialog is longer than the screen. Then the user cannot read it all, and if the close button is at the bottom, they cannot close it.
  - karlshea 4y ago
    Firefox also doesn't support :has. There's some more information on MDN [0] about how to make a modal dialog, you can open one in JavaScript using showModal() which has a backdrop, is actually modal, etc. [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
    - mg 4y ago
      Nice! https://jsfiddle.net/5gevzft8/1/ https://jsfiddle.net/5gevzft8/1/ Looks like you cannot use a button in the dialog then though. As it somehow makes the dialog scroll to the bottom.
      - derefr 4y ago
        Your "cannot use" is my "element has proper accessibility consideration for people who are viewing the dialog inside a webview that disables scrolling." With the buttons always starting in scrolled-into-view and in focus, those people can at least dismiss the modal!
      - MrJohz 4y ago
        This is the spec behaviour - the browser focus should immediately jump to the first focusable item in the page for accessibility reasons. (As I understand it, this is the norm for dialogs outside the browser.) My understanding is that you should be doing two things here: firstly, dialogs shouldn't generally be scrollable by themselves (or if they are, the interaction buttons should be sticky so that they're always visible). Instead, if you've got long text (say T&Cs) that should be in a scrollable box of its own. This allows the user to see the whole dialog (interactions and all) at once. Secondly, if there is something that should take focus before the buttons do, then you should set autofocus on that element explicitly. So in this case, you'd wrap the long text in a scrollable div, and add an "autofocus" attribute to that div to ensure that keyboard based users will immediately jump to it and be able to scroll it with their keyboard.
irrational 4y ago
I’m the opposite. I don’t want to have to use any third party code, libraries, frameworks, etc. I want it all in the standard library.
- simultsop 4y ago
  same here, it also bugs me when a language needs a framework then it needs a transpiler than an ide extension than a course to learn well how to align all ecosystem properly since standard not enough to give credit/satisfaction to all involved in dev :(
  - zdragnar 4y ago
    This is how we end up with insufferable things like type "number" inputs and alert and most of the other baked in things. They're halfway to what you want but can't go further because everyone has slightly different needs and browsers are already complex enough without baking in prebuilt components for everything from data tables to carousels to modals to drop-down menus. Also, the list of things that bug you that a language needs describes pretty much every programming language in existence.
    - badsectoracula 4y ago
      > Also, the list of things that bug you that a language needs describes pretty much every programming language in existence. The bit about ecosystem and the context on JavaScript makes me certain he meant external needs - in other words he'd like "batteries to be included". There are several languages that come with a lot of stuff out of the box.
- sgt 4y ago
  That's not the reality of modern web development in the last 10+ years though.
  - wildrhythms 4y ago
    Yes, and that has led to how many thousands of hours of developer time wasted building these things custom for their app (or trying to find some minimally invasive library to do it). Bring on the dialog element. Maybe we can get the ability to custom style select inputs next.
Jaxan 4y ago
Maybe it’s good not to prevent scrolling. I have had many situations where there was a non-scrollable modal dialogue and the buttons were off-screen (my phone has a small screen). So the website became completely unusable.
- derefr 4y ago
  It shouldn't necessarily prevent scrolling; but I'd expect scrolling the page behind the modal to keep the modal where it is in the viewport. That is, after all, how native modal dialog windows work.
  - samsin 4y ago
    That still wouldn't solve the situation GP described where the <dialog> element has a height greater than 100vh.
cm2187 4y ago
How do you deal with a large modal on a small screen then?
asddubs 4y ago
native browser features are usually more accessible, and can adapt to the platform they're on better
dgb23 4y ago
I agree. The primitives should be general and extensible via JS/WASM and presentation should be customizable. Browsers can’t cover every specific use case. Prebuilt, specific components should focus on providing utility for documents and forms. The “details” tag is a good example. It has interactive utility, clear semantics, but is easily extensible and you can fully style it. The text input tag, not so much. It’s for example difficult to extend into a typeahead/combobox with sensible UX and presentation without writing a whole buch of JS. And the story around accessibility isn’t clear either.
varrock 4y ago
It also doesn't trap focus within the dialog.
philistine 4y ago
Listen I’m just one dude with a very shaky understanding of programming. I still want my website to be good, so all those functionalities are a great thing.

by mg 4y ago

AprilArcus 4y ago

Try this: body:has(dialog[open]) { overflow: hidden } body:has(dialog[open])::before { content: ""; position: fixed; top: 0; left: 0; width: 100%; height: 100%; backdrop-filter: blur(4px); background-color: rgb(0, 0, 0, 0.5); }

mg 4y ago
Have you tried it? Here in Firefox, it does not work. https://jsfiddle.net/t34wz6kx/ https://jsfiddle.net/t34wz6kx/ Also, using "position: fixed" will fail when the dialog is longer than the screen. Then the user cannot read it all, and if the close button is at the bottom, they cannot close it.
- karlshea 4y ago
  Firefox also doesn't support :has. There's some more information on MDN [0] about how to make a modal dialog, you can open one in JavaScript using showModal() which has a backdrop, is actually modal, etc. [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
  - mg 4y ago
    Nice! https://jsfiddle.net/5gevzft8/1/ https://jsfiddle.net/5gevzft8/1/ Looks like you cannot use a button in the dialog then though. As it somehow makes the dialog scroll to the bottom.
    - derefr 4y ago
      Your "cannot use" is my "element has proper accessibility consideration for people who are viewing the dialog inside a webview that disables scrolling." With the buttons always starting in scrolled-into-view and in focus, those people can at least dismiss the modal!
    - MrJohz 4y ago
      This is the spec behaviour - the browser focus should immediately jump to the first focusable item in the page for accessibility reasons. (As I understand it, this is the norm for dialogs outside the browser.) My understanding is that you should be doing two things here: firstly, dialogs shouldn't generally be scrollable by themselves (or if they are, the interaction buttons should be sticky so that they're always visible). Instead, if you've got long text (say T&Cs) that should be in a scrollable box of its own. This allows the user to see the whole dialog (interactions and all) at once. Secondly, if there is something that should take focus before the buttons do, then you should set autofocus on that element explicitly. So in this case, you'd wrap the long text in a scrollable div, and add an "autofocus" attribute to that div to ensure that keyboard based users will immediately jump to it and be able to scroll it with their keyboard.

irrational 4y ago

I’m the opposite. I don’t want to have to use any third party code, libraries, frameworks, etc. I want it all in the standard library.

simultsop 4y ago
same here, it also bugs me when a language needs a framework then it needs a transpiler than an ide extension than a course to learn well how to align all ecosystem properly since standard not enough to give credit/satisfaction to all involved in dev :(
- zdragnar 4y ago
  This is how we end up with insufferable things like type "number" inputs and alert and most of the other baked in things. They're halfway to what you want but can't go further because everyone has slightly different needs and browsers are already complex enough without baking in prebuilt components for everything from data tables to carousels to modals to drop-down menus. Also, the list of things that bug you that a language needs describes pretty much every programming language in existence.
  - badsectoracula 4y ago
    > Also, the list of things that bug you that a language needs describes pretty much every programming language in existence. The bit about ecosystem and the context on JavaScript makes me certain he meant external needs - in other words he'd like "batteries to be included". There are several languages that come with a lot of stuff out of the box.
sgt 4y ago
That's not the reality of modern web development in the last 10+ years though.
- wildrhythms 4y ago
  Yes, and that has led to how many thousands of hours of developer time wasted building these things custom for their app (or trying to find some minimally invasive library to do it). Bring on the dialog element. Maybe we can get the ability to custom style select inputs next.

Jaxan 4y ago

Maybe it’s good not to prevent scrolling. I have had many situations where there was a non-scrollable modal dialogue and the buttons were off-screen (my phone has a small screen). So the website became completely unusable.

derefr 4y ago
It shouldn't necessarily prevent scrolling; but I'd expect scrolling the page behind the modal to keep the modal where it is in the viewport. That is, after all, how native modal dialog windows work.
- samsin 4y ago
  That still wouldn't solve the situation GP described where the <dialog> element has a height greater than 100vh.

cm2187 4y ago

How do you deal with a large modal on a small screen then?

asddubs 4y ago

native browser features are usually more accessible, and can adapt to the platform they're on better

dgb23 4y ago

I agree. The primitives should be general and extensible via JS/WASM and presentation should be customizable. Browsers can’t cover every specific use case. Prebuilt, specific components should focus on providing utility for documents and forms. The “details” tag is a good example. It has interactive utility, clear semantics, but is easily extensible and you can fully style it. The text input tag, not so much. It’s for example difficult to extend into a typeahead/combobox with sensible UX and presentation without writing a whole buch of JS. And the story around accessibility isn’t clear either.

varrock 4y ago

It also doesn't trap focus within the dialog.

philistine 4y ago

Listen I’m just one dude with a very shaky understanding of programming. I still want my website to be good, so all those functionalities are a great thing.