search

radix-ui / primitives

Radix Primitives is an open-source UI component library for building high-quality, accessible design systems and web apps. Maintained by @workos.
https://radix-ui.com/primitives
MIT License
15.5k stars 786 forks source link

Native <dialog> element for the dialog component #2830

Open woutervanvliet opened 5 months ago

woutervanvliet commented 5 months ago

Feature request

Overview

I'd like to see, optional, support for the browser native

element in the react-alert-dialog and alert-dialog packages

Who does this impact? Who is this for?

This is for anybody who prefers to embrace web standards.

Additional context

Building custom, often Portal based, dialog implementations has been the golden standard of web development for a very long time. But the browser native

element now has broad browser support, and largely eliminates the need for portals, reduces complexity with focus trapping and is generally a much more accessible solution.

gustaveWPM commented 5 months ago

Hell no.

woutervanvliet commented 5 months ago

@gustaveWPM Hot take... makes me curious. Would you care to elaborate on why?

gustaveWPM commented 5 months ago

@gustaveWPM Hot take... makes me curious. Would you care to elaborate on why?

I don't like some native APIs/some web browsers "Standards", and <dialog> is concerned.

I find it awkward to use some "Magic" for something so simple. It just implies a loss of control and customizability.

Furthermore, <dialog> is always pushed onto the top layer, which is an enough undesirable side effect imo to never want to hear about it.

EDIT: https://github.com/radix-ui/primitives/issues/1317#issuecomment-1094877241

woutervanvliet commented 5 months ago

Furthermore,

is always pushed onto the top layer, which is an enough undesirable side effect imo to never want to hear about it.

But that's exactly what a dialog should... could you describe a use case for a dialog that's not at the top layer?

gustaveWPM commented 5 months ago

Furthermore, is always pushed onto the top layer, which is an enough undesirable side effect imo to never want to hear about it.

But that's exactly what a dialog should... could you describe a use case for a dialog that's not at the top layer?

You may want to have more control on its z-index. For instance, if you have toasts in your UI, it can start to be undesirable to have a dialog forced to the top layer...

benweier commented 5 months ago

@gustaveWPM while this is a valid concern for you, and likely others, the keyword in the feature request is "optional". I see no problem with this being supported for users who prefer to use the native APIs

Zer0xxxx commented 3 months ago

@gustaveWPM while this is a valid concern for you, and likely others, the keyword in the feature request is "optional". I see no problem with this being supported for users who prefer to use the native APIs

Adding tons of "Options" (moreover, pointless ones) is kinda the best way to make a codebase very ugly and hard to maintain. Both in the lib itself, and in the projects using it. So I agree with @gustaveWPM

I think Radix is designed to provide tiny components, doing one thing and doing it right. I've enjoyed working on code that used Radix for exactly that reason. Although, it can be a little confusing at first, when you haven't made the right choice of component from the outset due to a lack of understanding of their subtleties.

However, these design choices quickly lead to the creation of a well-structured and meaningful UI that does exactly what you want it to do. I'll never go back!

Btw, if you want to respect meticulously all the web standards, you shouldn't use React.

Bricklou commented 3 months ago

Z-Index issues are also very problematic. Many developers seems promoting the usage of Z-Index as a bad practice because of how it works (ex. z-index: 999999; or any random high number just to ensure it is above everything else. It doesn't make sense)

On the other hand, it would be possible to use the new popover api to move (if wanted) the elements to the top layer and use the role dialog for dialogs.

Zer0xxxx commented 3 months ago

(ex. z-index: 999999; or any random high number just to ensure it is above everything else. It doesn't make sense)

Just sounds like skill issues, so I don't get the point. That would be like saying that BigInt is a "Bad practice" because you can use it badly everywhere instead of Number.

Or any other example of "Bad practice" which is just misusing a feature.

I can play dumb with absolutely anything in a codebase, and then blame the tool instead of just respecting it. I'm not sure that's so much of a consideration to keep in mind.

The main point is still the same: in "Complex" UIs, it can quickly become undecidable without granular, fine-grained control over layers.

The Dialog and Popover standards are just toys. They're good for quickly building a UI, but they're limited. It's not designed to create advanced UIs. Radix, on the other hand, is designed for it.

I don't know any designer for whom the notion of a "top layer" makes sense. A designer stacks his layers, that's all.

arturkot commented 3 months ago

Hi everyone,

They're good for quickly building a UI, but they're limited.

In what aspects? @Zer0xxxx My take is they're more powerful variations of existing HTML elements.

The main features I see coming from <dialog> specifically is that it solves a bunch of a11y issues in one shot:

I believe some of the code could be simplified thanks to the features baked-in into the native element.

Stuff like toasts or tool-tips beneath the top layer can be solved by injecting them into dialog when required. Yes, it's a bit of hassle but nothing scary. I imagine this as a breaking change when updating/replacing an existing implementation though. Something to keep in mind.

Also, mind that a <dialog> can be be similar to a "regular div" if required (meaning, it doesn't always have to be placed in the top layer). See notes about non-modal dialog here.

Zer0xxxx commented 3 months ago

Hi everyone,

They're good for quickly building a UI, but they're limited.

In what aspects? @Zer0xxxx My take is they're more powerful variations of existing HTML elements.

The main features I see coming from <dialog> specifically is that it solves a bunch of a11y issues in one shot:

* Trapping focus within the dialog. | This is covered by Radix I believe.

* The dialog is announced as such an element by screen readers. | Ditto.

* Bringing back the focus to **the latest focused element** _before_ the dialog has been activated. | This is emulated to a degree but requires the button to be wrapped in a dedicated component. Also, doesn't cover cases where the dialog is fired as a side effect of doing something else (e.g., using a keyboard shortcut while having some link or button focused).

I believe some of the code could be simplified thanks to the features baked-in into the native element.

Stuff like toasts or tool-tips beneath the top layer can be solved by injecting them into dialog when required. Yes, it's a bit of hassle but nothing scary. I imagine this as a breaking change when updating/replacing an existing implementation though. Something to keep in mind.

Also, mind that a <dialog> can be be similar to a "regular div" if required (meaning, it doesn't always have to be placed in the top layer). See notes about non-modal dialog here.

Oh, this is an interesting point of view!

First, I have to admit that I wasn't aware of the "Non-modal dialog" feature. Interesting.

e.g., using a keyboard shortcut while having some link or button focused

This can be relatively "Easily" done, using document.activeElement... But, I have noticed that it doesn't behave the same on Safari than in other web browsers.

So it can be really problematic, indeed. I would like to know if the standard support of dialog fixes this with Safari, it makes me curious.

Stuff like toasts or tool-tips beneath the top layer can be solved by injecting them into dialog when required.

Good luck. This is the most awful part about the native <dialog> element when it's pushed on the top layer. But this stays a really instructive point of view. The non-modal dialog feature re-rolls the dices for me.

gustaveWPM commented 3 months ago

Hi everyone,

They're good for quickly building a UI, but they're limited.

In what aspects? @Zer0xxxx My take is they're more powerful variations of existing HTML elements.

The main features I see coming from <dialog> specifically is that it solves a bunch of a11y issues in one shot:

* Trapping focus within the dialog. | This is covered by Radix I believe.

* The dialog is announced as such an element by screen readers. | Ditto.

* Bringing back the focus to **the latest focused element** _before_ the dialog has been activated. | This is emulated to a degree but requires the button to be wrapped in a dedicated component. Also, doesn't cover cases where the dialog is fired as a side effect of doing something else (e.g., using a keyboard shortcut while having some link or button focused).

I believe some of the code could be simplified thanks to the features baked-in into the native element.

Stuff like toasts or tool-tips beneath the top layer can be solved by injecting them into dialog when required. Yes, it's a bit of hassle but nothing scary. I imagine this as a breaking change when updating/replacing an existing implementation though. Something to keep in mind.

Also, mind that a <dialog> can be be similar to a "regular div" if required (meaning, it doesn't always have to be placed in the top layer). See notes about non-modal dialog here.

Oh my god, I'm sorry. It seems that I was wrong on this point!

@benoitgrelard (sorry for the ping), we have discussed about this concern and we began to weigh the pros and cons of this issue with a certain maturity. What are your thoughts about this? I'm curious.

GetPsyched commented 2 weeks ago

Has anything come out of it yet? Seems like the mention of non-modal dialogs changed some minds but this issue didn't get anywhere?