Think you know the top web browsers?

If I had to blindly guess about global marketshare, I would have gotten it wrong. I probably would have forgotten about UC browser (kind of the point of Peter O'Shaughnessy's article) that's so huge in Asia. I would have guessed Firefox has a slight edge on Safari (turns out Firefox is half the share of Safari), and that Edge would be outpacing IE by now (also only half).

This is good dinner party conversation fodder, but I wouldn't base any major decision making on it. The only stats that matter at your websites stats.


Legally Binding Electronic Signatures with eversign

There are few things more obnoxiously tedious than being asked to sign a document over email, where they tell you to print it, sign it, scan it, and email it back. One time I Photoshopped my signature onto a document, and they were able to tell somehow and made me go through the whole rigamarole instead.

We're working with highly sophisticated computers here, can't I sign this thing with the web somehow? Yes, you can! As long as the company asking is using eversign, that is.


The Power of Custom Directives in Vue

When you're initially learning a JavaScript framework, it feels a little like being a kid in a candy store. You take in everything available to you, and right off the bat, there are things that will make your life as a developer easier. Inevitably though, we all reach a point working with a framework where we have a use-case that the framework doesn't cover very well.

The beautiful thing about Vue is that it's incredibly feature-rich. But even if you have an edge case not covered by the framework, it's got your back there as well, because you can quite easily create a custom directive.


When Does a Project Need React?

You know when a project needs HTML and CSS, because it's all of them. When you reach for JavaScript is fairly clear: when you need interactivity or some functionality that only JavaScript can provide. It used to be fairly clear when we reached for libraries. We reached for jQuery to help us simplify working with the DOM, Ajax, and handle cross-browser issues with JavaScript. We reached for underscore to give us helper functions that the JavaScript alone didn't have.

As the need for these libraries fades, and we see a massive rise in new frameworks, I'd argue it's not as clear when to reach for them. At what point do we need React?


Total HTML Agnosticism

A couple of good posts on technology agnosticism lately.

Brad Frost says the design system itself is higher level than any particular technology:

... it doesn't bet the farm on any one technology, the system is able to adapt to inevitable changes to tools, technologies, and trends.

Jonathan Snook thinks Mustache is good choice for otherwise technologically agnostic templating:

I like it because of its simplicity and because it requires the heavy work with the data to be done before it sees a template.


A Vue.js introduction for people who know just enough jQuery to get by

Matt Rothenberg with a Vue.js tutorial playing off Shu Uesugi's 2015 article React.js Introduction For People Who Know Just Enough jQuery To Get By. Matt doesn't spend quite as much time comparing what building the UI component would be like in jQuery as compared to Vue as Shu did comparing with React, but it's just as well. It's literally the exact same UI component (a New Tweet box) as the React article, and now, 2 years later, without downplaying or knocking jQuery, most folks are ready to just jump in with new frameworks.

Remember we have a guide as well!

Between the Lines

Media queries are great for changing values in sudden snaps at different screen sizes. But, combining the power of calc() and viewport units like vw and vh , we can get an awful lot of fluidity across our layouts. For this we'll use a technique called linear interpolation.


Focusing a `background-image` on a Precise Location with Percentages

Let's say you have an element with a background-image, where only part of the image is visible, because the image is bigger than the element itself. The rest is cropped away, outside the element.

Now you want to move that background-image such that you're focusing the center of the element on a specific point in it. You also want to do that with percentage values rather than pixels. We're going to have to get clever.



The font-display property defines how font files are loaded and displayed by the browser. It is applied to the @font-face rule which defines custom fonts in a stylesheet.

@font-face {
  font-family: 'MyWebFont'; /* Define the custom font name */
  src:  url('myfont.woff2') format('woff2'),
        url('myfont.woff') format('woff'); /* Define where the font can be downlaoded */
  font-display: fallback; /* Define how the browser behaves during download */



I was on vacation this past week and at some little beach gift shop they were selling this really cool big thick book called Ocean: A Photicular Book. You've probably seen something like it before... a plastic card that shows different images depending on how you are looking at it. This book is extremely well done in that the image are very high quality, and the design of the book makes the images move as you turn the pages.


ES6 modules support lands in browsers: is it time to rethink bundling?

Modules, as in, this kind of syntax right in JavaScript:

import { myCounter, someOtherThing } from 'utilities';

Which we'd normally use Webpack to bundle, but now is supported in Safari Technology Preview, Firefox Nightly (flag), and Edge.

It's designed to support progressive enhancement, as you can safely link to a bundled version and a non-bundled version without having browsers download both.

Stefan Judis shows:

<!-- in case ES6 modules are supported -->
<script src="app/index.js" type="module"></script>
<!-- in case ES6 modules aren't supported -->
<script src="dist/bundle.js" defer nomodule></script>

Not bundling means simpler build processes, which is great, but forgoing all the other cool stuff a tool like Webpack can do, like "tree shaking". Also, all those imports are individual HTTP requests, which may not be as big of a deal in HTTP/2, but still isn't great:

Khan Academy discovered the same thing a while ago when experimenting with HTTP/2. The idea of shipping smaller files is great to guarantee perfect cache hit ratios, but at the end, it's always a tradeoff and it's depending on several factors. For a large code base splitting the code into several chunks (a vendor and an app bundle) makes sense, but shipping thousands of tiny files that can't be compressed properly is not the right approach.

Preprocessing build steps are likely here to stay. Native tech can learn from them, but we might as well leverage what both are good at.


The overflow-anchor property enables us to opt out of Scroll Anchoring, which is a browser feature intended to allow content to load above the user's current DOM location without changing the user's location once that content has been fully loaded.


Dealing with Spacing in Compiled Markdown Articles

Good thinking and exploration by Sebastian Eberlein. I'm a firm believer that you're doing yourself a favor if you blog in Markdown, because it gives you clean HTML output that isn't littered with classes very likely won't last forever.

Instead, why not use some clever CSS selectors (using stuff like adjacent sibling combinators) to get the spacing and styling you want without changing the markup. CSS is a lot easier to change than HTML. HTML within content, that is. HTML as part of templates is just as easy to change.