search

GoogleChrome / dialog-polyfill

Polyfill for the HTML dialog element
BSD 3-Clause "New" or "Revised" License
2.45k stars 245 forks source link

Fix focus of dialog inputs within shadow DOM (#189) #198

Closed hadriann closed 4 years ago

samthor commented 4 years ago

Thank you. I normally rev the release version myself but thanks for bumping it too. I can publish this soon.

samthor commented 4 years ago

As as a bit of a side note, and I'm not sure where else to put this: I'm glad folks are interested in polyfilling dialog inside a shadow root, but I actually don't think it's the right answer long-term.

I have an "element" branch of this repo which creates the <x-dialog> element (you can check it out, serve the directory, and load this file for a test). It uses Web Components (and Shadow DOM) to either polyfill (or use the native if supported).

It's much easier to use—just add <x-dialog> to your pages. But, it's no longer a polyfill. (Custom Elements must be in the form "x-y", so I can't just create one for <dialog>). So I wonder if users of this library might be frustrated to be told that <dialog> is for native (and... poor-ish SD support), but use <x-dialog> if you're targeting modern browsers (non-IE11).

hadriann commented 4 years ago

I, for one, am in favor of native elements (and APIs) whenever possible. I recently switched from a web-components-based custom dialog to the native dialog because I think that web components shouldn't be used to reinvent basic / native HTML functionality. So, when I target modern evergreen browsers I expect to be able to explore the full potential of HTML5 - while plugging in polyfills when needed, but unplugging them as soon as browser support is there.

With a custom dialog, the plug-in and unplug actions are not so straightforward anymore. If I make a heavy use of x-dialog in my app and at some point I find out that the native one has full support, I need to refactor / change quite a bit.

I guess a good use case for a custom dialog is an enhanced (not just style-wise) or specialized type of dialog, such as a non-blocking confirmation dialog.

Other than that, I hope that Firefox and Safari get up to speed with the "living standard" soon :)

samthor commented 4 years ago

I totally agree re: using native components, although <dialog> has unfortunately languished for over ~7 years now (since I took over the polyfill at least). Firefox has a basic implementation IIRC but that's about it. It's been saved from being cut from the spec at least once.

The big challenges with a polyfill are basically; interaction with stacking context (which a lot of folks do get right, but is pretty frustrating), and the remarkably odd rules around static positioning for modals (since the element remains "in-place" on top, even if you scroll).

With x-dialog, I tried to make an element which deals with those issues (... by forcing position: fixed for the polyfill and native support case) and also simplifies the instantiation process (there is none—and no issues with CSS insertion—you just add the CE), but which otherwise matches the spec. I appreciate that it could feel like "bait-and-switch" though, so thank you for your feedback. My decision at this point though becomes:

hadriann commented 4 years ago

@samthor was this fix published? Seems I cannot get version 0.5.2

samthor commented 4 years ago

No, sorry. It's published now.

On Mon, 3 Aug 2020 at 22:01, Adrian Nita notifications@github.com wrote:

@samthor https://github.com/samthor was this fix published? Seems I cannot get version 0.5.2

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GoogleChrome/dialog-polyfill/pull/198#issuecomment-667983881, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA5DEDV2I5CWQXAHWMXULTR62RKRANCNFSM4NBPBN7A .