Although there’s a lot of heated discussion around diversity, I feel many of us ignore the elephant in the web development diversity room. We tend to forget about users of older or non-standard devices and browsers, instead focusing on people with modern browsers, which nowadays means the latest versions of Chrome and Safari.

This is nothing new — see “works only in IE” ten years ago, or “works only in Chrome” right now — but as long as we’re addressing other diversity issues in web development we should address this one as well.

Ignoring users of older browsers springs from the same causes as ignoring women, or non-whites, or any other disadvantaged group. Average web developer does not know any non-whites, so he ignores them. Average web developer doesn’t know any people with older devices, so he ignores them. Not ignoring them would be more work, and we’re on a tight deadline with a tight budget, the boss didn’t say we have to pay attention to them, etc. etc. The usual excuses.

Besides, let’s be realistic, shall we? The next billion, most of whom are on cheap Android devices without the latest and greatest browsing software, are mostly poor — and mostly black or brown anyway — so they don’t fit in our business model. We only cater to whites — not because we’re racist (of COURSE we aren’t!) but because of ... well, the Others are not our market.

So far, this diversity problem plays out the same as the others. However, there’s one important difference: while other diversity problems in web development could conceivably be solved by non-web developers (by managers, for instance), the old-devices problem can only be solved by us because we’re the only ones who know how to do it.

Besides, taking care of all users is our job. So let’s do our job, shall we?

And let’s start at the start. Let’s admit we have a prejudice against users of old or non-standard devices and browsers, just as we have a prejudice against women and non-whites, and for exactly the same reasons.

The following is an unedited extract from my [forthcoming book](http://book.webtypography.net/).

In October 2016, version 1.8 of OpenType was [released](https://medium.com/@tiro/12ba6cd2369), and with it an extensive new technology: OpenType Font Variations. More commonly known as variable fonts, the technology enables a single font file to behave like multiple fonts. This is done by defining variations within the font, which are interpolated along one or more axes. Two of these axes might be width and weight, but the type designer can define many others too.

The preceding image shows a variable font rendered in 36 different styles, all from one file. If you were to pick four styles and serve them as normal fonts, a variable font file capable of providing the same styles would be significantly smaller than the four separate files, with the added speed advantage of requiring just one call to the server.

The illustration varies width and weight. Those two axes alone mean that, according to the OpenType Font Variations specification, theoretically 1000×1000 (one million) variations are possible within the one file with no extra data. A third axis could increase the possibilities to one billion.

At the time of writing the technology is in its infancy, but it potentially opens up tremendous opportunities for new kinds of responsive typography. The file size savings and fine precision means that many small adjustments could be made to the rendered font, potentially responding dynamically to the reader’s device and environment, as well to the text.

Within the design space created by the axes of variation in a font, the type designer can define specific positions as named instances. Each named instance could appear to users of design software as if it were a separate font, for example ‘regular’, ‘light condensed’ or ‘extra bold extended’.

In the OpenType specification, five common axes of variation have been pre-defined as four-character tags: weight `wght`, width `wdth`, italic `ital`, slant `slnt` and optical size `opsz`. These font variations can be enabled by the `font-weight`, `font-stretch`, and `font-style` properties. [CSS4](https://drafts.csswg.org/css-fonts-4/) adds new values for the properties to work with font variations:

• `font-weight` takes any integer from 1–999 (not limited to multiples of 100 as in CSS3).
• `font-stretch` takes a percentage number in a range where 100% is normal, 50% is ultra-condensed and 200% is ultra-expanded.
• `font-style` takes an oblique angle value from `oblique -90deg` to `oblique 90deg`.
• `font-optical-sizing` is a new property taking a value of `auto` or `none` which turns on optical sizing if it’s available as an axis in the variable font.

Font designers can also define custom axes with their own four-character tags. This enables designers to vary almost any imaginable aspect of a typeface, such as contrast, x-height, serif-shape, grunginess, and even parts of an individual glyphs, such as the length of the tail on a Q. Using a syntax similar to `font-feature-settings`, custom axes as well as the predefined ones, are available through the low-level `font-variation-settings` property. For example, this would render text with a variation that is very wide, light weight and optically sized for 48pt:

h2 {
font-variation-settings: “wdth” 600, “wght” 200, “opsz” 48;
}

Visit Laurence Penney’s [Axis-Praxis.org](http://Axis-Praxis.org) to play with variations and design instances of some variable fonts (requires [Safari Technology Preview](https://developer.apple.com/safari/technology-preview/)).

As with regular OpenType fonts, variable fonts can be used as web fonts as-is, or preferably wrapped up as a WOFF. If you want to use to a variable font as a web font, in your `@font-face` rule you should set the `format` to `woff-variations` or `ttf-variations`. If you wish to provide regular font fallbacks for browsers which don’t support variable fonts, you can use multiple font-face rules where necessary, repeating the variable font each time.

@font-face {
font-family: 'Nicefont';
src: url('nicefont_var.woff2') format('woff-variations');
src: url('nicefont_regular.woff2') format('woff2');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'Nicefont';
src: url('nicefont_var.woff2') format('woff-variations');
src: url('nicefont_black.woff2') format('woff2');
font-weight: 800;
font-style: normal;
}

At the time of writing there is support for `font-variation-settings` in Webkit Nightlies and [Safari Technology Preview](https://developer.apple.com/safari/technology-preview/), but neither support `font-weight` or other such properties with variable fonts. Additionally the web font `format` needs to be `woff` or `ttf`. Variable fonts were jointly developed by Adobe, Apple, Google and Microsoft. This means support in new versions of browsers should arrive across the board as soon as the precise implementations and CSS specifications are agreed. Current [estimates](http://responsivewebdesign.com/podcast/variable-fonts) have variable fonts being a viable option on the web by early 2018.

Read or add comments

It’s great to be delusional. It allows you to try super ambitious stuff that no normal person would touch with a barge pole.

But that on its own is not enough. You also need to the other stuff, the skill set, the ability to actually execute.

Talent. Brains. Ambition. Charm. Business savvy.

All the rock star stuff we admire the most in other people, counts for little without a solid, long-term work ethic.

You know, the boring stuff…

The post delusional is not a skill set appeared first on Gapingvoid.

During the recording of the web platform’s “Are Web Components ready?” podcast one of the comments stuck with me:

With web components we’re trying to bring ES6-aera technology into an ES5 world. That makes no sense.

There is a lot of interesting logic in that one. Right now, we’re in a bad place with the web. There is a big discussion what we should consider the “modern web” and how to innovate it. And the two sides of the it are at loggerheads:

• Purists of the web frown upon JavaScript dependency and expect no new feature to break the web. Instead it should build upon what we already have. These are developers wearing battle scars of the browser wars. I count myself amongst them for long time now – I just like things that work and got disappointed by browsers once too often.
• The more “pragmatic engineering” crowd sees the web as a software platform that needs evolving like every other one does. And one that is falling woefully behind. Native platforms on mobile for example do not worry about breaking existing experiences. It is OK to request the user to have a certain version of an OS to run. The same – in their view – should be OK on the web.

Both are correct, and both are wrong. And I am sick of it. Instead of trying to fix the situation, we bicker over ideas and methodologies. We christen new development approaches with grandiose names. Then we argue for days on end what these mean. We talk about “real world use” without looking at numbers not skewed in favor of certain solutions. And while all that happens, we’re losing the web.

I’m not buying the tales of woe that all users prefer native to the web now. That’s a short-sighted view backed up by sales numbers in affluent countries and our own circles.There is a massive audience out there with no smartphones.

I also don’t buy the argument that native is a fad and the web will prevail in the long run. We need to get better with the web and its technologies. And we won’t do that by pretending what we did twenty years ago is still great.

There is an argument for leaving old browsers without new functionality. The funny thing is that this is also what I, as a person who doesn’t want to break the web, believe in.

Should we stop pushing the web forward?

A few weeks ago Peter-Paul Koch kicked the hornets’ nest when proposing a one year innovation hiatus of browsers in his “Stop pushing the web forward” post.

He pointed out that there is a problem.

• We have many standards and proposed solutions to the shortcomings of the web. But all are still far away from implementation across browsers.
• He also pointed out a problem with adoption speed. None of the proposed standards managed to get any traction within a year.

Web Components is the biggest culprit there. This also was one of the findings of the Web Components/Modules panel of EdgeConf this year. It seems that without libraries, Web Components are more or less unusable right now. This is partly because there is a lot of consensus yet to be found as to what they should achieve.

It is hard to write a standard. It is hard to get consensus and buy-in from various browser vendors and their partners. And it is hard to make sure we don’t put a standard in our browsers that turns out to be less than optimal once we have it in there. We had enough of those already.

This is where JavaScript comes in. It has always been the means of adding upcoming functionality to the browsers of now and the ones of the past.

JavaScript is powerful

The great thing about JavaScript is, that it spans all the layers of web development. You can create both HTML and CSS with it (using the DOM and CSSOM or writing out styles inline). You can do so after you tested for capabilities of the browser and – to a degree – the end user. You can even create images, sounds, 3D environments, well – you name it.

JavaScript also successfully moved away from the client side and powers servers, fat-client applications and APIs. In these environments you control JavaScript engine. Originally this was only V8, but now also Chakra is available as an alternative. This sort of control is great for developers who know what they are doing. It also gives us the wrong impression that we could have the same on the web.

The bad thing about JavaScript is that this gives a lot of power to people too busy to use it in a thorough fashion.

• User agent sniffing is rampant and woefully wrong.
• A lot of solutions test for touch support and then assume a smartphone, leaving touch-screen devices with the wrong interface.
• Many users of libraries trust them to fix all issues without verifying.
• A lot of user agent sniffing checks for a name of a browser instead of the buggy version, thus making fixing those bugs a futile exercise for this product – it will always stay patched.

There is no doubt, that the use case for JavaScript has changed in the last few years and that – for good or worse – our solutions rely on it. This is OK, if we ensure that only those who can get this functionality. We can not make developer convenience result in empty pages.

Empty pages are empty pages

XHTML was killed off because it was too unforgiving. Any encoding problem in our files would have meant our users got an XML error message instead of our products. That’s why we replaced it with HTML5, which uses a much more forgiving parser.

The same problem applies with JavaScript. It is not fault tolerant. Any error that can happen is fatal to the execution of the program. To make matters worse, even the delivery of JavaScript to our end users is riddled with obstacles, bear traps and moats to cross. If you can’t rely on the delivery of your helper library you can easily end up with an empty page instead of the 60fps goodness we work so hard to deliver.

It is time to fix JavaScript

And we need to change JavaScript. It is virtually possible to do everything in JavaScript and you learn about new things and quirks of the language almost every week. Whilst this is fun, it also holds us back. Our success as developers used to be defined by knowing how browsers mess up. Now that we kind of fixed that our job should not be to know the quirks and oddities of a language – it should be to build maintainable, scalable and performant software products.

Our current attempts to improve JavaScript as a language has a few issues. Older browsers getting an EcmaScript 6 script taking advantage of all the good syntax changes see them as a syntax error and break.

That brings us to an impasse: we want to innovate and extend the language, but we have to deal with the issue of legacy environments. Our current solution is the one we always took in case of confusion: we abstract.

Abstraction languages and transpiling

On first glance, this seems like a great idea: we let computers do what they do best, crunching numbers and converting one thing into another. Using a language like TypeScript or a transpiler like Traceur or Babel we gain a lot of benefits:

• End users don’t get broken experiences. The transpiler converts ES6 to understandable ES5. They may get a lot more code than they would in an ES6 capable environment, but that’d mean they’d need to change their environment – something people only do for very good reasons. Our products are not reason enough – sorry.
• Developers can use the terser, cleaner syntax of ES6 right now without worrying about breakage in older browsers
• We can embrace the more structured approach of classes in JavaScript instead of having to get into the “JavaScript mindset”. This means more developers can build for the web.
• We control the conversion step – turning ES6 into code that runs across browsers happens in the transpiler; a resource we control. That way we can convert only what is necessary to legacy code and use supported features when they happen.

Alas, the last part doesn’t happen right now. Transpiling as it stands now is slow to work in the browser which is why we do it on the server side. There we can not do any capability testing, which means we convert all the ES6 features to the lowest common denominator. That way any of the native support for ES6 in browsers never gets any traction.

In essence, we added ES6 to browsers for internal use only. Developers write ES6, but always run ES5 in the browser.

This also means that we have the problem for developers that we don’t write the code that runs in the browser, but one level up from that. That makes debugging harder and we need to use sourcemaps to connect errors with the line in our source code that caused it. We might also run into the issue where the code generated by the transpiler is faulty and we can’t do anything about it.

The beauty of the web was its immediate connection between creation and consumption. You wrote the code that ran in the browser. Developer tools in the last years became amazingly sophisticated giving us insights into how our code behaves. With abstractions, we forfeit these beautiful options.

We already missed the boat once when DOM became a thing

Let’s turn back the clock a bit. Those of us who’ve been around when the DOM wasn’t standardised and DHTML was a thing remember clearly how terrible that was.

We rejoiced when we got DOM support and we had one API to write against. We even coined a term called “DOM scripting” to make a clear distinction between the DHTML of old and the “modern” code we write now. All of this was based on the simple principle of progressive enhancement using capability testing.

All you did was wrapping your code in a statement that checked if the “modern” DOM was supported:

if (document.getElementById) {
  // … your code
}

And then you used all the crazy new stuff that made our life so much easier: createElement, appendChild, getElementsByTagName. These were great (until we found innerHTML).

Browsers that didn’t make the cut, didn’t get any JavaScript. This has a few benefits:

• You move forward, without breaking things – browsers that can not run your code, don’t get it. There is a beautiful simplicity in that.
• You have a clear cut-off point – you know what you support and what you don’t. This cuts down immensely on testing time of your solutions. As you know an IE6 never gets any JavaScript, there is no need to test on it – if you enhanced progressively.
• You have a reason to write sensible HTML and plain CSS – you know this is your safety blanket that gets delivered to all browsers. And in most cases, having HTML that works without scripting is a great baseline for your more sophisticated solution that happens once JS does its magic.

It was a great idea, and it got some traction. But then it got replaced by something else: abstraction libraries like jQuery, prototype, mootools, YUI and hundreds of others, most of which forgotten. But sadly enough not removed from old implementations.

It’s a kind of magic: here come the libraries

Abstraction libraries promised (and in some cases still promise) us a lot of things:

• They sanitised across browsers – under the hood, they do a lot of bug workarounds and forking for different browsers to make things work. This is a lot of effort which resulted in browser bugs never getting fixed.
• They allow to write less and achieve more – which sounds like a very pragmatic way of working. It also means we create more code than is needed. It doesn’t look much to use a few plugins and write 10 lines of abstraction code to create a product. Under the hood, we made ourselves dependent on a lot of magic. We also have a responsibility to keep our helper libraries up-to-date and test in the browsers we now promise to support. We doubled our responsibilities for the sake of not having to be responsible for working around browser issues.
• They protected us from having to learn about the DOM – we didn’t need to type in those long names or the convoluted way to add a new element using insertBefore().

There is no doubt that the DOM in hindsight is a terrible API and its implementations are buggy. But there is also no doubt that we allowed it to stay that way by abstracting our issues away. Libraries bred a whole generation of developers who see the browser as something to convert code into, not something to write code for. It also slowed down the demands of fixing problems in browsers.

Nowadays, abstraction libraries of the DOM scripting days are landfill of the web. Many don’t get updated and quite a few new features can not be implemented in a straight-forward fashion in browsers as they would break web products relying on library abstractions with the same names.

Cutting the mustard

The idea of DOM scripting was to test for capabilities and use them instead of simulating them with convoluted replacements that work in older browsers. It removed a lot of the hackiness of the web and unspeakable things like writing out content with document.write() inside inline script elements.

The problem with capability testing is that it can backfire:

• Support for one feature doesn’t mean others are supported – a lot of times browsers support them in waves, depending on demand and complexity.
• Browsers lie to you – often there was rudimentary support for an object, but browsers lacked the methods it should have come with
• You never know what you’ll want to support – and testing for each and every feature is tedious

This is why we started defining other cut-off points. The developers in the BBC called this “cutting the mustard” and – after looking at support charts of browsers and testing the real support – defined the following test as a good one to weed out old browsers:

if('querySelector' in document
     && 'localStorage' in window
     && 'addEventListener' in window) {
     // bootstrap the javascript application
     }

Jake Archibald defined an even more drastic one for mobile products, filtering out both old versions of Internet Explorer and older WebKit on mobiles:

if (!('visibilityState' in document)) return;

You can then layer on more functionality in tests:

if ('visibilityState' in document) { 
  // Modern browser. Let's load JavaScript
  if ('serviceWorker' in navigator) {
    // Let's add offline support
    navigator.serviceWorker.register('sw.js', {
      scope: './'
    });
  }
}

This is great. So here is my proposal. Features of ES6 can be detected – even those that are completely new syntax. Kyle Simpson’s featuretests.io is a pretty comprehensive library full of tests that does exactly that.

How about we make support for a few ES6 features our new “cutting the mustard”?

This results in some good opportunities:

• We will get real use of ES6 features in browsers – this allows us to improve its performance and find browser issues to fix.
• We get promises – which not only make async work much easier, but also are the baseline of almost every new API the web really needs (see ServiceWorkers, for example)
• We are one step closer to real modules in Javascript
• We will get fetch – a much saner way to load dynamic content than Ajax
• We have in-built templating

The biggest win: iOS and Safari

Safari has lately become the problem child of the browser space. Many an innovation agreed by other players will fail to get traction if iOS is not on board. It is the stock browser of iOS and no other browser engine is allowed. No matter how much service and interface layer you see in Chrome or Opera for iOS, under the hood ticks the same engine.

And iOS is the golden child of the mobile world: it has the most beautiful devices, the most affluent users not shy about spending money and it doesn’t suffer from the fragmentation issues Android has. Android has larger numbers, but much less revenue per person.

That means what doesn’t run in Safari iOS is not ready to reach the audience the people who pay us deem the most important. Safari is the one and only browser engine on iOS, its roadmap is much foggier than the one of other browsers and its spokespeople are fashionably absent at every public discussion.

This sounds familiar and brings back terrible memories of an Internet Explorer monoculture as explained by Nolan Lawson in Safari is the new IE.

This is not going away any time soon. And many of the standards proposals implemented in Chrome and Firefox are red boxes on caniuse.com in the mobile Safari column.

However, the ES6 support of Mobile Safari is much better.

Can ES6 features make a sensible cut off point?

This is a bold idea. But I think a great one.

• We have a chance with ES6 to innovate the web much more quickly than we could with other standard proposals that need browser maker agreement.
• Legacy browsers will never get new APIs, and patching for them with polyfills and libraries results in a mess – better to let them have HTML and CSS
• This goes hand-in-hand with the extensible web manifesto
• Using ES6 features in production is the only way to make them perform well in browsers. You can’t optimise what isn’t used.

What do you think? Let’s take a look at support, and define a new “cutting the mustard”, extending this idea from API support to also include syntax changes.

Photo Credit: frankieleon