You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in having the polyfill apply itself conditionally, possibly by leveraging something like the following to decide not to do this work in browsers like Chrome and Edge:
On my end most of my usage is in shadow roots so I have access to doing this from the outside, however the document level application is made by default, and it would be great to avoid that as well. Is this something that would be acceptable in a PR form?
Initially, where the polyfill a module by default I'd suggest to split the code into something like:
// Apply the polyfill to the global document, so that no JavaScript
// coordination is required to use the polyfill in the top-level document:
applyFocusVisiblePolyfill(document);
}
The current default entry point could import both and call apply by default, then a secondary entry point like focus-visible-conditional.js could be created with the above test gating the call to apply. Similarly, the method at
could be wrapped in a helper that returned early when hasFocusVisible is true.
This should allow for current users to continue to receive the same functionality with no work required, but new or advanced users would be able to have some flexibility around application. It does bump into the idea that the library isn't currently in module form, which would beg the question would some bundle tooling be required to ensure that the code delivered would also be the same shape for those existing users. This could be mitigated by a breaking change release the leaned into ES Module delivery first and prioritized the reality that those users are more likely to be in a situation where conditional application is preferred, which could allow for only a single version to be distributed, the conditional one. The adds a tiny bit of extra work on the user's end as they'd need to be 100% sure they had CSS for both contexts, however.
Thoughts?
The text was updated successfully, but these errors were encountered:
I'm interested in having the polyfill apply itself conditionally, possibly by leveraging something like the following to decide not to do this work in browsers like Chrome and Edge:
On my end most of my usage is in shadow roots so I have access to doing this from the outside, however the document level application is made by default, and it would be great to avoid that as well. Is this something that would be acceptable in a PR form?
Initially, where the polyfill a module by default I'd suggest to split the code into something like:
focus-visible-polyfil.js
-focus-visible/src/focus-visible.js
Lines 1 to 275 in 10fdfa7
focus-visible-apply.js
- with the following lines from the original wrapped in a method calledapply
or similar:focus-visible/src/focus-visible.js
Lines 276 to 304 in 10fdfa7
The current default entry point could import both and call
apply
by default, then a secondary entry point likefocus-visible-conditional.js
could be created with the above test gating the call toapply
. Similarly, the method atfocus-visible/src/focus-visible.js
Line 8 in 10fdfa7
hasFocusVisible
is true.This should allow for current users to continue to receive the same functionality with no work required, but new or advanced users would be able to have some flexibility around application. It does bump into the idea that the library isn't currently in module form, which would beg the question would some bundle tooling be required to ensure that the code delivered would also be the same shape for those existing users. This could be mitigated by a breaking change release the leaned into ES Module delivery first and prioritized the reality that those users are more likely to be in a situation where conditional application is preferred, which could allow for only a single version to be distributed, the conditional one. The adds a tiny bit of extra work on the user's end as they'd need to be 100% sure they had CSS for both contexts, however.
Thoughts?
The text was updated successfully, but these errors were encountered: