Supporting IE

Below are details worth noting when considering to support or continue supporting Internet Explorer.

Facts

IE is no longer actively receiving new feature updates [needs reference]
IE11 is the only version still supported by Microsoft [needs reference]
IE11 is only receiving patches for critical security issues [needs reference]
IE11 has broken implemntations of valid, semantic HTML5 elements
- for unknown elements, browsers will style them as inline elements. This is problematic when you want to use valid semantic HTML5 elements to provide a11y support and the browser doesn't know about them.
- As a workaround, you have to add additional markup (role="main", etc.) and CSS (main { display: block; }) in order to drag IE forward to modern times.
IE does not support CSS Custom Properties (extremely useful for design systems and theming)

Security Issues

`window.opener` API exploits

External links to untrusted URLs can fall victim to exploits in the window.opener API. You can view a safe demonstration of how this could be used by hackers at https://mathiasbynens.github.io/rel-noopener/.

The best solution to this problem is to apply rel="noopener noreferrer" to any external link (<a href="" target="_blank">). However, there are two big problems.

IE11 doesn't support noopener
Only IE11 on later versions of Windows 10 (creators update) supports noreferrer

This is a security risk that we cannot completely prevent on IE, because it requires updates to core code in the browser, but IE is no longer receiving updates from Microsoft.

BUGS

`HTMLElement.prototype.tabIndex` broken with no intent to fix

Edge 12-17 and IE incorrectly return 0 for non-interactive elements without an explicit [tabindex] attribute. (Issue #4365703)

This bug WILL NOT be fixed in IE.

Accessibility

File Input

`input[type="file"]:active` never matches when using a keyboard

IE (all versions)
Edge 12-18

This prevents visual feedback when pressing SPACE (keydown) while focused on a file input. However, it still works when you use a mouse (mousedown).

`input[type="file"]` has TWO "tab stops"

One tab stop for a read-only text input that displays the selected file name.
Another for a button to open a file selection dialog.

The file input widget is rendered by the operating system (i.e., Windows), not the browser. There's no known CSS property or JavaScript configuration to remove the extra tab on the read-only text input.

IE (all versions)
Edge 12-18

Other Issues

Compiling to ES5

lager file size due to extra logic required to achieve similar functionality in ES6
does not have 1:1 feature parity with ES6
- this will likely result in strange bugs surfacing as time progresses
- eventually, polyfills won't be able to replicate new platform APIs / features in an ES5-compatible manne
  - this is not a matter of if but when

Limited CSS Layout Capabilities

Fluid CSS grid layouts (auto rows/columns, row/column gap, etc.) not supported.

Instead, use any combination of the following:

static/fixed CSS grid layout (legacy spec implementation)
flexbox
- save yourself the headache and only use for 1-dimensional layout (row OR column, not both)
floats (if absolutely necessary)
default document flow (sometimes it's better to let the browser handle it)

Custom Elements

To ship custom elements for browser consumption

ES5 Adapter

required from @webcomponents/webcomponentsjs in order to convert ES5 function constructors into ES6 classes (required by Custom Elements v1 API specification)
complicates consumer setup (unless bundled into ES5-generated assets)
2018-05-15: with the release of Firefox 60, ES6 module loading may provide the means to stop using the adapter for modern browsers (Edge, Firefox, Chrome, Safari, etc.)
2018-11-17: with @webcomponents/webcomponentsjs version ^1.2.4 || ^2.0.4, the adapter is simpler to consume and no longer throws an error in IE

ShadyDOM Polyfill

The ShadyDOM polyfill doesn't prevent Light DOM CSS from accidentally styling ShadyDOM markup.

NOTE: this isn't IE-specific, but it will eventually become an exclusive problem with IE (once modern browsers fully support ShadowDOM.)

To imitate ShadowDOM encapsulation the ShadyDOM polyfill rewrites markup and CSS to increase CSS specificity of rendered markup (essentially "faking" encapsulation by defining more specific CSS selectors).

For example:

<style scope="ui-thing">
  /* ShadyCSS Selectors */
  #wrapper.ui-thing { ... }
  #body.ui-thing { ... }
</style>
<style>
  /* Light DOM CSS selectors */
  #wrapper { ... }
  #body { ... }
</style>
<div id="wrapper">
  <ui-thing>
    <div id="wrapper" class="style-scope ui-thing">
      <div id="body">...</div>
    </div>
  </ui-thing>
</div>

In this scenario, the #wrapper selector could accidentally apply unwanted styling to the ShadyDOM markup.

Workaround - prefixed ShadyDOM selectors

To work around this issue, we have to make the selectors in the Shadow DOM more specific than Light DOM.

The most stable way to work around this is to apply the BEM naming convention to IDs in the ShadowDOM. This prevents collisions in both Light DOM as well as ShadyDOM selectors across custom elements.

<style scope="ui-thing">
  /* ShadyCSS Selectors */
  #uiThing.ui-thing { ... }
  #uiThing__body.ui-thing { ... }
</style>
<style>
  /* LightDOM CSS Selectors */
  #wrapper { ... }
  #body { ... }
</style>
<div id="wrapper">
  <hx-thing>
    <div id="uiThing" class="style-scope ui-thing">
      <div id="uiThing__body">...</div>
    </div>
  </hx-thing>
</div>

Now, #wrapper won't match the ShadyDOM markup.

CITguy/supporting-ie.md