Bundling in a widget, scope about focus-visible HOT 13 OPEN

I was thinking more like

focusVisible.init({global: false});  // default to "global" mode which "decorates" the whole document
focusVisible.decorate(myEl, 'uppy-focus-visible-container', 'uppy-u-focus-visible');

then in the library

function addFocusVisibleClass(el) {
  if (!globalMode && !isDescendantOfDecoratedElement(el))
    return;

  // rest of method
}

You could have more than one element "decorated" in the document, but they don't need to know about each other.

I'm not sure how to have the current "auto init in global mode" functionality coexist with this, though.

from focus-visible.

Or can we ship a separate ponyfill version?

Usage in Uppy can be:

import focusVisible from 'focus-visible-ponyfill'

focusVisible({
  scope: '.uppy', // a selector, defaults to `:root`
  className: 'uppy-focus-visible' // defaults to `focus-visible`
})

And the polyfill version can be just:

import focusVisible from 'focus-visible-ponyfill'

focusVisible()

from focus-visible.

This seems like a good idea. Could we have a kind of "registry" for container name -> custom class name, so that multiple widgets could use it? How would you specify these options to the library?

from focus-visible.

(Also your widget looks great, and has a great logo!)

from focus-visible.

Also mentioned in #46

I actually have mixed feelings on this idea. I might lean a bit more toward not encouraging libraries to bundle their own version of the polfyill, but to instead inform the page author that the polyfill is required to use the library. That avoids the situation where multiple components are trying to scope or change the name for the class that the polyfill applies.

from focus-visible.

Hm, I think as long as components can avoid stomping on each other and the main page (hence the "registry" idea), it's not too bad.

Obviously for the real pseudo-selector this won't be possible, but I can understand wanting to keep things scoped while using the library.

from focus-visible.

yeah that's reasonable

from focus-visible.

(Also your widget looks great, and has a great logo!)

Thanks! :)

I might lean a bit more toward not encouraging libraries to bundle their own version of the polfyill, but to instead inform the page author that the polyfill is required to use the library. That avoids the situation where multiple components are trying to scope or change the name for the class that the polyfill applies.

but I can understand wanting to keep things scoped while using the library.

Yeah, I understand this is intended as a polyfill, but the way it currently works is it’s adding classes to elements, not pseudo-classes, and when this functionality is actually implemented in browsers it will be different, so can’t just remove the polyfill like with Promises or Fetch.

From my standpoint I can either bundle it with Uppy as external dependency (if I can add scope, because I think can’t be tempering with the whole document that I have no knowledge about, right? Feels a bit invasive) or copy-paste the code and modify it slightly to include scope features or hardcode classnames and container. Feels weird to be asking users to include focus-visible before using Uppy, most will just ignore it, I think, and its convenient when you can just include one script and style link and be done with it.

Could we have a kind of "registry" for container name -> custom class name, so that multiple widgets could use it?

By that do you mean that we document which lib is using this and what class names its using? 🤔Like:

# uppy

`.uppy-focus-visible` and `.uppy-u-focus-visible`

# codemirror

`.cm-focus-visible` and `.cm-element-focus-visible`

How would you specify these options to the library?

I’m thinking we’ll need a way to use it programmatically, like:

const focusVisible = require('focus-visible')
focusVisible.init({
  containterClassName: '.uppy-focus-visible',
  elClassName: '.uppy-u-focus-visible'
})

from focus-visible.

Has there been much progress on this? I'm in the same boat, wanting to add it to https://github.com/sampotts/plyr to help with this issue: sampotts/plyr#905

from focus-visible.

from focus-visible.

OK sure I'll take a look and try and get a PR together 👍

from focus-visible.

Hey folks, unfortunately I'm heads down on a project that launches in early november. Not sure if I'll be able to get to this before then :\

Not sure if @alice has time to take a look?

from focus-visible.

We have a ponyfill in this PR and in this NPM package, which is slightly refactored. It's also supposed to work in scopes like iframes and shadow dom. Our primary problem with this project (and any that assumes a global window/document) is that it cannot be injected into iframes/shadow dom contexts programmatically.

Feel free to use if you need it.

from focus-visible.