addEventListener,removeEventListener, anddispatchEventfor IE8 including custom bubbling eventstimeStamp,cancelable,bubbles,target, andcurrentTargetproperties per each eventdocument.createEvent('Event')standard API withe.initEvent(type, bubbles, cancelable)supported toopreventDefault(),stopPropagation(),stopImmediatePropagation()working with both synthetic and real eventsdocument.addEventListener('DOMContentLoaded', callback, false)supportedtextContent,firstElementChild,lastElementChild,previousElementSibling,nextElementSibling,childElementCountdocument.defaultView,window.getComputedStyle
current tests file and live test page
Here a page example
<!DOCTYPE html>
<html>
<head>
<title>ie8</title>
<!--[if IE 8]><script src="ie8.js"></script><![endif]-->
<script>
this.addEventListener('load', function(e) {
alert('Hello Standards');
});
</script>
</head>
</html>The file can be either the full version or the minified one and could be placed before or after some third parts library accordingly with compatibility.
It is now possible to include this file through cdnjs
<!--[if IE 8]><script
src="//cdnjs.cloudflare.com/ajax/libs/ie8/0.2.5/ie8.js"
></script><![endif]-->This polyfill normalize the EventTarget interface for every node.
This shim normalizes the DOM Level 2 Event interface too, adding an extra DOM Level 3 .stopImmediatePropagation() as bonus.
Here a humble list of things what won't probably ever be fixed in IE8
- a standard capturing phase. The logic involved to pause a synthetic or DOM event, capture up, and re-dispatch top-down is probably not worth it the time and the size of the code. Right now if the
useCaptureflag is used, the event is prepended instead of appended simulating somehow the 99% of the time reason we might opt for thecapturephase, being this usually slower too so it's a good practice, in any case, to.stopPropagation()on capture. - not supported modern events,
DOMContentLoadeda part, suchtransitionendor similar. As events might exist and might not exist in any browser out there, it does not make sense to fix them here. However, this polyfill provides all needed tools to fix special events through a powerful, custom events compatible, W3C standard API
Some library could do weak features detection and decide the browser is IE8 regardless and threat it like that, some other might assume since this stuff is there and working much more should be possible too.
Well, in 4 years of problems and counting, I have no idea about how many libraries still do work arounds for IE8 but if your libraries are ignoring such browser you might want to add this file regardless and probably find IE8 automagically fixed for all your JS needs.
The very first thought I had about this project was: how the hack is possible nobody had gone down this road before?
I am still thinking the same so ... there might be many things this polyfill is not fixing (yet). If you have any specific request please file a feature request (or a bug) in the proper section.
It's about IE8 so I am expecting 23456789065123456789 tickets about problems each day so probably only most relevant will be considered due the amount of time it might take.
Thanks for your contribution and your understanding.
 |
|---|
| Andrea Giammarchi |
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent