-
Notifications
You must be signed in to change notification settings - Fork 164
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
Fixed IE10/11 support (#34) #35
Fixed IE10/11 support (#34) #35
Conversation
jhildenbiddle
commented
Feb 14, 2018
- Changed NodeList-to-Array conversion from spread operator to Array.apply
- Changed Array.includes instances with Array.indexOf
- Changed ES6 code in demo.js to ES5 as this code is not transpiled via babel
- Added CustomEvent polyfill and converted dispatched Event() instances to CustomEvent()
- Replaced NodeList-to-Array conversion from spread operator to Array.apply - Replaced Array.includes instances with Array.indexOf - Added CustomEvent polyfill and converted dispatched Event() instances to CustomEvent() - Converted ES6 code in demo.js to ES5 as this code is not transpiled via babel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's awesome, thank you very much! I just have a small concern about the polyfill being included in the source code.
src/medium-zoom.js
Outdated
@@ -13,6 +15,23 @@ const isListOrCollection = selector => | |||
|
|||
const isNode = selector => selector && selector.nodeType === 1 | |||
|
|||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not include the polyfill in the source code? Perhaps document in the README to include this polyfill before including medium-zoom
for IE support. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. Agreed on not including the polyfill as-is. Libs shouldn't mess with globals (that's my bad).
If it were my choice, I'd switch from a CustomEvent polyfill (which modifies the window
object) to a ponyyfill. The rational for this is so that libraries that depend on medium-zoom aren't forced to polyfill to provide support for older browsers. If medium-zoom requires ponyfills to function, then so do all libraries that depend on it (unless they use a forked version of medium-zoom and do the ponyfilling themselves but... that kinda stinks). In this case, we can switch the current CurrentEvent polyfill to a ~6-line ponyfill very easily and prevent devs from having to deal the issue which seems like the right thing to do.
For template
support, I did a quick scan of the code and it looks like we could get this working with minimal changes. I haven't spend enough time looking into this to say definitively, but I am happy to do so if you feel this is work exploring. It's worth noting that template
support is unavailable for Edge 12, and all versions of Edge have known issues that may effect medium-zoom depending on how users define their template (again, haven't investigated). We can look into these if/when we tackle template
support changes and potentially avoid these Edge-specific known issues at the same time. For now, perhaps it is best to handle template
support (and any related discussions) as a separate issue and close on these changes which provide "core" support for IE/Edge 12+13 and prevent legacy browsers from breaking.
So, how do you feel about proceeding as follows:
- Switch CustomEvent polyfill used in PR to a ponyfill
- Add feature detection to allow
options.template
to be ignored in browsers that do not support HTML templates. - Update README to include browser support section
- List support beginning with IE10+
- List polyfill requirement for IE and Edge 12 for
options.template
support
- Update README
options.support
section to include IE/Edge12 polyfill requirement
If this works for you, I can tackle these changes early next week.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds great, thanks for the time you put into this! I'm away next week but ping me if there's anything I can help with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You bet! Thanks for being amenable to the changes. :)
I'll make the updates mid next week. We can sync up again after the PR request is submitted.
As for I don't have the tools to test these solutions on IE unfortunately. |
If interested, head over to https://www.browserstack.com and sign up for a free open-source developer account. This will make testing in IE much, much easier. The Chrome extension makes any OS/browser combination just a few clicks away. You can also get a free open-source account on http://saucelabs.com. Same general idea. Both offer live testing in your browser as well as automated testing. I use both (SauceLabs for automated testing, BrowserStack for live testing). Hope this helps! |
Thanks for all the tips, that will definitely be useful! |
Apologies for the delay on the update. The polyfill that was previously included has been removed. In its place is a custom ZoomEvent function which does essentially the same thing (creates modern+legacy compatible CustomEvents) without modifying the I did not dive into If this PR is merged, I will make sure the maintainers of docsify are notified so that they can update their zoom-image plugin. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is brilliant, thanks a bunch!
src/medium-zoom.js
Outdated
if (typeof window.CustomEvent === 'function') { | ||
return new CustomEvent(event, params) | ||
} else { | ||
const evt = document.createEvent('CustomEvent') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you name this variable something like customEvent
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. :)
Do you prefer customEvent
or createCustomEvent
? The latter feels like a better match to the existing [verb][Noun]
method names. Happy to go whichever way you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
customEvent
makes more sense to me since it's an object, not a method. Perhaps customEventFactory
is appropriate here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, there was a misunderstanding. I meant renaming the variable evt
to customEvent
.
But having renamed ZoomEvent
to customEvent
is also good. I understand why you wanted to call it createCustomEvent
.
Now if you can rename customEvent
to createCustomEvent
and evt
to customEvent
it would be perfect 🙂
Sorry for the confusion.
No worries at all. Happy to land this. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
We need to add the "Support" section in the README and then we're good to release a new version of the library! I'll do that by the end of next week. Thanks a lot! |