loading...
Cover image for What To Expect When You're Expecting To Drop IE11 ๐Ÿ—‘๏ธ

What To Expect When You're Expecting To Drop IE11 ๐Ÿ—‘๏ธ

samthor profile image Sam Thorogood Updated on ใƒป4 min read

Blog-A-Day in June (19 Part Series)

1) Rebuild only when necessary in Node 2) Civilization is a game you never lose 3 ... 17 3) Arrow functions break JavaScript parsers 4) Detecting Select All on the Web 5) Declaring JS Variables in 2019 6) Sam's dotfiles highlights 7) Automate Reading Form Results with ๐Ÿค– Chrome 8) Beyond appendChild: Better convenience methods for HTML 9) AMA, Sam 10-yr Googler in Web DevRel 10) Disable a HTML form while in-flight using fieldset 11) PWAs that download like apps ๐Ÿ—œ๏ธ 12) Matching elements with selectors in JS 13) Install This PWA To Continue 14) Google Assistant now supports "Open/Close" devices 15) Modern Web Components 16) What To Expect When You're Expecting To Drop IE11 ๐Ÿ—‘๏ธ 17) Divert Vertical Scroll To The Side โ†”๏ธ 18) Graceful Shutdown Is A Lie 19) Progress Indicator With Fetch

So you've decided to drop support for IE11 and move onto evergreen browsers only (IE11 is only about ~2% globally). That's great! ๐ŸŒฒ

With that in mind, here's a giant list of the features you should use, today (today being mid-2019), safely, without polyfills or feature detection. ๐Ÿ“ƒ

Before we start, of course, there'll always be old browsers. And, to be fair, browsers in emerging markets are more complex: like UC, KaiOS (based on an older Firefox), and Opera Mini. In these cases, I suggest serving no JS whatsoever (if possible), or encouraging users to upgrade. ๐Ÿคท

Let's go! โฌ‡๏ธ

The DOM

JavaScript Language

  • ES Modules, through <script type="module"> and import/export ๐ŸŽ‰

  • Template literals (with backticks)

  • Classes like class Foo { constructor() { ... } }

  • Functions! Arrow functions, rest parameters, async functions that allow await, generators which can yield

JavaScript Library

  • Promise and fetch (no need for XMLHttpRequest anymore ๐Ÿšซ)

  • Methods on Array: find, includes; and on String: includes, padStart and padEnd

  • The Proxy object, allowing for interesting approaches

  • Methods on Object: entries and values, for iteration (like Object.keys)

  • The URL object (useful to check for query params and work with URLs)

  • The currentScript property ("what file am I")

  • You can safely dispatch a new CustomEvent('....') rather than dealing with weird intializers

  • Symbol and friends

JavaScript + The DOM

Whole New APIs

  • Service Workers ๐Ÿฅณ

  • Web Assembly ๐Ÿ‘ฉโ€๐Ÿ’ป

  • Gamepad API ๐ŸŽฎ

  • Web Audio API ๐Ÿ“ฃ

  • Pointer Lock API: useful for HTML games and rich experiences ๐Ÿ๐Ÿ”’

  • Constraint Validation API (improved form validation) ๐Ÿ“

  • WebRTC ๐Ÿ“ฝ๏ธ

  • getUserMedia to get access to video, audio streams ๐Ÿ™

CSS

  • Grid ๐ŸŽ‰

  • CSS Variables, such as --foo: blue;, used with color: var(--foo)

  • Sticky Position

  • CSS filters, allowing for visual effects like invert, drop shadow and hue changes

  • Image object-fit (Edge only supports it on <img>), allowing you to make an image contain or cover its contents rather than stretch

  • Improved media queries for pointer or mouse access Fun fact: this was one of the first demos I wrote working on Chrome.

  • New CSS cursors 'grab', 'zoom-in', 'zoom-out'

  • The ::placeholder pseudo-element, for styling the placeholder text inside an <input>

  • Using initial or unset as CSS values

  • The vmax unit, which is a percent of whichever's larger: width or height

  • Going along with the JS method, the CSS @supports at-rule

  • Read-only and read-write pseudo-class selectors (:read-write seems the more useful of the two)

  • Stroke and fill on text

    • ... although supported on all evergreens, you'll need to include the -webkit- prefixes: yes, even for Edge and Firefox
  • Risky bugs in IE11 are no longer an issue:

Phew!

You got this far! Congratulations! ๐ŸŽ‰

If there's any I've missed, or good resources for any of these features, let me know below.

17 ๐Ÿ‘‹

Blog-A-Day in June (19 Part Series)

1) Rebuild only when necessary in Node 2) Civilization is a game you never lose 3 ... 17 3) Arrow functions break JavaScript parsers 4) Detecting Select All on the Web 5) Declaring JS Variables in 2019 6) Sam's dotfiles highlights 7) Automate Reading Form Results with ๐Ÿค– Chrome 8) Beyond appendChild: Better convenience methods for HTML 9) AMA, Sam 10-yr Googler in Web DevRel 10) Disable a HTML form while in-flight using fieldset 11) PWAs that download like apps ๐Ÿ—œ๏ธ 12) Matching elements with selectors in JS 13) Install This PWA To Continue 14) Google Assistant now supports "Open/Close" devices 15) Modern Web Components 16) What To Expect When You're Expecting To Drop IE11 ๐Ÿ—‘๏ธ 17) Divert Vertical Scroll To The Side โ†”๏ธ 18) Graceful Shutdown Is A Lie 19) Progress Indicator With Fetch

Posted on by:

samthor profile

Sam Thorogood

@samthor

Developer Relations for Web at Google.

Discussion

markdown guide
 

Developers should stop supporting these unmaintained browsers and force users into a better, faster, and more modern experience. Too much time and energy is spent on supporting browsers that people are using simply because they don't know any better.

If seeing the message "Your browser is not supported" was a common occurrence people would stop using IE 11. Instead we punish everyone sending out bloated transpiled and polyfilled code just to placate the tiny minority using browsers half a decade old.

 

I agree, but I also can't stress this enough: if your site is mostly content, then just ship content. For me and my projects at Google, this happens by only shipping <script type="module"> code. Everyone else gets the basic HTML version.

 

I'm doing something similar with Vue. The modern mode flag makes it easy. It creates two builds. Using the module and nomodule fags IE users get transpiled code and everyone else gets just minified code.

I've found that its not foolproof though. It can generate some wierd errors when it converts a generator into a jumbled mess of semi-equivalent functions. Luckily I don't have to worry about it. I got the go-ahead to drop IE. Giving them the transpiled code is literally all we are doing for them. If it breaks, its not an issue.

IE users see a big warning on a login screen telling them in no uncertain terms that their browser will not work. Its kind of disheartening how many lines I still see in the server logs with "Trident". I don't know why these people are so stubborn and insist on using a slow browser on a website that tells them that they will experience errors on that site.

 

Using XHR instead of the fetch API is not out of the question. Fetch isn't a 1:1 replacement, and as Chris Ferdinandi points out, requires two functions just to get the data in readable form. (In the first then() the data is in a stream.) Another great post by Glenn Stovall demonstrates how to write a small ajax function using XHR without any third party libraries.

 

You're not wrong, and the extra step is a bit misunderstood, although important if you want to stream large binary files (I used it in this PWA demo to show a %โ€”blink and you'll miss it).

I have a few unrelated thoughts:

  • await makes the flow much nicer than Chris' examples
  • I'm also surprised neither link uses onload, instead using the more confusing onreadystatechange (and this is actually a vote for XHRs).
  • the lack of support for responseType = 'json' in IE11 actually makes XHRs more confusing, since you just can't safely use that parameter and you have to add a JSON.parse call too
 

Very nice list.

Don't forget Custom Elements and Shadow DOM, which I think merit a place on this list since with Edgium, they're supported on all the Evergreens.

 

I'm avoiding Edgium. I think dropping IE11 gives you a big enough list that it's interesting right now.

 

This echoes lots of developer stories, sadly. On the flipside, I think primitives like Grid are so good now that many devs are just honestly forgetting about IE11.

And at least for CSS, IE11 will still serve, even if none of the elements are in the right place. And if your JS is done right for content sites, IE11 will still be readable!