daverupert.com

Team Incentives in Overwatch

Wed, 22 Nov 2017 00:00:00 -0600

The past year has brought me much joy (and curse words) to play Overwatch with friends and strangers on the Internet a few nights a week. It’s hard to overstate how much of a team sport this game is. Even at medium levels of gameplay a single underperforming player will cost the match. Unfortunately, there isn’t much of an incentive system to behave as a cooperative team member.

When you end a match in Overwatch there’s a little button in the bottom right of the screen that says “Stay as Team”. The button has a wonderful UX, it glows and dings just the right amount when clicked. But the general rule of thumb is: Never click this button. It is a penalty. The result is longer queue times and you’ll probably lose your next match.

Generally, the larger your team, the longer the queue time. Overwatch tries to match you up to a similarly sized team with similar user ranking. That takes time. Once a match is found, your ad-hoc 6-stack will then match up against a true 6-stack of people who play together all the time (because only really dedicated people would suffer 5-minute wait times to queue in a 6-stack). Now your team is at an extreme disadvantage, and will likely get demoralized and disband.

Losing badly negatively effects team play. No one thinks they’re the problem. It’s not uncommon for players to openly flame (which is a nice way to say “verbally harass”) other players instead of focusing on how to improve the team dynamic. Competitive tension is so high, posturing and prejudgement about who is going to cost the match often happens even before the match has started.

The long-term benefits of being a consistent team player are obvious, you win more games with better teamwork. But the short term reinforcement is that clicking the “Stay as Team” button produced a negative outcome. So we all queue up like lone Rōnin and repeat the cycle every 15-minutes.

I think a lot about incentives. Are there levers to pull in order to reduce toxicity and improve the overall experience?

Blizzard has recently started banning “one-tricks”, people who only play one character and won’t switch, in an effort to encourage team cooperation. While this is probably necessary, it’s a negative incentive for bad teamwork. I’d love to see more positive incentives for good team work.

Here are just some examples:

A sportsmanship ranking that factors into match matching heuristics.
Clan feature? Heck, Blizzard made World of Warcraft.
Instead of Play of the Game featuring only a single player, maybe POTGs could highlight awesome teamwork (combo-ults, etc).
Instead of performance voting at the end of each map, you vote for “Most Positive” or “Most Grouped Up” team member.
Improved team queue times.
Artificially increasing queue times for solo players after certain rank.
Special loot for people who successfully queue up in teams (e.g. Rewards for 100 games played as a 3/4/5/6-stack, etc). There’s some science to suggest in-game loot and player performance are interconnected.

I don’t really care what it is, but I’d love to see Blizzard thinking and talking about positive incentives to nudge players to play well with others. Not just banhammers.

Happier HTML5 Form Validation

Fri, 17 Nov 2017 00:00:00 -0600

I recently embarked on improving the client-side form validation for a client. There were about 400 lines of form validation code stuffed inside a 1000 line form_helper.js. I looked for lightweight form validation scripts but after some hemming and hawing I decided to try my hand (again) at native HTML5 Form Validation.

If you’ve ever experimented with HTML5 Form Validation, you’ve probably been disappointed. The out-of-box experience isn’t quite what you want. Adding the required attribute to inputs works wonderfully. However the styling portion with input:invalid sorta sucks because empty inputs are trigger the :invalid state, even before the user has interacted with the page.

I finally sat down and spent a couple days trying to make HTML5 Form Validation work the way I want it. I had the following goals:

Leverage browser-level feedback, free focus management and accessible labelling
Only validate inputs on submit
Styling with .error class

With this wishlist in hand, I set off and found a solution that works with only 6 lines of code.

The Setup

First we create a basic HTML5 form with a required attributes on inputs we want to validate…

<form action="/users/signup" method="post">
    <label for="email">Email</label>
    <input id="email" type="email" required>
    ...
    <input type="submit" value="Submit">
</form>

And then we need the CSS for the error state…

input.error {
  border-color: red;
}

Again, we want to use a CSS class and not the input:invalid pseudo-class because even before the user interacts with the form on the page, input:invalid makes it look like the user made an error. This is a bad UX. Never blame the user.

😱 Form Validation in 6 Lines of JS!

I instinctually reached for the submit event to try and manipulate error handling. However, this won’t work because the invalid event from the inputs block the form’s submit event from firing. It’s good that our form won’t try to submit invalid data I wasn’t sure how to validate a form that was never submitted. I tried a few grossly complex workarounds.

Eventually, I discovered the simplest solution by hooking into the input’s invalid event. Just before the submit event, the browser performs a form.checkValidity() check which checks all the inputs. All inputs with invalid data fire the invalid event to say “Hey, I have invalid data!” It’s here that we can apply the error class we need.

const inputs = document.querySelectorAll("input, select, textarea");

inputs.forEach(input => {
  input.addEventListener(
    "invalid",
    event => {
      input.classList.add("error");
    },
    false
  );
});

🎉 We did it! Now when a form is submitted, the invalid event fires on invalid inputs, and we add an .error class which adds a red border around the input. And we’re done! 172b. Form validation that fits in a tweet.

♿ The best part is we’re leveraging the browser’s focus management and accessibility behaviors. When a form submission is prevented, the first :invalid input gets focused and screen readers read out the error message for that input. This is great. Focus management isn’t fun to code.

💪 We’re also leveraging HTML5 input types for common pattern matching. input[type="email"] expects an email address and the error messaging will say something along those lines. Same with input[type="url"], input[type="number"], etc. HTML input types are basic but powerful stuff.

But wait there’s more complex things we can do!

Optional: Validate on Blur

If you like your forms to immediately flag errors after leaving each input (which that’s fine, I’m not judging), it’s pretty easy to add that functionality. In fact, it’s just an additional 3 lines of code…

input.addEventListener("blur", function() {
  input.checkValidity();
});

This On :invalid inputs, it will trigger the invalid event and add the .error class we programmed above.

Optional: Validate Regex Patterns

I thought this was going to be awful and ruin my simple solution. Custom error messaging could be gnarly as well. But NOPE. HTML gods spared me. Behold, regex pattern matching in ZERO lines of JavaScript!

By using a title attribute to describe the expected data input and a pattern attribute with a regex pattern, we can pretty much validate against anything we want.

<label for="alpha">Alphanumeric Only</label>
<input id="alpha" type="text" pattern="[a-zA-Z0-9]+" title="Only alphanumeric characters allowed" required/>

There’s even a website, HTMLPattern.com, that has the regex for almost every kind of validation you’d ever want to create.

Demo: Putting it all together

Here’s a Codepen of a complete working form with Pattern Matching using this approach.

See the Pen Native form validation onsubmit with pattern?? by Dave Rupert (@davatron5000) on CodePen.

Tradeoffs

Every solution is a system of tradeoffs. The major tradeoff we’re making here is that in leiu of controlling the styling of client-side validation errors, we’re leveraging the browsers native tooltip-style validation messages. It doesn’t look the coolest, but it works really well for casual client-side validation.

Instead of being perscriptive about error messaging, we use what the browser natively gives us. We’re of course doing server-side validation and are free to style those errors however we want (usually that’s a more critical error and needs a better UX).

If this is unacceptable, Hyperform.js is a pretty small (32kb minfied / 9kb gzipped) reimplementation of the same HTML5 Form Validation API in JavaScript, but with additions to iron out some weird parts.

Let me know if you try this and have any problems with the approach. I’ll probably use this as a starting point for every project ever. Happy coding!

The Medium

Fri, 10 Nov 2017 00:00:00 -0600

I’ve had a few similar conversations lately with colleagues I admire in the Web industry. They’ve all mentioned that they are a bit tired and burnt out. This happens, especially over time. But there is a trend. For most it comes down to the fact that the etherial World Wide Web, The Medium that we all love, appears broken or unrepairable.

The Medium which tied the world together is being used and exploited to drive us apart. Social networks promote abuse. Our data and personal information are weaponized against us. Chatbots competitively one-up eachother over conspiracy theories, gathering data. The endless daily news cycle of multiple things to be outraged about is exhausting for most non-robots. In many ways the central question of “What’s happening?” has changed to “What are we mad about?”

It’s hard to divorce the The Medium from the problems of the Physical World. Death. Struggle. Injustice. Politics. This sustained level of IRL civic engagement is tiring, but I will keep my eyes on the prize, hold on.

Alas, even the etherial currency created for The Medium is now working to destroy Physical World. One Bitcoin transaction now uses as much energy as your house in a week. If it were me, I’d shut down this experiment. It is immoral.

But that’s part of the problem, isn’t it? We’re building things without regard for the ethical implications. Especially, if ignoring the ethical ramificiations happens to create wealth. “Peak capitalism” I guess it’s called. As we yield control over to artificial intelligence and learned machines, I can only hope their trainers considered more than efficiency and capitalism.

The Medium is slowly being owned by a handful of companies. Reports of the Web’s death are greatly exaggerated, but concentrations of power rarely end up well for the general public.

For the physical pixels and bytes delivered to the glowing screens, I have heard specific concerns as well.

Recently in a talk about design I heard that “UX is a solved problem.” This particular use of “UX” was in the context of GUIs. That’s a bit deflating and hard to rebut. But maybe in some ways this is a relief, in less than 20 years we’ve managed to upload enough wisdom and shared knowledge into The Medium, that problems are no longer problems. Our knowledge can be automated and we can start thinking about bigger problems.

As browsers have gotten better and eliminated age-old problems, the build tools have gotten more complicated. In a recent talk on Source Maps I heard that “JavaScript is a compiled language”, which is to say the output sent to the browser more resembles a binary format than its human readable source. This is true, though not required. For me, I feel the complex toolchain disconnecting me from the instant gratification of publishing to the Web.

Lord, save me from my Ludditism.

I share the disillusionment. This version of The Medium is not The Medium I want or fell in love with. This is a love story about humans connecting across continents. I want to be hopeful even at the risk of being naïve.

I have to keep reminding myself that I do have some control. I can build The Medium I want. I can cling to what’s good. And this gives me hope.

Is Heart the greatest rock band ever?

Thu, 02 Nov 2017 00:00:00 -0500

Let me break this down for you.

Two women leads. This is rare even today. This Lead Vocalist Ann Wilson and the lead guitarist Nancy Wilson are incredible. They both shred. Oh an…
They were sisters. Did you notice that? Not only were they rock’n’rollers, but sisters. This is a 10x awesome factor.
Ann Wilson shreds. Still quite possibly the most heavy metal vocalist ever.
Nancy Wilson shreds even harder. I’d trade all my teeth to have even just a quarter of Nancy Wilson’t raw talent and guitar skills.
The other guitarist Roger Fisher played a two necked guitar. This is all you need to know. That is bad ass.
Roger Fisher also wore a satin karate gi on stage. I’m gonna let that one sink in. Then when you’ve recooperated from this mind blowing fact, checkout these wierd thong bellbottoms thing and check yourself into the hospital because you just got rocked.
They did all this before MTV. MTV switched on and got flooded with glam rock. But that didn’t stop them, they adapted, sissied up and met that synth rock pop music and grabbed another handful of Billboard Top 10 hits.

Look. You’re not gonna win on this one. You probably just ought to admit I’m right. You’ll probably drop the “Led” on me and think you countered my lvl 70 wizard spell, but in the year 2017 ain’t nobody got time to listen to a 42-minute guitar solo.

Toto? Did you say “Toto”? Well, now, maybe you have an argument…

Me listening to any song by The Police

Wed, 01 Nov 2017 00:00:00 -0500

The following is an accurate account of me listening to any song by The Police:

“Aw, hell yeah. The Police. Turn it up.”

“Huh. This guitar. Rrrrrough.”

“Chorus pedals.”

“So um. Are The Police a good rock band or a shitty reggae band?”

“What is up with this drummer? The last measure is super crammed and sorta all over the place. But I can’t tell if this is good drumming or bad drumming so I better just nod and make cool faces when it gets weird.”

“Was that a harmonica?”

“These guys are all blonde and look like eachother huh.”

“Whoah. What’s this song actually about?”

It’s neat that The Police hits tend to have an unexpected twist. “Every Breath You Take” is a devotional about stalking someone. “Roxanne” is a powerfully emotive song about falling in love with a prostitute. “So Lonely” is a quite upbeat song about being lonely, broken-hearted, and depressed. In “Message in a Bottle” he’s not rescued by sending out an S.O.S. but instead receives millions of messages from other castaways.

Transpiled for-of Loops are Bad for the Client

Thu, 26 Oct 2017 00:00:00 -0500

This is the story of picking the right JavaScript for-loop. On a client project Julian Jones and I casually wrote heaps of NodeList.prototype.forEach() for the DOM manipulation in our Pattern Library.

const inputs = document.querySelectorAll('input, select, textarea');

inputs.forEach(function(input){
    console.log(input);
});

forEach() on a NodeList is very new. It didn’t even work in Edge until this summer so I knew it would fail in older browsers. Our strategy was to use Babel to fix this for us. Unfortunately, we learned that Babel doesn’t transpile forEach() statements. Hm. Twitter apparently thinks you’re an idiot if you didn’t know this about Babel, so we set off to look for a workaround.

`for...of` Loops to the Rescue!

After some initial exploration, we decided to switch to for...of-loops instead.

const inputs = document.querySelectorAll('input, select, textarea');

for(let input of inputs) {
    console.log(input);
}

The syntactic sugar of the auto-assigned variables gave this the edge over writing traditional for-loops. Running it through the Babel REPL tool gave us some confidence that it would transpile giving us the backwards-compat we needed.

'use strict';

var inputs = document.querySelectorAll('input, select, textarea');

var _iteratorNormalCompletion = true;
var _didIteratorError = false;
var _iteratorError = undefined;

try {
    for (var _iterator = inputs[Symbol.iterator](), _step; !(_iteratorNormalCompletion = (_step = _iterator.next()).done); _iteratorNormalCompletion = true) {
        var input = _step.value;

        console.log(input);
    }
} catch (err) {
    _didIteratorError = true;
    _iteratorError = err;
} finally {
    try {
        if (!_iteratorNormalCompletion && _iterator.return) {
            _iterator.return();
        }
    } finally {
        if (_didIteratorError) {
            throw _iteratorError;
        }
    }
}

The transformed output of for...of-loops is an ugly try {} catch {} finally { try {} finally {} } statement, but whatever, it solves the problem and computers be computers, right?!

However. This doesn’t work in IE11. Surprise! 'Symbol' is undefined.

Symbol.iterator is a relatively new ES6 language feature that doesn’t exist in IE11. This error was a bit unexpected in that even with an IE > 8 flag, Babel only takes care of the syntax not the feature support. To put it another way, I was surprised the backwards-compat machine didn’t take care of the backwards-compat.

Ironically, browser support for for...of is greater than Symbol.iterator support.

Chalk it up again to my ignorance of how Babel works, the feedback from Twitter was that I needed to polyfill Symbol. First stop, I looked at babel-polyfill.js but was surprised to see it is 259kb unminified/uncompressed. I’m sure it does a lot, but the entire JavaScript bundle for the whole site is only 93kb unminified/uncompressed. It’s hard for me to recommed a +300% increase.

Then it was suggested to use Babel with preset-env and babel-polyfill which if configured right (heh) injects an import statement for es6.symbol.js which Webpack then takes and bundles together for the client. Once that’s all configured and npm install‘d, we finally have a for-loop!

I started getting uncomfortable with my options.

Re-looking at the transpiled output, we wondered if traditional for-loops were a better way to avoid the try-catch mess. Fortunately, we decided to retrace our steps and re-evaluate NodeList.prototype.forEach()…

`NodeList.prototype.forEach()` for the Win!

forEach() was our original choice and has the syntactic sugar we craved. We were surprised to discover the NodeList.prototype.forEach() polyfill is only ~200b. New browsers leverage the new language features as well. This lightweight solution seemed too good to be true so we started by rolling back a few for-loops to see the impact. After each save, we noticed the bundle size dropping by ~700b for each for-loop we reverted.

All said and done, we converted 15 for-loops to NodeList.prototype.forEach() and shaved off 9kb from our unminified/uncompressed bundle (10% reduction) and increased our browser compatibility back to IE9.

Conclusion: Transpiled `for...of` Loops are Bad for the Client

This leads me to my link-bait title conclusion; I think for...of loops being run through Babel and served to the client is an anti-pattern. Transforming adds 658b of try-catch code per for-loop. With something as foundational as a for-loop, this adds up to a not insignificant amount of non-DRY code delivered to the client. The Babel fallback uses Symbol.iterator which doesn’t increase compatibility in older browsers and leads to more polyfilling. Newer browsers don’t leverage new language features, they get the transpiled try-catch statements.

If you live in a ES6+-only Browsertopia, then for...of loops are probably great but I’d question the need to transpile that language feature. There are advantages of ES6 for-of loops, but that seems limited to when you want to break; and exit a loop early instead of looping through every item. For client-side DOM manipulation, I typically find myself looping through every element I have querySelected.

I don’t enjoy living in absolutes, but I think it’s important to find lightest possible solution that meets your needs. In this instance NodeList.prototype.forEach() allowed us to write cleaner code and output less code and I believe that it is a better approach on the client.

Bonus conclusion: What the hell are we doing here?

This story is just a personal reminder for me to repeatedly question what our tools spit out. I don’t want to be the neophobe in the room but I sometimes wonder if we’re living in a collective delusion that the current toolchain is great when it’s really just morbidly complex. More JavaScript to fix JavaScript concerns the hell out of me. Especially given that JS on the average mobile client is an expensive resource.

I’m not sure this is an issue with Babel per-se, but maybe a more meta topic of the cost of polyfilling. In fact, a quick look at my codebase tells me that picturefill makes up ~55% (47kb unminified/uncompressed) of the total JavaScript bundle – and we only use it for the logo!

All of these “problems” minify and gzip away. Sure, sure. Except that minified picturefill is still ~33% of the total bundle. So it’s still an issue. But the issue isn’t size alone, it’s that a majority of my codebase only does one tiny task and existed unquestioned¹.

I am responsible for the code that goes into the machine, I do not want to shirk the responsibility of what comes out. Blind faith in tools to fix our problems is a risky choice. Maybe “risky” is the wrong word, but it certainly seems that we move the cost of our compromises to the client and we, speaking from personal experience, rarely inspect the results.

Annnnd you know that ya boy is working on a ~3kb sizes-less version of a <picture> polyfill that minifies down to ~1kb. Currently works in IE9-IE11. ↩

The Era of Newshammer

Mon, 16 Oct 2017 00:00:00 -0500

Welcome to the brand new Dave-Rupert-Dot-Com! It’s been about 5 years since I did any kind of redesign to my site and it feels good finally get this done. Allow me to give you a tour of some of the new features.

Meet Newshammer

Based on a dumb twitter joke, I commmissioned an awesome illustration from my friend and D&D cohort Kyle Ferrin. Kyle has an amazing illustration style and I couldn’t be happier displaying his work on my website. And once I got the illustration from Kyle I was like “Yes. This will basically be the whole site.”

From a webperf perspective, Newshammer is a hefty 252kb transparent PNG, optimized down to a 48-bit color pallete. I even manually exported a WebP for the first time in my life (185kb). I struggled with the number of kilobytes a bit so I cut a mobile version as well at 77kb and 68kb for the PNG and WebP respectively. I’m fairly happy with the results.

CSS Variable Themes!

My favorite feature of the site is that I finally have a good art direction and theming structure. Using CSS Custom Properties (“CSS Variables”), I can easily theme any part of the websites I want. A theme for my site looks something like this:

:root.theme-minions {
    --bg: yellow;
    --text: black;
    --link: blue;
    --link-active: lightblue;
    --nav: blue;
    --headings: black;
    --border: blue;
}

With just ~7 lines of CSS I can completely change the look and feel of my site. I 🧡 this. If I need more flexibility (e.g. fonts?), it’s as simple as rolling a value up into a :root variable and then overriding as necessary. Here are some of the default themes shipping in Dave Rupert 4.0: Newshammer…

Feel free to web inspect your own, take screenshots, and send them my way. On some of the themes, I even brought back some grunge background textures from Transparent Textures. Mmm… dirty screens.

CSS Variables on Client Sites?

I have a lot to say about CSS Variables and theming but the tl;dr is they’re great. But I don’t know yet if I’d recommend having this theming setup on client sites or pattern libraries.

Where I really think CSS Variables would shine is inside a Web Component’s Shadow Root as opposed to the global :root. I can explain this in another post, but theming could be done at a component level quite efficiently. <button class="button button--primary"> could become <my-button theme="primary">. I think this would fundamentally change how we write CSS today. Component themes wouldn’t re-assign property values, themes would just modify variables.

Bummer that HTML Imports got shitcanned tho.

Webfonts are back, baby!

I ditched webfonts for system fonts recently under the feeling that I wasn’t getting enough value for the kiloboytes and FOUT. It was fine but the 300 weight of Segoe for body text was nearly illegible on Chrome on Windows. I got a handful of complaints about that. So I made a change.

Two weights of Rubik do the majority of heavy lifting on the site now. Rubik is a squatty, thick, slightly-rounded sans-serif. It is a weird futuristic sans-serif and the “J” is super fucked up, but that’s maybe why I like it. In general, I find the typeface much more quirky and enjoyable to read than a system font.

The other font is Domine, a charming serif, that is used exclusively for blockquotes on post templates.

I haven’t settled on a font-loading strategy I love, so I’m just trying good ol’ fashioned @font-face with font-display: swap. This means Chrome will prefer a non-blocking FOUT experience. Edge defaults to a FOUT experience. Firefox has font-display behind a flag. And iOS… render-blocked like a mofo. When, O Browser Gods, will you release me from this prison!?

I almost went with 3 weights of Rubik but backed down. I’m hoping in the near future Variable Fonts make these sort of compromises irrelevant.

Before/After

I could bore you with some other CSS nerdery, but let’s look at some performance stats. I like to do this when I’m changing things up just to see how things are shaking down (All measurements on 3G Slow).

Page	Start Render	Speed Index	DOMComplete	Load	Bytes In
Home (Before)	1.079s	1079	3.498s	3.705s	69 KB
Home (After)	1.177s	1783	5.530s	5.738s	314 KB
Article (Before)	1.288s	1291	6.164s	8.108s	413 KB
Article (After)	1.395s	1400	5.974s	7.651s	388 KB

Oops. It appears I’ve quintupled the size of the homepage and nearly doubled load times. This is Newshammer and my webfonts’ fault. I’ve slimmed down my article template a bit so that’s good news.

While this is not ideal, it’s a bit expected. My site was maybe artificially fast before. I tore it down to skin and bones. I’m also not doing any Critical CSS work this time around because theming doesn’t exactly mesh well with CSS-in-Head strategies. Some intentional decisions are slowing things down.

And here’s the deal, I can iterate going forward. Launch day metrics aren’t always final. I can get better. Switching over to HTTP/2, Service Workers, and more are on my TODO list.

But for now, let’s kick this thing off…

A good science fiction story...

Mon, 02 Oct 2017 00:00:00 -0500

“A good science fiction story should be able to predict not the automobile but the traffic jam.” – Frederik Pohl

One of my favorite quotes on Science Fiction is from Frederik Pohl. Pohl got his start writing for the sci-fi pulp magazine Amazing Stories in 1937 at the age of sixteen and went on to write books and become the editor of Galaxy magazine.

Pohl’s quote on “good science fiction” inspires me when thinking about technology. Good technologists (the ones manufacturing the science fiction) should be able to predict not just the technology, but the problems it creates. Thinking two steps ahead.

Then yesterday…

Y'all pile on us. You really think the issue doesn't weigh on us? And you're so dismissive of the Trust and Safety team. We're all people.
— Biz Stone (@biz) October 1, 2017

This is a tweet from Twitter co-founder Biz Stone replying to Mike Montiero about a public challenge to a debate. @Biz and @Jack set out to make a platform that millions of people use. They took in millions of dollars in VC funding to make that happen. They made millions of dollars when that company went public. But yet, they failed to anticipate the event when a world leader (ours) would begin inciting a nuclear war on their platform. And what astounds me most is that they, the millionaire profiteers of this endless newscycle, feel victimized?

Facebook too has failed to predict how their algorithm could have allowed foreign propaganda to influence our electoral process. They failed to see how their algorithm which feeds our confirmation biases might also radicalize us and balkanize politics. A failure to anticipate.

There’s a running Twitter meme that we’re now living in an alternate timeline; the worst possible one. And to some extent I believe that we are. We’re living in the timeline that invented the car, but didn’t anticipate the traffic jam.

I wanted to end with a similar quote from Ray Bradbury on the function of science fiction…

“The function of science fiction is not only to predict the future, but to prevent it.” – Ray Bradbury

Dave Goes to the Microsoft Edge Web Summit 2017

Sat, 23 Sep 2017 00:00:00 -0500

Last week I had the pleasure of attending the Microsoft Edge Web Summit. This was the 3rd Edge Web Summit continuing the new tradition of Microsoft being A LOT more open and transparent about their browser’s development.

The Summit itself was very rewarding from a people perspective. I found myself surrounded by my Twitter feed and was able to finally meet and chat in-person with quite a few people I admire from their talks, writing, and open source contributions. Microsoft really is acquiring lots of great talent right now.

As an Edge user, it was a pleasure to meet with and talk to the Edge developers. They heard my feedback and niche gripes, but my primary interest over the whole event was getting a sense of where Edge is going and what Edge developers think needs to be focused on and improved.

Six Must-See Talks from the Edge Web Summit

All the talks from the Summit were great and informative but I wanted to highlight ~6 of the 14 talks I think are generally appealing and worth watching. I broke them up into two categories: How browsers work & New features and APIs.

1. How browsers work

I think most of us take for granted the hard work that goes into building a browser. These talks really illuminate the effort required to update Edge (and other browsers are doing similar things) while the software is being used by millions of people.

“Decisions, Decisions, Decisions: How we plan at Microsoft Edge” by Greg Whitworth

This was one of the last talks but I think it does a great job framing how features we developers crave get shipped in a browser. Every piece of software is a system of compromises. Limited time and resources means the Edge team must prioritize which features are most important. Greg Whitworth did a great job explaining how Edge uses feedback from UserVoice to inform their product decisions.

“Building a safer browser: Four guards to keep users safe” by Nathan Starr

I’ve never heard a talk like this before. Nathan Starr explained in terms I could understand the mechanisms that Edge uses to secure the browser against Remote Code Execution. He walked through the “Four Guards” Edge has employed to cut off the three most common attack vectors.

“What’s new and beyond for the Microsoft Edge DevTools” by Jacob Rossi

Jacob Rossi opens his talk with a bit of honesty; Edge’s F12 Developer Tools are a bit behind. A lot of it is carryover code from the IE days and Edge has begun the process of untangling the legacy code and making it all faster.

2. New Features and APIs

Based on my Twitter mentions, a lot of people still feel the Web is being held back by Edge. I understand the sentiment, but I also like to hear why people think that. Usually it’s some pet feature is missing. Edge is working hard to close the gap. And what I like about these talks is that they aren’t Chrome-only things or Apple-only things, throughout the conference it felt like Edge was talking about “Web Things”.

“CSS Grid: Bringing true two-dimensional layout to the web” by Melanie Richards

This was a fantastic talk. I’ve heard more than a few CSS Grid talks, I use Grid daily, and I still learned a lot. It’s maybe the best “How-to CSS Grid” talk I’ve ever heard and Melanie Richards knows what she’s talking about because she helped build the exemplary summit.microsoftedge.com site.

“Pay the Web Forward: Making payments simpler on the Modern Web” by Molly Dalton

Molly Dalton opened her talk illustrating how web payment capture forms have basically been the same ~14.5 inputs for the last 20 years. It’s time to modernize this. The talk contains a nice walkthru examples showing how the Payment API can revamp the checkout flow.

“Mixed Reality in Microsoft Edge with WebVR” with Nell Waliczek and Lewis Weaver

WebVR probably isn’t on everyone’s radar, but Nell Waliczek and Lewis Weaver’s talk showed how the Promise-based WebVR API works. Microsoft and its OEM partners have some intriguing “Mixed Reality” devices on the horizon. I get excited about WebVR (over all the other VRs) and I’ve built some WebVR experiences with Aframe. I’d love to get my hands on one of these headsets and controllers.

A Summit Summary

The common thread between all of my conversations with Edge developers was that the decision to break away from IE was a great one. Edge is being rebuilt from the ground up; a new layout system, a new networking system, a new DOM tree parser, a new JS engine, and more. Are all coming together to unblock the main UI thread resulting in a better, faster, and more secure browser. You really get a sense that forking Internet Explorer was the best thing to happen for Edge and its users. A risky, monumental re-platforming project that has paid off.

I’m also very encouraged by Microsoft’s support of Progressive Web Apps. Service Workers will be turned on by default in Edge 1617 (behind a flag in 16). Microsoft has plans to scour the web and ingest PWAs into its Windows Store. Microsoft has created tools like ManifestStation and PWA Builder which give you a jump start on you Manifest and your Service Worker. You can even get an .appx bundle (a “Hosted Web App”) that you can deploy to the Windows Store right now if you want.

Edge and Windows embracing PWAs is part of the reason I stuck with Windows and I’m excited to see how PWAs on Windows plays out in the near near future.

Breaking the Grid

Tue, 05 Sep 2017 00:00:00 -0500

As a Front-End developer nothing bothers me more than seeing an unexpected horizontal scrollbar on a website. While building out a checkout layout with CSS Grid I was surprised to find something mysterious was breaking the container. I thought Grid sort of auto-solved sizing.

Eventually I found two ways to break CSS Grid. As it would happen, I was doing both in the same layout. 🤦‍

#1: Overflow-x Elements break the Grid

We had a subnavigation pattern in our checkout that would overflow-x to reveal more payment options. Even with overflow-x: auto applied the Grid Item was being sized to the scrollWidth of the subnavigation. Turns out any overflow-x element like a <code> block or a responsive table solution would break the Grid. Here’s a reduced test case:

See the Pen Overflow-x Elements Inside CSS Grid (bug? behavior?) by Dave Rupert (@davatron5000) on CodePen.

Typically overflow-x: auto fixes horizontally overflowing elements. But nope, not here. The next escalation is to wrap the element and try a bunch of overflow: hidden tricks to force the layout to obey. Still nope.

The reason this is happening is that Grid Items have a default min-width: auto and will auto-size to the content inside. It sets its min-width based on the width of overflowing block. So to fix an deeply nested overflowing child, you counter-intuitively ignore the parent element and go all the way up the DOM tree to the Grid Item and zero-out the min-width.

.grid > * { min-width: 0; }

This will result in Grid Items with overflowing content to be sized correctly. But not always…

#2: Form Controls break the Grid

Our layout was also using Grid to put form inputs side-by-side. I created a reduced test case of different input types in a CodePen to isolate the problem. If you squeeze the window until you get a horizontal scrollbar ~380px you’ll see inputs spilling out of the grid track.

See the Pen CSS Grid PRBLMZ 😢😓😭 by Dave Rupert (@davatron5000) on CodePen.

Typically to fix inputs like this you’d apply max-width: 100%, but while that mostly fixes Chrome and Safari some elements and elements in Firefox and Edge still break out of the grid track.

Why is this happening? Because <input> elements and their ilk (<img>, <progress>, <select>, <video>) have the potential of being something called Replaced Elements.

What the heck are Replaced Elements?

According to MDN, a replaced element is an element whose representation is outside the scope of CSS. These are situations where the browser takes your markup and injects a “Shadow DOM-esque” element. <video> is a great example of this, but lots of form controls also fall under this umbrella.

Replaced Elements exist in somewhat of a specification no man’s land. The styling and rendering rules around them aren’t clearly defined, just that they “often have intrinsic dimensions”. This results in browsers coming to different conclusions for the default appearance of certain elements or whether Replaced Elements are used at all. You can see in this screenshot how browsers use Replaced Elements differently and their varying sizes.

For our situation, some input elements have a phantom “intrinsic size” applied by the browser. It doesn’t show up as a browser-defined style in the Styles tab nor the Calculated Styles tab, but is a min-width of around ~180px for a standard <input type="text">.

In order to fix elements spilling out of the grid track in a cross-browser way, we have to override this intrinsic sizing of replaced elements.

/* Apply max-width to Replaced Elements and Form controls */
img, video, audio, canvas, input,
select, button, progress { max-width: 100%; }

/* Make file and submit inputs text-wrap */
input[type="file"],
input[type="submit"] { white-space: pre-wrap; }

/* Fix Progress and Range Inputs */
progress,
input[type="range"] { width: 100%; }

/* Fix Number Inputs in Firefox */
@supports (--moz-appearance: none) {
  input[type="number"] { width: 100%; }
}

There’s a side effect here where progress, range, and number now will always occupy 100% of the grid track. This could be overriden or customized.

Are these Grid implementation bugs? Not exactly.

This behavior –as someone on StackOverflow pointed out– is actually to-spec. Grid is inheriting Flexbox’s behavior around min-width: auto and Replaced Elements have min-width in their intrinsic dimensions. So it’s not a bug per se.

However, for nearly every one of my layouts, this will result in me using a utility class I’ll apply to mis-behaving Grid Items. In the interest of staying on-brand, I’m calling it “Fit Grid”.

/*
 _______  ___   _______    _______  ______    ___   ______  
|       ||   | |       |  |       ||    _ |  |   | |      | 
|    ___||   | |_     _|  |    ___||   | ||  |   | |  _    |
|   |___ |   |   |   |    |   | __ |   |_||_ |   | | | |   |
|    ___||   |   |   |    |   ||  ||    __  ||   | | |_|   |
|   |    |   |   |   |    |   |_| ||   |  | ||   | |       |
|___|    |___|   |___|    |_______||___|  |_||___| |______| 
by Dave Rupert
Read More: https://daverupert.com/2017/09/breaking-the-grid/
*/

/* 
 * Remove `min-width: auto` from Grid Items
 * Fixes overflow-x items.
 */
.fit-grid > * { min-width: 0; }

/* Apply max-width to Replaced Elements and Form controls */
.fit-grid img,
.fit-grid video,
.fit-grid audio,
.fit-grid canvas,
.fit-grid input,
.fit-grid select,
.fit-grid button,
.fit-grid progress { max-width: 100%; }

/* Make file and submit inputs text-wrap */
.fit-grid input[type="file"],
.fit-grid input[type="submit"] { white-space: pre-wrap; }

/* Fix Progress and Range Inputs */
.fit-grid progress,
.fit-grid input[type="range"] { width: 100%; }

/* Fix Number Inputs in Firefox */
@supports (--moz-appearance: none) {
  .fit-grid input[type="number"] { width: 100%; }
}

Heavy-lifting layout grids need to be agnostic of the content inside of them and tolerant to support a wide variety of scenarios. I’ll likely need to include this on every project to make Grid Items as tolerant as possible. While not a bug, I can see this as being “Clearfix 2.0” territory.

If it were up to me, I think Replaced Elements should always obey and fit inside the Grid Track. I’d love it if browsers could come together on this. The only other question I have is whether or not all Form Controls should occupy the entire grid track like progress, range, and number require. The solution is input, select { width: 100% }, but my gut is telling me not everyone would want that.

If you have improvements, I’d love to hear it them and I’ll put this up on GitHub, but please test it in every browser before claiming a fix. Thanks, d00dz.

Thanks to Greg Whitworth from Microsoft Edge for helping me debug and understanding Replaced Elements a lot more.