renatodeleao / a11y-vue-dialog Goto Github PK

This came from the one to one match of the markup version:

<a11y-vue-dialog-renderless #default="{ backdropRef }">
  <!-- i work as root but also as backdrop overlay -->
   <div class="dialog" v-bind="backdropRef.props">
     <div class="dialog__inner">conent</div>
   <div>
</div>

But this is also a valid implementation, and currently will break the component

<a11y-vue-dialog-renderless #default="{ backdropRef }">
  <!-- i work as root -->
   <div class="dialog">
     <div class="dialog__backdrop" v-bind="backdropRef.props" />
     <div class="dialog__inner">conent</div>
   <div>
</div>

Cause

Our dom "refs", are querySelected assuming a dialogRoot exists and is the element with data-id, but that data-id is bound via backdropRef.props, meaning it won't find the descendents.

Because there's not a focusable element within dialog selected.
We need to re-focus after the current focus element is removed.

Not sure if the best approach is to focus first or next focusable element. Maybe binding keyboard elements to window instead would do, but then nested dialogs would require extra-logic.

Although things are working i can't seem to write a proper test to check if methods are being called correctly.

although I still recommend a portal solution for accessible dialogs, and speciallyportal-vue as the one till Vue 3 comes out and we have <Teleport>, i don't want to list it under our dependencies anymore, since we're moving renderless and any portal solution should, in theory, work.

The portal version itself should not have any influence on this component behaviour, and any current portal version should work anyways.

Since we use <component :is="portalName" /> under the hood for the markuped, it should be fairly easy to provide any valid portal component name and props object for configuration.

Also as announced, the markup version of this component be deprecated, so it makes even more sense to do it.

This assumption needs some testing of course.

it's a duplicate of closeRef.listeners.click and it's making the scoped slots API bigger for no extra benefit.

It doesn't make sense to have the same logic twice.

Using :focus-visible polyfill breaks focus trap.
Test and it's reproducible on versions >= 0.4.5 — so probably that frankenstein engeneering to keep focus trap order after conditional content mutation affected this. The good side is debugging since it reduces the scope of causes.

• codesandbox

Note that this is not a security concern for the package at all, but I'm tired of getting those weekly security emails from github.
Vuepress has been deprecated and Vitpress is the new king in town.

and errors... 🕵️

And also when dialog starts open by default, focus element is not found

it's not the first time that i publish a version without actually build code on it. Let's automate the whole process so it doesn't rely on my tired human brain.

A know limitation of portal-vue so while this depends on it we should warn users.

Gladely vue 3 new <Teleport /> won't have these issues

Related

• vuejs/rfcs#62
• vuejs/rfcs#112
• vuejs/vue#5837 (Provide/inject with functional components)

This plugin shouldn't try to guess Apps root dom structure. Remove $root overflow declaration. Make it optional to pass a scrollableElement other than body but don't infer it.

After v0.4.6, we get it stable enough to not break code, but there's sill some scenarios were the calculation of what's the previous or next Tab-able element fails.

The good news is, focus is still trapped within dialog after content mutations, it still gets new focusable elements, so no functionality was broke.

I'll pick on this next month.