Revert previous clip-deprecation fixes in favor of hybrid clip and clip-path. #2989
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@harvesthq/chosen-developers /cc @jisraelsen
This PR reverts #2939 and #2943, which attempted to avoid using the deprecated
clip
property and useddisplay: none
, at the cost of a second input to capture focus events.It didn’t work out too well, and has continued to be a headache as we try to use the latest version in Harvest. I think the best thing to do is admit it was the wrong choice and revert it. Juggling focus and key events isn’t standard across browsers, especially while making DOM modifications.
This PR instead leaves the deprecated
clip
property and additionally introduces the same fix usingclip-path
. The result is that browsers that do not support the new standardclip-path
will fallback to using the deprecatedclip
property, without requiring any additional changes.One nice side-effect: while trying to make this all work correctly, I had to dig way into the way we handle focus and blur events in Chosen. If you’re not aware, we’re currently doing a lot of juggling around blur events, since blurring an input technically happens while clicking on an item to select it. I discovered that we can avoid doing all of that if we rely on
focusin
andfocusout
events on the wrapping container, as demonstrated in this jsfiddle (watch forchosenfocus
andchosenblur
events). I’ll be pursuing this further in a separate PR, and expect to be able to delete a bunch of focus-specific properties as well as the extra 100ms the chosen drop is visible — but didn’t want to hold this up on an unrelated change.