Drop IE Support

[CITguy]

likely to be a long-lived issue

[CITguy]

Compiling to ES5

• larger file size due to extra logic required to achieve similar functionality
• does not have 1:1 feature parity with ES6
  • this will likely result in strange bugs surfacing in the future
  • eventually, polyfills won't be able to replicate new features in an ES5-compatible manner
    • it's not a matter of if but when

[CITguy]

ES5 Adapter

• needed to convert ES5 logic to ES6 class syntax for custom element registration
• requires hacks and redundant logic to function outside of HTML imports
• complicates consumer setup

2018-05-15: with the release of Firefox 60, ES6 module loading may provide the means to stop using the adapter altogether.

2018-11-17: with @webcomponents/webcomponentsjs versions ^1.2.4 || ^2.0.4, the adapter is simpler to consume and no longer throws an error in IE.

[CITguy]

Limited CSS Layout Capabilities

• Flexbox instead of Modern CSS Grid
• Flexbox is not intended for 2D layout (hacks are in place to make it behave better, but not perfect)
• IE has old implementation of css grid (useful, but limited)
  • Can use grid implementation for fixed layouts only.
  • Fluid CSS grid layouts (auto rows, auto margins, etc.) are impossible in IE.
  • Grid gap styling must be applied using margin on grid items (no -ms-* equivalent of grid-gap).
• All other modern browsers have native implementation of latest CSS Grid specification.

Recommendation

When applying fluid CSS grid layouts to new or existing components, identify what the IE fallback will look like.

[CITguy]

Legacy CSS Grid instead of Flexbox

• In cases where we need to implement scrollbars along a single dimension (horizontally or vertically) on elements that have fluid dimensions up to a maximum value (fill space if content is light, scroll if content is heavy), IE cannot properly trigger scrolling overflows with flexbox.
• See this codepen example for a demonstration.

[CITguy]

Broken implementation 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 accessibility support and the browser doesn't know about them.
• As a workaround, we have to add additional markup (role="main", etc.) and CSS (main { display: block; }, etc.) in order to drag IE forward to modern times.

[CITguy]

Platform Polyfills

• Based on research around required polyfills, IE is the only browser that needs additional platform polyfills beyond what webcomponentsjs provides.
• Maintaining polyfills adds development overhead.
• Extra polyfills increase required asset size (directly affecting performance).

2018-05-15: This can be minimized with updates in #227 put on hold

[CITguy]

Limited Support for CSS Custom Properties

The ShadyCSS polyfill that's included with webcomponentsjs will detect if a CSS custom property is consumed in the Shadow DOM and will stamp a static value when it styles the Shady DOM elements. This is fine for default styles, but it prevents overriding values in the Light DOM for the following cases:

• theming from Light DOM (not possible in IE without rewriting ShadyCSS styles)
• overriding values to demonstrate component states, for visual regression (impossible/difficult to do visual regression tests in IE, because of this)

[CITguy]

ShadyDOM Rewrites - CSS Styling Conflicts

ShadyDOM 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 have native support for 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="hx-thing">
  /* ShadyCSS Selectors */
  #wrapper.hx-thing { ... }
  #body.hx-thing { ... }
</style>
<style>
  /* Light DOM CSS selectors */
  #wrapper { ... }
  #body { ... }
</style>
<div id="wrapper">
  <hx-thing>
    <div id="wrapper" class="style-scope hx-thing">
      <div id="body">...</div>
    </div>
  </hx-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 simplest way to do this is to prefix the selectors with hx, so we'd end up with: (this could conflict with other ShadyDOM selectors)

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="hx-thing">
  /* ShadyCSS Selectors */
  #hxThing.hx-thing { ... }
  #hxThing__body.hx-thing { ... }
</style>
<style>
  /* LightDOM CSS Selectors */
  #wrapper { ... }
  #body { ... }
</style>
<div id="wrapper">
  <hx-thing>
    <div id="hxThing" class="style-scope hx-thing">
      <div id="hxThing__body">...</div>
    </div>
  </hx-thing>
</div>

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

[CITguy]

ShadyDOM Rewrites - Differing CSS Selectors in Light DOM

ShadyDOM modifies the generated DOM to the point of requiring two different CSS selectors in order to target the same element.

native ShadowDOM supported

<hx-thing icon="key">
  <p>Thing content!</p>
</hx-thing>

The hx-thing > p selector (specificity:002) will select the Light DOM paragraph.

polyfilled via ShadyDOM

<hx-thing icon="key">
  <div id="wrapper" class="style-scope hx-thing">
    <hx-icon type="key" class="style-scope hx-thing"></hx-icon>
    <span class="style-scope hx-thing">
      <p>Thing content!</p>
    </span>
  </div>
</hx-thing>

The #wrapper.hx-thing > span > p selector (specificity: 112) is required to target the paragraph in a polyfilled browser. This selector is highly dependent on the ShadowDOM markup structure, and is extremely brittle. The only way around this requires bloating either the CSS (with more specific selectors) or the markup (with extra ids or classes) in order to guarantee the same target across browsers.

This affects:

• Light DOM styling
• Testing

Future

Eventually, this won't be a problem for evergreen browsers. As they gain native ShadowDOM and Custom Element support, the ShadyDOM rewrites will no longer be applied. However, as long as we support IE, this will always be an issue, because IE will always require the polyfill.

[CITguy]

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.

1. IE11 doesn't support noopener
2. 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.