Tags: standards

661

sparkline

Tuesday, May 26th, 2020

as days pass by — Browsers are not rendering engines

You see, diversity of rendering engines isn’t actually in itself the point. What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good?

Stuart responds to a post from Brian that was riffing off a post of mine from a while back. I like this kind of social network.

Wednesday, May 13th, 2020

Sass and clamp

CSS got some pretty nifty features recently. There’s the min() and max() functions. If you use them for, say, width you can use one rule where previously you would’ve needed to use two (a width declaration followed by either min-width or max-width). But they can also be applied to font-size! That’s very nifty—we’ve never had min-font-size or max-font-size properties.

There’s also the clamp() function. That allows you to set a minimum size, a default size, and a maximum size. Again, it can be used for lengths, like width, or for font-size.

Over on thesession.org, I’ve had some media queries in place for a while now that would increase the font-size for larger screens. It’s nothing crucial, just a nice-to-have so that on wide screens, the font is bumped up accordingly. I realised I could replace all those media queries with one clamp() statement, thanks to the vw (viewport width) unit:

font-size: clamp(1rem, 1.333vw, 1.5rem);

By default, the font-size is 1.333vw (1.333% of the viewport width), but it will never get smaller than 1rem and it will never get larger than 1.5rem.

That works, but there’s a bit of an issue with using raw vw units like that. If someone is on a wide screen and they try to adjust the font size, nothing will happen. The viewport width doesn’t change when you bump the font size up or down.

The solution is to mix in some kind of unit that does respond to the font size being bumped up or down (like, say, the rem unit). Handily, clamp() allows you to combine units, just like calc(). So I can do this:

font-size: clamp(1rem, 0.5rem + 0.666vw, 1.5rem);

The result is much the same as my previous rule, but now—thanks to the presence of that 0.5rem value—the font size responds to being adjusted by the user.

You could use a full 1rem in that default value:

font-size: clamp(1rem, 1rem + 0.333vw, 1.5rem);

…but if you do that, the minimum size (1rem) will never be reached—the default value will always be larger. So in effect it’s no different than saying:

font-size: min(1.rem + 0.333vw, 1.5rem);

I mentioned this to Chris just the other day.

Anyway, I got the result I wanted. I wanted the font size to stay at the browser default size (usually 16 pixels) until the screen was larger than around 1200 pixels. From there, the font size gets gradually bigger, until it hits one and a half times the browser default (which would be 24 pixels if the default size started at 16). I decided to apply it to the :root element (which is html) using percentages:

:root {
  font-size: clamp(100%, 50% + 0.666vw, 150%);
}

(My thinking goes like this: if we take a screen width of 1200 pixels, then 1vw would be 12 pixels: 1200 divided by 100. So for a font size of 16 pixels, that would be 1.333vw. But because I’m combining it with half of the default font size—50% of 16 pixels = 8 pixels—I need to cut the vw value in half as well: 50% of 1.333vw = 0.666vw.)

So I’ve got the CSS rule I want. I dropped it in to the top of my file and…

I got an error.

There was nothing wrong with my CSS. The problem was that I was dropping it into a Sass file (.scss).

Perhaps I am showing my age. Do people even use Sass any more? I hear that post-processors usurped Sass’s dominance (although no-one’s ever been able to explain to me why they’re different to pre-processers like Sass; they both process something you’ve written into something else). Or maybe everyone’s just writing their CSS in JS now. I hear that’s a thing.

The Session is a looooong-term project so I’m very hesitant to use any technology that won’t stand the test of time. When I added Sass into the mix, back in—I think—2012 or so, I wasn’t sure whether it was the right thing to do, from a long-term perspective. But it did offer some useful functionality so I went ahead and used it.

Now, eight years later, it was having a hard time dealing with the new clamp() function. Specifically, it didn’t like the values being calculated through the addition of multiple units. I think it was clashing with Sass’s in-built ability to add units together.

I started to ask myself whether I should still be using Sass. I looked at which features I was using…

Variables. Well, now we’ve got CSS custom properties, which are even more powerful than Sass variables because they can be updated in real time. Sass variables are like const. CSS custom properties are like let.

Mixins. These can be very useful, but now there’s a lot that you can do just in CSS with calc(). The built-in darken() and lighten() mixins are handy though when it comes to colours.

Nesting. I’ve never been a fan. I know it can make the source files look tidier but I find it can sometimes obfuscate what you’re final selectors are going to look like. So this wasn’t something I was using much any way.

Multiple files. Ah! This is the thing I would miss most. Having separate .scss files for separate interface elements is very handy!

But globbing a bunch of separate .scss files into one .css file isn’t really a Sass task. That’s what build tools are for. In fact, that’s what I was already doing with my JavaScript files; I write them as individual .js files that then get concatenated into one .js file using Grunt.

(Yes, this project uses Grunt. I told you I was showing my age. But, you know what? It works. Though seeing as I’m mostly using it for concatenation, I could probably replace it with a makefile. If I’m going to use old technology, I might as well go all the way.)

I swapped out Sass variables for CSS custom properties, mixins for calc(), and removed what little nesting I was doing. Then I stripped the Sass parts out of my Grunt file and replaced them with some concatenation and minification tasks. All of this makes no difference to the actual website, but it means I’ve got one less dependency …and I can use clamp()!

Remember a little while back when I was making a dark mode for my site? I made this observation:

Let’s just take a moment here to pause and reflect on the fact that we can now use CSS to create all sorts of effects that previously required a graphic design tool like Photoshop.

It feels like something similar has happened with tools like Sass. Sass was the hare. CSS is the tortoise. Sass blazed the trail, but now native CSS can achieve much the same result.

It’s like when we used to need something like jQuery to do DOM Scripting succinctly using CSS selectors. Then we got things like querySelector() in JavaScript so we no longer needed the trailblazer.

I’ve said it before and I’ll say it again, the goal of any good library should be to get so successful as to make itself redundant. That is, the ideas and functionality provided by the tool are so useful and widely adopted that the native technologies—HTML, CSS, and JavaScript—take their cue from those tools.

You could argue that this is what happened with Flash. It certainly happened with jQuery and Sass. I’m pretty sure we’ll see the same cycle play out with frameworks like React.

Monday, May 11th, 2020

Creating an Accessible Range Slider with CSS | a11y with Lindsey

If you want an accessible slider component, the trick isn’t to use a whole load of JavaScript. The trick is to use the native input type="range" and then figure out the CSS you need (which, alas, involves lots of vendor prefixes).

Thursday, April 30th, 2020

Interactive Elements: A Strange Game

Just today I was discussing with Trys and Cassie why developers tend to create bespoke JavaScript-driven components rather than using the elements that browsers give us for free. It all comes down to the ability to style the user interface.

Here, Brian proposes a kind of minimum viable web component that handles logic like keyboard control and accessibility, but leaves the styling practically untouched. Check out his panel-set demo of a tabbed interface.

I really, really like the way that it wraps existing content. If the web component fails for any reason, the content is still available. So the web component is a progressive enhancement:

An experimental custom element that wraps plain-old HTML (view the source) and decorates function, keyboard handling, accessibility information.

Friday, April 10th, 2020

Web Share API test

Remember a while back I wrote about some odd behaviour with the Web Share API in Safari on iOS?

When the share() method is triggered, iOS provides multiple ways of sharing: Messages, Airdrop, email, and so on. But the simplest option is the one labelled “copy”, which copies to the clipboard.

Here’s the thing: if you’ve provided a text parameter to the share() method then that’s what’s going to get copied to the clipboard—not the URL.

That’s a shame. Personally, I think the url field should take precedence.

Tess filed a bug soon after, which was very gratifying to see.

Now Phil has put together a test case:

  1. Share URL, title, and text
  2. Share URL and title
  3. Share URL and text

Very handy! The results (using the “copy” to clipboard action) are somewhat like rock, paper, scissors:

  • URL beats title,
  • text beats URL,
  • nothing beats text.

So it’s more like rock, paper, high explosives.

Wednesday, March 11th, 2020

A curl in every port

A few years back, Zach Bloom wrote The History of the URL: Path, Fragment, Query, and Auth. He recently expanded on it and republished it on the Cloudflare blog as The History of the URL. It’s well worth the time to read the whole thing. It’s packed full of fascinating tidbits.

In the section on ports, Zach says:

The timeline of Gopher and HTTP can be evidenced by their default port numbers. Gopher is 70, HTTP 80. The HTTP port was assigned (likely by Jon Postel at the IANA) at the request of Tim Berners-Lee sometime between 1990 and 1992.

Ooh, I can give you an exact date! It was January 24th, 1992. I know this because of the hack week in CERN last year to recreate the first ever web browser.

Kimberly was spelunking down the original source code, when she came across this line in the HTUtils.h file:

#define TCP_PORT 80 /* Allocated to http by Jon Postel/ISI 24-Jan-92 */

We showed this to Jean-François Groff, who worked on the original web technologies like libwww, the forerunner to libcurl. He remembers that day. It felt like they had “made it”, receiving the official blessing of Jon Postel (in the same RFC, incidentally, that gave port 70 to Gopher).

Then he told us something interesting about the next line of code:

#define OLD_TCP_PORT 2784 /* Try the old one if no answer on 80 */

Port 2784? That seems like an odd choice. Most of us would choose something easy to remember.

Well, it turns out that 2784 is easy to remember if you’re Tim Berners-Lee.

Those were the last four digits of his parents’ phone number.

The History of the URL

This is a wonderful deep dive into all the parts of a URL:

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

There’s a lot of great DNS stuff about the host part:

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

Tuesday, March 3rd, 2020

HTML: The Inaccessible Parts - daverupert.com

Well, this is a grim collection from Dave:

There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.

It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”

Monday, February 24th, 2020

Let’s Define CSS 4 · Issue #4770 · w3c/csswg-drafts

Jen kicked off a fascinating thread here:

It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.

The level is discourse is impressively smart and civil.

Personally, I don’t (yet) have an opinion on this either way, but I’ll be watching it unfold with keen interest.

Saturday, February 15th, 2020

Things I’ve been wrong about, things I’ve been right about | Nolan Lawson

  • Wrong: web workers will take over the world
  • Wrong: Safari is the new IE
  • Right: developer experience is trumping user experience
  • Right: I’m better off without a Twitter account
  • Right: the cost of small modules
  • Mixed: progressive enhancement isn’t dead, but it smells funny

Maybe I should do one of these.

Monday, February 3rd, 2020

Old CSS, new CSS / fuzzy notepad

I absolutely love this in-depth history of the web, written in a snappy, snarky tone.

In the beginning, there was no CSS.

This was very bad.

Even if you—like me—lived through all this stuff, I guarantee there’ll still be something in here you didn’t know.

Monday, January 27th, 2020

Diary of an Engine Diversity Absolutist – Dan’s Blog

Dan responds to an extremely worrying sentiment from Alex:

The sentiment about “engine diversity” points to a growing mindset among (primarily) Google employees that are involved with the Chromium project that puts an emphasis on getting new features into Chromium as a much higher priority than working with other implementations.

Needless to say, I agree with this:

Proponents of a “move fast and break things” approach to the web tend to defend their approach as defending the web from the dominance of native applications. I absolutely think that situation would be worse right now if it weren’t for the pressure for wide review that multiple implementations has put on the web.

The web’s key differentiator is that it is a part of the commons and that it is multi-stakeholder in nature.

Thursday, January 23rd, 2020

Web standards, dictionaries, and design systems

Years ago, the world of web standards was split. Two groups—the W3C and the WHATWG—were working on the next iteration of HTML. They had different ideas about the nature of standardisation.

Broadly speaking, the W3C followed a specification-first approach. Figure out what should be implemented first and foremost. From this perspective, specs can be seen as blueprints for browsers to work from.

The WHATWG, by contrast, were implementation led. The way they saw it, there was no point specifying something if browsers weren’t going to implement it. Instead, specs are there to document existing behaviour in browsers.

I’m over-generalising somewhat in my descriptions there, but the point is that there was an ideological difference of opinion around what standards bodies should do.

This always reminded me of a similar ideological conflict when it comes to language usage.

Language prescriptivists attempt to define rules about what’s right or right or wrong in a language. Rules like “never end a sentence with a preposition.” Prescriptivists are generally fighting a losing battle and spend most of their time bemoaning the decline of their language because people aren’t following the rules.

Language descriptivists work the exact opposite way. They see their job as documenting existing language usage instead of defining it. Lexicographers—like Merriam-Webster or the Oxford English Dictionary—receive complaints from angry prescriptivists when dictionaries document usage like “literally” meaning “figuratively”.

Dictionaries are descriptive, not prescriptive.

I’ve seen the prescriptive/descriptive divide somewhere else too. I’ve seen it in the world of design systems.

Jordan Moore talks about intentional and emergent design systems:

There appears to be two competing approaches in designing design systems.

An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.

An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).

An intentional design system is prescriptive. An emergent design system is descriptive.

I think we can learn from the worlds of web standards and dictionaries here. A prescriptive approach might give you a beautiful design system, but if it doesn’t reflect the actual product, it’s fiction. A descriptive approach might give a design system with imperfections and annoying flaws, but at least it will be accurate.

I think it’s more important for a design system to be accurate than beautiful.

As Matthew Ström says, you should start with the design system you already have:

Instead of drawing a whole new set of components, start with the components you already have in production. Document them meticulously. Create a single source of truth for design, warts and all.

Monday, January 20th, 2020

Unity

It’s official. Microsoft’s Edge browser is running on the Blink rendering engine and it’s available now.

Just over a year ago, I wrote about my feelings on this decision:

I’m sure the decision makes sound business sense for Microsoft, but it’s not good for the health of the web.

The importance of browser engine diversity is beautifully illustrated (literally) in Rachel’s The Ecological Impact of Browser Diversity.

But I was chatting to Amber the other day, and I mentioned how I can see the theoretical justification for Microsoft’s decision …even if I don’t quite buy it myself.

Picture, if you will, something I’ll call the bar of unity. It’s a measurement of how much collaboration is happening between browser makers.

In the early days of the web, the bar of unity was very low indeed. The two main browser vendors—Microsoft and Netscape—not only weren’t collaborating, they were actively splintering the languages of the web. One of them would invent a new HTML element, and the other would invent a completely different element to do the same thing (remember abbr and acronym). One of them would come up with one model for interacting with a document through JavaScript, and the other would come up with a completely different model to the same thing (remember document.all and document.layers).

There wasn’t enough collaboration. Our collective anger at this situation led directly to the creation of The Web Standards Project.

Eventually, those companies did start collaborating on standards at the W3C. The bar of unity was raised.

This has been the situation for most of the web’s history. Different browser makers agreed on standards, but went their own separate ways on implementation. That’s where they drew the line.

Now that line is being redrawn. The bar of unity is being raised. Now, a number of separate browser makers—Google, Samsung, Microsoft—not only collaborate on standards but also on implementation, sharing a codebase.

The bar of unity isn’t right at the top. Browsers can still differentiate in their user interfaces. Edge, for example, can—and does—offer very sensible defaults for blocking trackers. That’s much harder for Chrome to do, given that Google are amongst the worst offenders.

So these browsers are still competing, but the competition is no longer happening at the level of the rendering engine.

I can see how this looks like a positive development. In fact, from this point of view, Mozilla are getting in the way of progress by having a separate codebase (yes, this is a genuinely-held opinion by some people).

On the face of it, more unity sounds good. It sounds like more collaboration. More cooperation.

But then I think of situations where complete unity isn’t necessarily a good thing. Take political systems, for example. If you have hundreds of different political parties, that’s not ideal. But if you only have one political party, that’s very bad indeed!

There’s a sweet spot somewhere in between where there’s a base of level of agreement and cooperation, but there’s also plenty of room for disagreement and opposition. Right now, the browser landscape is just about still in that sweet spot. It’s like a two-party system where one party has a crushing majority. Checks and balances exist, but they’re in peril.

Firefox is one of the last remaining representatives offering an alternative. The least we can do is support it.

Thursday, January 16th, 2020

Intent to Deprecate and Freeze: The User-Agent string - Google Groups

Excellent news! All the major browsers have agreed to freeze their user-agent strings, effectively making them a relic (which they kinda always were).

For many (most?) uses of UA sniffing today, a better tool for the job would be to use feature detection.

Friday, January 10th, 2020

Install prompt

There’s an interesting thread on Github about the tongue-twistingly named beforeinstallpromt JavaScript event.

Let me back up…

Progressive web apps. You know what they are, right? They’re websites that have taken their vitamins. Specifically, they’re responsive websites that:

  1. are served over HTTPS,
  2. have a web app manifest, and
  3. have a service worker handling the offline scenario.

The web app manifest—a JSON file of metadata—is particularly useful for describing how your site should behave if someone adds it to their home screen. You can specify what icon should be used. You can specify whether the site should launch in a browser or as a standalone app (practically indistinguishable from a native app). You can specify which URL on the site should be used as the starting point when the site is launched from the home screen.

So progressive web apps work just fine when you visit them in a browser, but they really shine when you add them to your home screen. It seems like pretty much everyone is in agreement that adding a progressive web app to your home screen shouldn’t be an onerous task. But how does the browser let the user know that it might be a good idea to “install” the web site they’re looking at?

The Samsung Internet browser does ambient badging—a + symbol shows up to indicate that a website can be installed. This is a great approach!

I hope that Chrome on Android will also use ambient badging at some point. To start with though, Chrome notified users that a site was installable by popping up a notification at the bottom of the screen. I think these might be called “toasts”.

Getting the “add to home screen” prompt for https://huffduffer.com/ on Android Chrome. And there’s the “add to home screen” prompt for https://html5forwebdesigners.com/ HTTPS + manifest.json + Service Worker = “Add to Home Screen” prompt. Add to home screen.

Needless to say, the toast notification wasn’t very effective. That’s because we web designers and developers have spent years teaching people to immediately dismiss those notifications without even reading them. Accept our cookies! Sign up to our newsletter! Install our native app! Just about anything that’s user-hostile gets put in a notification (either a toast or an overlay) and shoved straight in the user’s face before they’ve even had time to start reading the content they came for in the first place. Users will then either:

  1. turn around and leave, or
  2. use muscle memory reach for that X in the corner of the notification.

A tiny fraction of users might actually click on the call to action, possibly by mistake.

Chrome didn’t abandon the toast notification for progressive web apps, but it did change when they would appear. Rather than the browser deciding when to show the prompt—usually when the user has just arrived on the site—a new JavaScript event called beforeinstallprompt can be used.

It’s a bit weird though. You have to “capture” the event that fires when the prompt would have normally been shown, subdue it, hold on to that event, and then re-release it when you think it should be shown (like when the user has completed a transaction, for example, and having your site on the home screen would genuinely be useful). That’s a lot of hoops. Here’s the code I use on The Session to only show the installation prompt to users who are logged in.

The end result is that the user is still shown a toast notification, but at least this time it’s the site owner who has decided when it will be shown. The Chrome team call this notification “the mini-info bar”, and Pete acknowledges that it’s not ideal:

The mini-infobar is an interim experience for Chrome on Android as we work towards creating a consistent experience across all platforms that includes an install button into the omnibox.

I think “an install button in the omnibox” means ambient badging in the browser interface, which would be great!

Anyway, back to that thread on Github. Basically, neither Apple nor Mozilla are going to implement the beforeinstallprompt event (well, technically Mozilla have implemented it but they’re not going to ship it). That’s fair enough. It’s an interim solution that’s not ideal for all reasons I’ve already covered.

But there’s a lot of pushback. Even if the details of beforeinstallprompt are troublesome, surely there should be some way for site owners to let users know that can—or should—install a progressive web app? As a site owner, I have a lot of sympathy for that viewpoint. But I also understand the security and usability issues that can arise from bad actors abusing this mechanism.

Still, I have to hand it to Chrome: even if we put the beforeinstallprompt event to one side, the browser still has a mechanism for letting users know that a progressive web app can be installed—the mini info bar. It’s not a great mechanism, but it’s better than nothing. Nothing is precisely what Firefox and Safari currently offer (though Firefox is experimenting with something).

In the case of Safari, not only do they not provide a mechanism for letting the user know that a site can be installed, but since the last iOS update, they’ve buried the “add to home screen” option even deeper in the “sharing sheet” (the list of options that comes up when you press the incomprehensible rectangle-with-arrow-emerging-from-it icon). You now have to scroll below the fold just to find the “add to home screen” option.

So while I totally get the misgivings about beforeinstallprompt, I feel that a constructive alternative wouldn’t go amiss.

And that’s all I have to say about that.

Except… there’s another interesting angle to that Github thread. There’s talk of allowing sites that are launched from the home screen to have access to more features than a site inside a web browser. Usually permissions on the web are explicitly granted or denied on a case-by-case basis: geolocation; notifications; camera access, etc. I think this is the first time I’ve heard of one action—adding to the home screen—being used as a proxy for implicitly granting more access. Very interesting. Although that idea seems to be roundly rejected here:

A key argument for using installation in this manner is that some APIs are simply so powerful that the drive-by web should not be able to ask for them. However, this document takes the position that installation alone as a restriction is undesirable.

Then again:

I understand that Chromium or Google may hold such a position but Apple’s WebKit team may not necessarily agree with such a position.

Thursday, January 9th, 2020

Adding Response Metadata to Cache API Explainer by Aaron Gustafson and Jungkee Song

This is a great proposal that would make the Cache API even more powerful by adding metadata to cached items, like when it was cached, how big it is, and how many times it’s been retrieved.

Tuesday, January 7th, 2020

[css-grid-2] Masonry layout · Issue #4650 · w3c/csswg-drafts

This is an interesting looking proposal for CSS grid to be ever so slightly extended to enable Masonry-style auto placement—something’s that tantalisingly close right now, but still requires some JavaScript to do calculations.

Tuesday, December 31st, 2019

Running Code Over Time – Eric’s Archived Thoughts

We should think of our code, even our designs, as running for decades, and alter our work to match.

Saturday, December 14th, 2019

Building The Web

An interview conducted by Vitaly Friedman ahead of the 2019 View Source conference in Amsterdam.

Do you think, as of today, the Web is in the best shape it will ever be?

Well, to paraphrase Charles Dickens, “It is the best of the times; it is the worst of times,” because, in a sense, things are absolutely great today. Let’s just take it from the point of view of browsers and browser support for standards.

What you can do in a browser today just straight out of the box is amazing compared to the past. There are some little differences between browsers but, honestly, not like it used to be. Back in the day, if you were a Web developer, you spent maybe 50% of your time battling specific browser bugs trying to make one browser work like another browser, all this stuff, trying to make up for lack of standards.

It’s funny. I was listening to panel discussions we did at a conference I think 11 years ago, the AtMedia Conference in London. One of the questions I was asking the panelists was like, “What’s your wish list for CSS or browsers, in general?” They were saying things like, “Oh, if we had multiple background images, everything would be perfect. All my problems would be solved.”

They were all saying things that we have. They were all saying things that we have today, and we’ve got more. We have so much today that you couldn’t even imagine in the past, things like service workers where you can literally control network level stuff, amazing CSS things with Grid now and Flexbox. Amazing, right? One the one hand, yes, things are better than they’ve ever been.

Then, on another hand, not so much because, first of all, in the area of browsers, the fact that making a browser is now so complicated that only very, very, very, very few companies and organizations could do it and we’re kind of down to just two or three browser rendering engines, that’s not very healthy for something like the Web, which has always thrived on diversity. That’s something we’ll see how that plays out, so I’m uncomfortable about that but it remains to be seen.

Then, in terms of things being, in my opinion, worse than they were before, it’s less to do with what we get from browsers and more to do with how we choose to make things on the Web. We seem to have collectively decided to make things really complicated in terms of, I want to put something on the Web that used to be relatively straightforward.

I know there were all sorts of problems with the way we used to do it and maybe it didn’t scale so well, but we seem to have collectively decided that the barrier to entry to putting something on the Web requires loads of technologies, not browser technologies, but technologies that sit on our computers or sit on our servers. It’s great that we’ve got version control, build tools, automatic bundlers, and all this stuff, but the level of complexity is extremely high, it seems to me.

I know I’m slow and maybe that’s the reason I’m just not very good at picking this stuff up, but it seems to be objectively quite complex. That strikes me as strange because, like I was saying, you can do more with less these days in a browser. It’s easier than ever to build something interactive in a browser with quite minimal HTML, a bit of JavaScript, CSS, right? You can do loads with what you get out of the browser. Yet, we’ve decided to almost reinvent everything for ourselves.

Even though the browser will let us do all this really smart stuff, let’s reinvent it in JavaScript for ourselves. Let’s reinvent going from URL to URL. We’ll call it rooting, and we’ll do all that ourselves. We’ll do it all in JavaScript, and that means now we have to manage state, and so we’re keeping track of all this stuff.

It’s weird because it’s a choice to do that stuff. Yet, we’re acting as though it’s the default.

People are constantly saying, “Oh, well, expectations are different now.” I will say that’s true. People’s expectations of the Web are different, but not in the way that people mostly talk about it.

When people use that phrase, “Oh, people’s expectations of the Web are different now,” what they usually mean is, “Oh, people expect more from the Web. People expect the Web to be fast and interactive like native apps and stuff. I think that would be great if that were true, but my observation from talking to people is that people’s expectations of the Web have changed.

People expect the Web to be terrible. I talk to people and they’ve simply given up on the Web. Certainly, on mobile, they just try to avoid going on the Web.

Yes, people’s expectations of the Web have changed but not for the better. They’re associating the Web with bad experiences, with things being slow, with constantly being bombarded with, you know, sign up to my newsletter, accept cookies, dark patterns, all this stuff.

The solution to that is not, well, let’s throw more complicated toolchains, JavaScript libraries, and frameworks at it. The solution is to pull things back. How about if we didn’t have terrible user experiences that bombard people with stuff? How about if we just made websites using the bare minimum technology so that they’re fast and respond quickly?

Yet, weirdly, we’ve gotten into this cycle where people say, “Oh, people’s expectations of the Web are so high now that we must use all this complex technology,” which just ends up making the Web feel, frankly, even worse. From that perspective, things are in a pretty terrible state for the Web. Yet, like I said in terms of what you can do out of the box in a browser, just get a text editor and write some HTML, a bit of CSS, a bit of JavaScript; you can make amazing things straight out of the box that 10, 15 years ago we literally couldn’t have imagined.

What are the most important things for people coming into the industry to understand? Thinking about how to ensure the things they are building will be reliable and maintainable in the future?

I think the first thing to establish is that people learn in different ways. The answer to this question kind of depends on the person. I’ve experienced this myself, talking to students in, say, Codebar and stuff, is that some people really want to know why something is working, first. Give me the fundamentals. Give me almost a bit of theory but build things up from the fundamentals upwards until we’ve got a thing that works.

Other people, they don’t work that way. They say, “I want to build something as quickly as possible.” Okay, let’s start with a framework. Let’s create React App or something, something that gets you something straight away and then work backward from there.

I say, “Okay, but what’s actually going on here? Why does this work? What’s happening under the hood?”

There are two different ways of learning there. Neither is right and neither is wrong. There are just different ways.

I think the important thing is that, at some point, you end up with this kind of layered level of knowledge that you’ve got the fundaments in the grounding and then you can add things on top like a framework at the tippy top of that stack. Whether you start with the framework and work down to the fundamentals or start with the fundamentals and work up to the framework, I don’t think that matters as long as what you end up with is a nice rounded kind of stack of technologies.

Then, I think, what you learn over time, and I feel is something you could be told but you kind of have to just learn it yourself and experience it, is that the stuff further down, the fundamentals will change at a much slower pace and the stuff higher up, the abstractions, the frameworks, the tools, they will change at a faster pace. Once you know that, then it’s okay. Then that feeling of being overwhelmed, like, “Oh, there’s so much to learn,” you can start to filter it and figure out, “Well, where do I want to concentrate? Do I want to learn stuff that I know I will have to swap out in another year, two years, three years, or will I concentrate my time on this lower level fundamental stuff that will last for maybe decades, or do I split it? Do I dedicate some of my time to fundamentals and some of my time to the abstractions?”

I think the key thing is that you go in with your eyes open about the nature of the thing you’re learning. If I’m going to learn about HTML and, to a certain extent, CSS and stuff, then I will know this is knowledge that will last for quite a while. It’s not going to change too quickly. But if I’m learning about a framework, a build tool, or something like that, then I will say, “Okay. It’s fine that I’m learning this,” but I shouldn’t be under any illusions that this is going to be forever and not be surprised when, further down the line, people say, “Oh, you’re still using that framework? We don’t use that anymore. We use this other framework now,” right?

I think that’s the key thing is going in with your eyes open. It’s totally fine to study all the stuff, learn all the stuff, as long as you’re not disappointed, like, “Oh, I invested all my time in that framework and now nobody is using that framework anymore. We’ve all moved on to this other framework.”

There’s a phrase from DevOps where you talk about your servers. They say, treat your servers like cattle, not pets. Don’t get too attached to them.

I feel like that’s the case with a lot of the tools we use. I would consider frameworks and libraries to be tools. They’re tools. You use them to help you work faster, but don’t get too attached to them because they will change whereas, the more fundamental stuff, you can rely on.

Now, when I say fundamental stuff, to a certain extent I’m talking about the technology stuff like HTML. That moves at a slow pace. HTTP and how the Internet works, that’s not going to change very fast.

When I say fundamentals, I think you can go deeper than that even, and you can talk about philosophies, attitudes, and ways of approaching how to build something on the Web that’s completely agnostic to technologies. In other words, it’s like what your mindset is when you approach building something, what your priorities are, what you value. Those kinds of things can last for a very, very long time, longer than any technologies.

For example, over time, on the Web, I’ve come to realize that progressive enhancement, which is completely technology agnostic—it’s just a way of thinking—is a good long-term investment. Even as technologies come and go, this approach of thinking in a sort of layered way and building up from the most supported thing to least supported thing works really well no matter what the technology is that comes along.

When Ajax came along in 2005, I could take the progressive enhancement approach and apply it to Ajax. When responsive design came along in 2010, I could take progressive enhancement and apply it to responsive design. When progressive Web apps come along, whatever it happens to be, I can take this approach, this fundamental approach and apply it to whatever the new technology is. Those things tend to be really long-lasting. Those kinds of approaches, almost strategies I guess, are things that can last a long time.

You should always be questioning them. You should always be saying, “Is this still relevant? Does this still work in this situation? Does it still apply?” Over a long time period, you start to get an answer to that. It’s like, “Yeah, actually, it’s funny. Even over 20 years, this particular strategy works really well,” whereas some other strategy that worked well 15 years ago, it turns out, just doesn’t even apply today because some technology has made it obsolete.

Yeah, fundamental things aren’t necessarily technologies. I think a Web developer is well versed in getting to grips with those fundamental things but, at the same time, I’m not sure if you could learn those first. I’m not sure if you could be like, “Okay, we’re going to learn about these fundamental things without touching a line of code.” You kind of have to learn them for yourself by doing it and learning over time, I think.

Do you think frameworks, for example, will be replaced by the establishment of long-lasting Web components with CSS routines where we can adjust everything? Is this the world we’re moving toward or is it going to stay simple after all?

Yes, absolutely, the things that people are pushing the envelope with, in terms of frameworks today, will become the standards of tomorrow. I think I would put good money on that because I’ve seen it happen. I’ve seen it happen in the past, generally.

It’s usually in JavaScript that we figure something out, we figure out what we want, and we make it work in JavaScript first. If it’s a really powerful idea that solves a common problem, it will find its way further down.

The classic example, early on, I’m talking in the ’90s now, the first pieces of JavaScript were things like doing image rollovers. Now we don’t need JavaScript for that because we use hover in CSS. It’s such a common use case, it moved down into the declarative layer.

The same with form validation. You have to write your own form validation. Now you can just do required in HTML and stuff like that. This pattern plays out over and over again. With responsive images, we figured out what we wanted in JavaScript and then we got it in HTML with pictures.

Yes, I think the goal of any good framework or library should be to make itself redundant. A classic example of this would be jQuery. You don’t need jQuery today because all the stuff that jQuery did for you like using CSS selectors to find DOM nodes, you can do that now in the browser using querySelector, querySelectorAll. But of course, the only reason why querySelector exists is because jQuery proved it was powerful and people wanted it.

I think, absolutely, a lot of the things that people are currently using frameworks and libraries for will become part of the standard, whether that has to do with the idea of a virtual DOM, state management, managing page transitions, giving us control over that. Yes, absolutely, that will find its way.

Now, whether the specific implementations will be these things like Web components, Houdini, and stuff like that, that’s interesting. We’ll see how that plays out. That’s all part of this bigger idea of the extensible Web where, in the past, we would get specific things like, here is the picture element, here is this new JavaScript API or whatever, here is querySelector. Whereas now, we’ve sort of been given, okay, here are the nuts and bolts of how a browser works. You build a solution and then we’ll see what happens. That’s an interesting idea.

I guess the theory is then that, okay, let’s say we get Web components, we get Houdini. Now we all start building our own widgets and we all start building our own CSS functions. The theory is that the ones that are really popular and really goodwill then get standardized and end up in the standards.

I’m not sure if that’s actually going to happen because I wonder what a standards body or browser maker would actually say is, “Oh, well, we don’t need to make it part of the standard because everyone can just use the Web component, everyone can just use this Houdini thing,” right? We’ll see whether that works out.

I wonder if it’ll end up maybe like the situation with jQuery plugins. I mentioned that jQuery was great, it showed this is what people want, and it ended up as a standard. As well as jQuery the library, you also had jQuery plugins, the ecosystem where everybody built a thousand different carousels, a thousand different widgets. There was no quality control and you couldn’t figure out which was the right one to use. I worry that might be where we end up with things like Web components, Houdini, and stuff like that. But it’s an interesting idea, this extensible Web thing.

How will we build? How will the workflow or the tooling change and evolve as we move forward?

Well, that’s up to us. These things are created by people, so that’s something to be aware of. When people come to the Web think, “Oh, what should I learn? What’s the tool? What’s the methodology? How will we be building websites?” It’s almost like, what horse should I be backing here? What’s a safe bet?

You’ve got to step back and realize these things aren’t handed down from heaven as some kind of decision has been made and then passed on to us. We make those decisions. We decide how the Web gets built. There’s no central authority on this stuff. We collectively decide it.

You can choose how the future of Web development is going to look. You could choose what a workflow is going to look like that works for you and works for other people.

The Web is super flexible. You can choose to build in this layered way that I’ve talked about, progressive enhancement, very resilient way of working, but you don’t have to. The Web doesn’t mandate that you work that way. You could choose to build in a way that you just do everything in JavaScript and make JavaScript do the rooting, the DOM, and everything in JavaScript.

It’s a choice. It’s not something that, oh, in the future, we will all do this; in the future, we will all do that. In the future, you will make a choice about how you want to build.

I think, too often, though, when we’re making those decisions of how should I build or what’s the best way to build something on the Web, I worry that sometimes we think about it a bit too much from our perspective. What’s the best way for me to build on the Web? What’s going to make things easiest for me as a developer?

I don’t want to make things hard for us. I don’t want life to be difficult, but I do think our priorities should actually be what’s going to make things better for the user, even if that means more work from us.

If you’re getting paid, if you’re getting a paycheck to make things on the Web—then again, kind of going back to responsibility—it’s not about you now. You have a duty of care to the people who will be using the thing you’re building. Decisions about how to build on the Web shouldn’t just be made according to what you like, what you think is nice for you, what makes your life easy, what saves you typing, but should be more informed by what’s going to be better for users, what’s going to be more resilient, what’s going to leave nobody behind, you know, something that’s available to everyone.

I know I’m talking a lot in abstractions and vagaries, but the talk at View Source will go into a little more detail.

People are often disappointed in the state of the Web today. How do you see the Web evolving over the years? Do you think that privacy and ethics will become a standard?

I think the first thing to establish is that I don’t want to paint too rosy a picture of how things were in the past. There have always been problems. It’s just that we might have different problems today.

I remember the days of literal pop-up windows or pop-under windows, things like that, really annoying things that eventually browsers had to come in and kind of stamp down on that stuff. That’s sort of happening today as well with some of the egregious tracking and surveillance you see Safari and Firefox taking steps to limit that.

In the past, I would have said, “Oh, we need to figure this out. We need to almost self-regulate,” you know, before it’s too late. At this point, I think, “No, it is too late,” and regulation is coming. GDPR is a first step in that and there will be more.

We deserve it. We had our chance to figure this stuff out for ourselves and do the right thing. We blew it, and things are really bad when it comes to surveillance and tracking.

A lot of the business models seem to be predicated on tracking. I’m saying tracking here, not advertising. Advertising isn’t the issue here. It’s specifically tracking.

It’s a bit of a shame that we talk about ad blockers as a software. Most people are not blocking ads. What they’re blocking is tracking. Again, the same way that browsers had to kind of step in and stop popups and pop-under windows, now we see ad blockers, tracking blockers stepping in to solve this.

We get this kind of battle, right? It’s almost like an arms race that’s been going on. I think regulation is going to come in on top of that. Guaranteed it’s going to happen.

You’re right; the fundamental business models in use today are kind of at odds with privacy and surveillance, so they might need to change. Although, I don’t think advertising requires tracking. I know a lot of people talk as though it does. People talk about, “Oh, you can’t have advertising without a tracking link.” You absolutely can. Sponsorship, other kinds of advertising absolutely work.

The other thing is that tracking is not very good. If I’m advertised to with something that absolutely suits my needs then it kind of ceases to be advertising. It just becomes useful, right? That’s not what I experience. What I experience is just really badly targeted things. It’s not even like the tracking works. Yet, people claim tracking is essential.

Anyway, when I say business models need to change, I don’t mean advertising. I think advertising is actually a reasonable business model for some kinds of services. That connection between advertising and tracking, that needs to be severed.

Some people think that’s impossible. They say, “No, it’s just a law of nature that those two things go together.” That’s not true. We choose that. 
The other thing to remember is that we sometimes look around to see how things are today and we can’t imagine it could be any different. We see one dominant search engine and so we think there could only ever be one dominant search engine, but that’s not true. That’s just the way things have turned out. We see a big social network like Facebook and we think, “Oh, there could ever be one big social network.” Again, that’s just the way things have turned out in our situation.

I think the worst thing we can do is assume things are inevitable and it’s inevitable that things end up that way. That’s particularly true when it comes to surveillance and tracking and things that are antiprivacy to say, “Well, that’s just the way it is. It’s inevitable and it couldn’t be any other way.” I think the first step is that we have to have the imagination to think about how things could be different, how things could have turned out differently, and then work towards making that a reality.

Also, this is a huge opportunity. People are clearly fed up with the tracking. They’re fed up with the surveillance. They don’t mind the advertising. There is a separation there. There is an opportunity here to take on these big organizations who literally can’t change their business model.

Someone like Google, the idea of tracking and surveillance is kind of intrinsically linked to their core business model. That gives a huge opportunity. You can see Apple already starting to exploit this opportunity, but other people, too, where you can make privacy and lack of tracking your selling point. It’s a way for a small player to suddenly maybe disrupt the incumbents because the incumbents are so reliant on tracking.

You can’t take on Facebook by trying to be another Facebook, but you can take on Facebook by being what Facebook can’t do. Not what Facebook won’t do, what Facebook literally can’t do. There’s actually a big opportunity there.

Yeah, when we talk about the good old days of keeping track of things, blogs, I kind of share that because I remember the good old days as well. But I’ll say I see a bit of a resurgence as well. Enough people are getting fed up with just posting on silos like Twitter, Facebook, and stuff that I see more and more people launching their own websites again and publishing there. I hope we’ll see more of that.

What are you most excited about on the Web these days?

Yeah, this is an interesting question because it’s happened over and over again over the course of my career, about 20 years now, where I’ll think, like, “Oh, there’s nothing really exciting me,” and then something comes along and I get, ooh, really excited. Almost kind of puttering along when CSS came along, “Oh, this is really interesting.” Then, years later, Ajax, like, “Ah, this is really interesting.”

I think currently service workers are the things that get me excited, get me thinking about, oh, the potential for what the Web could be. The potential for the user experience on the Web is huge. I don’t even think the challenges are technological because it’s pretty straightforward using service workers.

It’s more changing people’s expectations of the Web, the idea that, oh, you should be able to open a browser or hit a bookmark and have something happen even if you don’t have an Internet connection or even if you are on a crappy network that things could still be quite reliable. That’s such a fundamental change and that gets me very, very excited. It’s also, obviously, a huge challenge to change that.

I have to say, over a long enough time period, the things that I start to think about start to be less and less about specific technologies and more and more about just the Web, in general, and the people making the Web.

I certainly have fears for the Web. They aren’t so much around technologies, like, “Oh, will one particular browser make or dominate,” or, “Will one particular framework be the only technology around?” Those things are concerning. It’s more about, “Will the idea of being able to make for the Web start to get reduced down to an elite kind of priesthood of a certain kind of person?” Frankly, the kind of person who looks like me, right? White, male, privileged, European. If we’re the only people who get to make for the Web, that will be terrible.

I think the real potential of the Web and the promise of the Web from the early days was that it’s for anyone. Anybody should be able to not just use the Web and consume it, but anyone should be able to add to it and build for it.

The thing that actually motivates me now is less about a specific technology and more about how can I try and get a more diverse range of people making the Web, making their own careers out of making for the Web rather than it being reduced, reduced, reduced to a certain kind of person. When I’m done with all this, if I look around and all the other people making websites look just like me, then I think we’ll have failed.