-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have some way of opening <dialog>
elements without JavaScript
#3567
Comments
Yeah, it's somewhat weird you can close them via |
One workaround would be to utilize
or to include |
I don't think there's a very significant difference between e.g. |
IMO there are very specific and quite substantial differences with those two examples. For one, the latter cannot be used in combination with CSP headers that disable inline JavaScript. Secondly the latter example cannot be easily statically analysed - this leads to plenty of problems such as no way for accessibility tools to determine which dialog that button will open. |
FWIW, we ended up creating
It does still need JavaScript to be fully accessible, but it is interactive without. Having a native way to achieve the stacking context would definitely be much preferred, whatever it end up being. |
@Malvoz a toggle would be helpful but I think it's also worth being able to choose the state you're aiming for. I think it's worth noting the
though you could argue |
Currently, I do something like this <button data-for-dialog="testDialog" open>Open dialog</button>
<dialog id="testDialog">
<h1>An example of a native Dialog element</h1>
<p>This is a dialog box and, believe it or not, it's built into HTML, sure we needed some javascript to open it but hey, it's a start.</p>
<button data-for-dialog="testDialog" close>Close dialog</button>
</dialog> and then have some JS like so const dialogTriggers = document.querySelectorAll(`[data-for-dialog]`);
for (let trigger of dialogTriggers) {
const dialog = document.getElementById(trigger.dataset.forDialog);
trigger.addEventListener('click', () => {
trigger.hasAttribute('open') && dialog.showModal();
trigger.hasAttribute('close') && dialog.close();
});
} I think it would be helpful to be able to do something like this and have it work. <button for-dialog="testDialog" open>Open dialog</button>
<dialog modal id="testDialog">
<h1>An example of a native Dialog element</h1>
<p>This is a dialog box and, believe it or not, it's built into HTML, sure we needed some javascript to open it but hey, it's a start.</p>
<button for-dialog="testDialog" close>Close dialog</button>
</dialog> Where you have the desired state is an atribute of your controller, or it toggles if nothing if present. |
I would propose the following addition to the standard: an This will be useful for both existing (details/summary, dialog) as well as future interactive elements that can be opened/closed. A polyfill will also be pretty simple: if ('opens' in document.createElement('button')) {
document.addEventListener('click', (ev) => {
let target = ev.target;
while (target) {
if (!target.getAttribute) {
continue;
}
const targetCloses = target.getAttribute('closes');
const targetOpens = target.getAttribute('opens');
const targetOpensModal = target.getAttribute('opensModal');
const targetOpensAny = targetOpens || targetOpensModal;
const attribute = targetOpensModal ? 'openModal' : 'open';
if (targetOpensAny && targetOpensAny === targetCloses) {
const toggle = document.getElementById(targetOpensAny);
if (toggle.hasAttribute(attribute)) {
toggle.removeAttribute(attribute);
} else {
toggle.setAttribute(attribute, true);
}
} else {
if (targetOpensAny) {
const open = document.getElementById(targetOpensAny);
open.setAttribute(attribute, true);
}
if (targetCloses) {
const close = document.getElementById(targetCloses);
close.removeAttribute('open');
close.removeAttribute('openModal')
}
}
target = target.parentElement;
}
});
} |
I appreciate all these proposals; however, I think it's more likely that we'll end up removing the dialog element entirely, as it only has a single implementer and is thus retrospectively failing to meet the criteria of https://whatwg.org/working-mode#additions. Given this, proposals to expand an already-failing feature are unlikely to get much engagement... |
I believe Firefox has the feature behind a flag but were waiting to see how |
That does't match my understanding, but be that as it may, stalled implementations don't really help a feature make progress either. |
I've had success implementing much of what I need |
Implementing this in CSS is possible, but doing so in an accessible way is really difficult to get right. So a semantic element making this easier would be an improvement over the current state. While I agree that the proposal for dialog is lacking, the idea of having a semantic element for notifications, modals, etc. should not be dismissed easily. |
I honestly don't understand what's the delay in implementing this. I have hardly worked on a project where I didn't need to create a dialog and resorted to custom JS/CSS. A dialog with custom HTML content should be part of the spec and should have been part of the spec since 2013. |
A dialog with HTML content is indeed part of the spec. Putting things in the spec however does not magically compell browsers to implement it. Only Chrome has implemented it so far, and other browsers have shown no movement toward doing so in some time. Your exasperation is probably better directed toward their bug trackers, instead of toward the bug tracker of a specification that you seem to have not read. |
FYI; there has been some movement from Firefox in implementing <dialog> quite recently: |
I think you may be over-optimistic there. The last time any code related to dialog landed was a month ago, in which someone added a pref to enable the incomplete implementation, but it was then immediately backed out by bots. The last time someone actually landed implementation code was 2016-12-11, if I am reading correctly. This is not the sort of implementation interest that marks a sustainable feature :(. |
Apart from the previous Firefox news, even also the WebKit teams explicitly mention it in their roadmap 2020 draft . |
MS has a proposal for a Edit: see It seems there's implementor interest from WebKit, what's the status of implementing |
For an official position it's better to reach out at https://github.com/mozilla/standards-positions/issues/new. On a personal level, it seems nice, though I'm interested in how it interacts with CSS (specially with what happens if a popup is under a transform or such, for example). Firefox's native popup menus are a somewhat interesting prior art, I think: we have an internal |
Firefox's My feedback from using
My suggested approach differs, however; I'd sidestep burdening a) it is a labelable element, Or to put it informally, I think writing |
just as <dialog id="my-dialog"></dialog>
<button dialog="my-dialog" dialogaction="open">
<button dialog="my-dialog" dialogaction="close"> I think that would be more coherent with existing button attributes. |
Combo of popover with dialog. This uses <button dialogtarget="dialog" popovertarget="tooltip">Click</button>
<div id="tooltip" popover="hint" class="tooltip">I appear on hover</div>
<dialog id="dialog" modal>
<h1>I am modal</h1>
</dialog> I don't know about the |
I would like to +1 this proposal. It is almost perfectly parallel to This (declarative invocation) is one of the "nice" features of popover that could naturally be brought to |
similar +1 but with one caveat, as I don't understand the use case for the pending clarity on the above, the values could be simplified down to: show, hide, toggle, showModal but curious to any use case i'm not thinking of to help me adjust my thinking |
I can't think of a particularly compelling use case, other than slots which can reflect elements in or outside of the dialog depending on the open state, and so would benefit from being able to define |
so would the idea there be that a button outside of the modal dialog opens the dialog, and then that same button is re-slotted into the dialog itself so that it could toggle it closed? and somehow that would be preferable to just having a close button within the dialog? |
I like this simplification; I think you're right that
Perhaps I'm missing a way to do this declaratively, but I believe to be able to do that, you'd either have to change a |
Seems sensible to me. Given other discussions around deprecating Dialog interface mixin DialogInvokerElement {
[CEReactions] attribute Element? dialogModalTargetElement;
}; Where if this value points to a dialog, then clicking on this element would open the dialog as modal. |
I think "dialog popover" is elevated to top-layer whereas a standard "dialog open" is not. |
Hmm very interesting point. I'm not sure everyone is 100% onboard with deprecating non-modal dialog behavior (i.e. So I'm supportive of just
Right. But that's almost always what you want, I think. Said another way, now that you have |
i also like this further simplification. My primary opposition is squarely in the scope of deprecating "non-modal" dialogs. We still need those. However, deprecating |
Thanks. This motivated me to finally file #9376. I agree with you. |
I've made an attempt at a PR: #9456. An open question in the PR which I'm bringing here:
|
agreed, it'd be odd to have each cancel the other out so that nothing happens. I'd personally lean towards the dialog becoming a non-modal popover if someone were to erroneously add both attribute sets. Just seems like the situation that would result in the least potential to making content that was supposed to be accessible, inaccessible, and remove any possibility of someone becoming semi-trapped in a modal that wasn't supposed to be one. |
Excellent point, I've updated the spec to go in that direction unless more compelling alternatives present themselves. |
For those following along, the new proposal is to add Please follow #9625. |
One capability missing from the #9625 (brilliant proposal btw) is the ability to open a dialog as a modal by default
My use case is that I sometimes have modal dialogs that are linked to a client side router where the URL controls their visibility. I currently call My thoughts on what
|
|
The open tag would still be required to make it actually modal so I don't think CSS could break it? I would suggest a single |
There's also discussion in #9376 about removing |
This is my suggestion. To create some new attributes...
|
What about using anchors? <a href="showmodal:#my-dialog">Open</a> |
dialog elements are a great addition and I'm glad they're getting implemented, but a key part of their functionality relies on JavaScript: to open a
<dialog>
you need to use JavaScript to set theopen
attribute.It'd be great if there was a way to make a
<a>
or a<button>
elements capable of opening dialogs.Precident already exists for page interactivity baked into HTML - for example
<a href="#..">
can already scroll the page, and<details>
elements are capable of hiding elements behind interactivity, so I think it stands to reason<dialog>
elements could be opened by other page elements.The text was updated successfully, but these errors were encountered: