WHATWG HTML Standard VS dialog-polyfill

WHAT-WG HTML

There's a long-standing WHATWG feature request open for it here: https://github.com/whatwg/html/issues/2791

And several userland custom element implementation, like https://www.npmjs.com/package//html-include-element

One of the cool things that you can do with client-side includes and shadow DOM is render the included HTML into a shadow root that has s, so that the child content of the include element is slotted into a shell implemented by the included HTML.

This lets you do things like have the main page be the pre-page content and the included HTML be a heavily cached site-wide shell, and then another per-user include with personalized HTML - all cached appropriately.

The `allow` attribute on iframes is a relatively recent API addition from 2017

https://github.com/whatwg/html/pull/3287

I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform.

I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791

And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-element

Then HTML could support these elements being targets of links.

> Consider https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/

I thought, oh, that's not so bad. Then I realized what I was looking at was a 10 page index.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get

to target a section of the page that isn't an has been argued about and hashed out for years.<p>Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. <a href="https://github.com/whatwg/html/issues/new?assignees=&labels=addition%2Fproposal%2Cneeds+implementer+interest&projects=&template=1-new-feature.yml">https://github.com/whatwg/html/issues/new?assignees=&labels=...</a><p>It asks three main questions:<p>* What problem are you trying to solve?

The issue with a single global event handler is discussed here: https://github.com/WICG/close-watcher#a-single-event

If you use popover="", you get the kind of functionality you're discussing for free. For

, the discussion is in progress and reaching a conclusion: https://github.com/whatwg/html/issues/9373

> - Z-index has no effect in the top-layer. No need to compete for a higher z-index.

This is the kind of boring feature that can end up saving huge amounts of developer time. Z-indexing in CSS is kind of annoying and I've seen projects just detach dialogs from their normal position in the DOM entirely to get around stacking errors before.

----

Minor question:

> - There is only one `top-layer` but it can have many children. Last opened === current element on top.

Is this true? The spec says:

> The top layer is an ordered set of elements, rendered in the order they appear in the set. The last element in the set is rendered last, and thus appears on top.

I'm still playing around with `dialog` elements, so you may well be right, I'm just having trouble finding the actual spec rules about what happens when there are multiple dialogs and they're being simultaneously manipulated.

----

> - Not supported in Safari <= 15.3

Worth noting that there is a polyfill (https://github.com/GoogleChrome/dialog-polyfill), but that the polyfill comes with some fairly large limitations, specifically that they don't advise dialogs be used as children of elements with their own stacking context.

This is reasonable, but also... my first thought when I originally ran into `dialog` was "finally I can stop worrying about which of my elements create new stacking contexts!" -- so it does decrease the usefulness quite a bit.

Yeah, Safari is pretty often behind the other popular browsers. But, you can generally predict that by looking for any given feature on MDN and check the "Browser compatibility" section. Sometimes, there are polyfills available that sort of "force" a feature to work across every browser.

(Searching for "polyfill " will usually get you good results - in this case the first result appears to be a library maintained by the Chrome team: https://github.com/GoogleChrome/dialog-polyfill )

This does not make sense. Of course new functionality won't work on old browsers.

is easy to polyfill well: https://github.com/GoogleChrome/dialog-polyfill

GoogleChrome / dialog-polyfill