When Dan wrote this a week ago, I thought it sounded very far-fetched. Now it sounds almost inevitable.
Monday, November 7th, 2022
Monday, July 25th, 2022
- a button,
- a dropdown, and
- a datepicker.
In each case you could use native HTML elements:
Or you could use
In the case of a dropdown, it’s less clear-cut. Personally, I’d use a
select element. While it’s currently impossible to style the open state of a
select element, you can style the closed state with relative ease. That’s good enough for me.
Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling
select elements. That’s one of the reasons why the work being done by the Open UI group is so important.
But there’s one more component: a button.
Again, you could use the native
button element, or you could use a
div or a
Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native
button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.
I’ve been trying to understand the mindset of a developer who wouldn’t use a native
button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.
I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.
When I hear that there’s a native HTML element—like
select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).
But I now understand that someone else might hear that there’s a native HTML element—like
select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.
I get it. I don’t agree. But I get it.
But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.
Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using
Sunday, May 1st, 2022
Robin adds a long-zoom perspective on my recent post:
Saturday, April 30th, 2022
Thursday, April 28th, 2022
I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:
I would love it if someone could explain why they avoid native browser features but use third-party code.
Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!
Charles Harries takes on my question in his post Libraries over browser features:
Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.
So again, it’s browser incompatibilities that made libraries attractive.
Jim Nielsen responds with the same message in his post Trusting Browsers:
We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.
For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.
Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.
I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.
This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.
I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.
Jim is glass-half-full kind of guy:
I’m optimistic that trust in browser-native features and APIs is being restored.
He also points to a very sensible mindset when it comes to third-party libraries and frameworks:
In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).
Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).
I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.
I like Jim’s proposed design princple:
Where available, default to browser-native features over third party code, abstractions, or idioms.
(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)
Wednesday, April 27th, 2022
I’ve noticed a strange mindset amongst front-end/full-stack developers. At least it seems strange to me. But maybe I’m the one with the strange mindset and everyone else knows something I don’t.
It’s to do with trust and suspicion.
I’ve made no secret of the fact that I’m suspicious of third-party code and dependencies in general. Every dependency you add to a project is one more potential single point of failure. You have to trust that the strangers who wrote that code knew what they were doing. I’m still somewhat flabbergasted that developers regularly add dependencies—via npm or yarn or whatever—that then pull in even more dependencies, all while assuming good faith and competence on the part of every person involved.
It’s a touching expression of faith in your fellow humans, but I’m not keen on the idea of faith-based development.
And yet, the mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.
When I write and talk about using service workers, I often come across scepticism from developers about writing the service worker code. “Is there a library I can use?” they ask. “Well, yes” I reply, “but then you’ve got to understand the library, and the time it takes you to do that could be spent understanding the native code.” So even though a library might not offer any new functionality—just a different idion—many developers are more likely to trust the third-party library than they are to trust the underlying code that the third-party library is abstracting!
Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.
On the one hand, I get it. Bootstrap and React are very popular. That popularity speaks volumes. If lots of people use a technology, it must be a safe bet, right?
But if we’re talking about popularity, every single browser today ships with support for features like grid, custom properties, service workers and web components. No third-party framework can even come close to that install base.
And the fact that these technologies have shipped in stable browsers means they’re vetted. They’ve been through a rigourous testing phase. They’ve effectively got a seal of approval from each individual browser maker. To me, that seems like a much bigger signal of trustworthiness than the popularity of a third-party library or framework.
So I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.
Is it because of the job market? When recruiters are looking for developers, their laundry list is usually third-party technologies: React, Vue, Bootstrap, etc. It’s rare to find a job ad that lists native browser technologies: flexbox, grid, service workers, web components.
I would love it if someone could explain why they avoid native browser features but use third-party code.
Until then, I shall remain perplexed.
Tuesday, January 11th, 2022
Occasionally, I wonder whether I’ve got it all wrong. Is my age, my technical unsophistication, or my fond remembrance of an internet unencumbered by commerce blinding me to the opportunities that crypto offers me? But then I read something terrible and I recant my doubts, meditate for a while and get on with my life.
Monday, January 10th, 2022
Blockchain technologies have somehow managed to land in the worst of both worlds—decentralized but not really, immutable but not really.
A great analysis of the system of smoke and mirrors that constitutes so-called web3:
Instead of being at the mercy of the “big tech” companies like Amazon and Google that monopolize the traditional way of doing things on the web, you are now at the mercy of a few other tech companies that are rapidly monopolizing the blockchain way of doing things.
Saturday, January 8th, 2022
A balanced, even-handed look at actually using so-called web3 technology. It turns out that even if you leave the ethical and environmental concerns aside, the technological underpinning are, um, troublesome to say the least.
Thursday, January 6th, 2022
A very even-handed and level-headed assessment by Laurie, who has far more patience than me when it comes to this shit.
The term “web3” is a transparent attempt to associate technologies diametrically opposed to the web with its success; an effort to launder the reputation of systems that have most effectively served as vehicles for money laundering, fraud, and the acceleration of ransomware using the good name of a system that I help maintain.
Perhaps this play to appropriate the value of the web is what it smells like: a desperate move by bag-holders to lure in a new tranche of suckers, allowing them to clear speculative positions. Or perhaps it’s honest confusion. Technically speaking, whatever it is, it isn’t the web or any iteration of it.
Wednesday, January 5th, 2022
Web3 is like a combination of pyramid schemes, scientology and Tamagotchi. There’s the fact that ultimately anything you do on blockchains costs you real money and that once you’ve paid that, you’re one of the people who need to get the next cohort of buyers onboard or lose your money. There’s believing that you’re joining a movement that’s in the know, with all kinds of interesting words and sci-fi stuff that normies just don’t understand. And there’s your portfolio, your pretty JPGs, wallets, apps and everything you spent so much time on understanding and maintaining. Good luck avoiding sunk cost fallacy there.
Thursday, December 23rd, 2021
Much of the energy behind crypto arises from the very strong need that some people feel to operate outside of a state, and therefore outside of any sort of democratic communal overview. The idea that Ayn Rand, that Nietzsche-for-Teenagers toxin, should have had her whacky ideas enshrined in a philosophy about money is what is terrifying to me.
Tuesday, December 7th, 2021
We are so excited by the idea of machines that can write, and create art, and compose music, with seemingly little regard for how many wells of creativity sit untapped because many of us spend the best hours of our days toiling away, and even more can barely fulfill basic needs for food, shelter, and water. I can’t help but wonder how rich our lives could be if we focused a little more on creating conditions that enable all humans to exercise their creativity as much as we would like robots to be able to.
The underlying technology of cryptocurrency is based on a world without trust. Its most ardent proponents want to demolish institutions and abolish regulation, reducing the world to a numbers game which they believe they can win. If the wildest fantasies of cryptocurrency enthusiasts were to come true, if all the environmental and technical objections were to fall away, the result would be financial capitalism with all the brakes taken off.
The promotion of cryptocurrencies is at best irresponsible, an advertisement for an unregulated casino. At worst it is an environmental disaster, a predatory pyramid scheme, and a commitment to an ideology of greed and distrust. I believe the only ethical response is to reject it in all its forms.
Tuesday, November 9th, 2021
Forgive me for linking to The Rag, but for completeness’s sake, it would be remiss of me not to point out more coverage of “that” question I asked:
It was to the company’s credit that it chose to take the question posed by Clearleft’s Jeremy Keith, well known in the web standards community and who was briefly on the advisory committee for AMP (Accelerated Mobile Pages), before resigning saying that “it has become clear to me that AMP remains a Google product.” AMP has been in the news of late with a lawsuit alleging Google deliberately throttled ad load times to promote it, and Keith asked: “Given the court proceedings against AMP, why should anyone trust FLOC or any other Google initiatives ostensibly focused on privacy?”
Sunday, November 7th, 2021
An article by Sarah Gooding, prompted by the question I asked at Chrome Dev Summit:
Jeremy Keith’s question referencing the AMP allegations in the recently unredacted antitrust complaint against Google was extremely unlikely to receive an adequate response from the Chrome Leadership team, but the mere act of asking is a public reminder of the trust Google has willfully eroded in pushing AMP on publishers.
Tuesday, August 3rd, 2021
Facebook Container for Firefox
Firefox has a nifty extension—made by Mozilla—called Facebook Container. It does two things.
First of all, it sandboxes any of your activity while you’re on the facebook.com domain. The tab you’re in is isolated from all others.
Secondly, when you visit a site that loads a tracker from Facebook, the extension alerts you to its presence. For example, if a page has a share widget that would post to Facebook, a little fence icon appears over the widget warning you that Facebook will be able to track that activity.
It’s a nifty extension that I’ve been using for quite a while. Except now it’s gone completely haywire. That little fence icon is appearing all over the web wherever there’s a form with an email input. See, for example, the newsletter sign-up form in the footer of the Clearleft site. It’s happening on forms over on The Session too despite the rigourous-bordering-on-paranoid security restrictions in place there.
Hovering over the fence icon displays this text:
If you use your real email address here, Facebook may be able to track you.
That is, of course, false. It’s also really damaging. One of the worst things that you can do in the security space is to cry wolf. If a concerned user is told that they can ignore that warning, you’re lessening the impact of all warnings, even serious legitimate ones.
Sometimes false positives are an acceptable price to pay for overall increased security, but in this case, the rate of false positives can only decrease trust.
I tried to find out how to submit a bug report about this but I couldn’t work it out (and I certainly don’t want to file a bug report in a review) so I’m writing this in the hopes that somebody at Mozilla sees it.
What’s really worrying is that this might not be considered a bug. The release notes for the version of the extension that came out last week say:
Email fields will now show a prompt, alerting users about how Facebook can track users by their email address.
Like …all email fields? That’s ridiculous!
I thought the issue might’ve been fixed in the latest release that came out yesterday. The release notes say:
This release addresses fixes a issue from our last release – the email field prompt now only displays on sites where Facebook resources have been blocked.
But the behaviour is unfortunately still there, even on sites like The Session or Clearleft that wouldn’t touch Facebook resources with a barge pole. The fence icon continues to pop up all over the web.
I hope this gets sorted soon. I like the Facebook Container extension and I’d like to be able to recommend it to other people. Right now I’d recommed the opposite—don’t install this extension while it’s behaving so overzealously. If the current behaviour continues, I’ll be uninstalling this extension myself.
Update: It looks like a fix is being rolled out. Fingers crossed!
Monday, October 12th, 2020
Clearleft turned fifteen this year. We didn’t make a big deal of it. What with The Situation and all, it didn’t seem fitting to be self-congratulatory. Still, any agency that can survive for a decade and a half deserves some recognition.
I didn’t make too much of a big deal of it back then. I think I was afraid I’d jinx it. I still kind of feel that way. Fifteen years of success? Beginner’s luck.
Despite being one of the three founders, I was never an owner of Clearleft. I let Andy and Rich take the risks and rewards on their shoulders while I take a salary, the same as any other employee.
But now, after fifteen years, I am also an owner of Clearleft.
Clearleft is now owned by an employee ownership trust. This isn’t like owning shares in a company—a common Silicon Valley honeypot. This is literally owning the company. Shares are transferable—this isn’t. As long as I’m an employee at Clearleft, I’m a part owner.
On a day-to-day basis, none of this makes much difference. Everyone continues to do great work, the same as before. The difference is in what happens to any profit produced as a result of that work. The owners decide what to do with that profit. The owners are us.
In most companies you’ve got a tension between a board representing the stakeholders and a union representing the workers. In the case of an employee ownership trust, the interests are one and the same. The stakeholders are the workers.
It’ll be fascinating to see how this plays out. Check back again in fifteen years.
Saturday, March 9th, 2019
Handing back control
An Event Apart Seattle was most excellent. This year, the AEA team are trying something different and making each event three days long. That’s a lot of mindblowing content!
What always fascinates me at events like these is the way that some themes seem to emerge, without any prior collusion between the speakers. This time, I felt that there was a strong thread of giving control directly to users:
Margot described this in terms of vulnerability for the brand, but the kind of vulnerability that leads to trust.
Sarah talked about it in terms of respect—respecting the privacy of users, and respecting the way that they want to use your services. Call it compassion, call it empathy, or call it just good business sense, but providing these kind of controls in an interface is an excellent long-term strategy.
In Val’s animation talk, she did a deep dive into
prefers-reduced-motion, a media query that deliberately hands control back to the user.
Even in a CSS-heavy talk like Jen’s, she took the time to explain why starting with meaningful markup is so important—it’s because you can’t control how the user will access your content. They may use tools like reader modes, or Pocket, or have web pages read aloud to them. The user has the final say, and rightly so.
In his CSS talk, Eric reminded us that a style sheet is a list of strong suggestions, not instructions.
Beth’s talk was probably the most explicit on the theme of returning control to users. She drew on examples from beyond the world of the web—from architecture, urban planning, and more—to show that the most successful systems are not imposed from the top down, but involve everyone, especially those most marginalised.
And even in my own talk on service workers, I raved about the design pattern of allowing users to save pages offline to read later. Instead of trying to guess what the user wants, give them the means to take control.
I was really encouraged to see this theme emerge. Mind you, when I look at the reality of most web products, it’s easy to get discouraged. Far from providing their users with controls over their own content, Instagram won’t even let their customers have a chronological feed. And Matt recently wrote about how both Twitter and Quora are heading further and further away from giving control to their users in his piece called Optimizing for outrage.
Still, I came away from An Event Apart Seattle with a renewed determination to do my part in giving people more control over the products and services we design and develop.
I spent the first two days of the conference trying to liveblog as much as I could. I find it really focuses my attention, although it’s also quite knackering. I didn’t do too badly; I managed to write cover eleven of the talks (out of the conference’s total of seventeen):
- Slow Design for an Anxious World by Jeffrey Zeldman
- Designing for Trust in an Uncertain World by Margot Bloomstein
- Designing for Personalities by Sarah Parmenter
- Generation Style by Eric Meyer
- Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
- Designing Intrinsic Layouts by Jen Simmons
- How to Think Like a Front-End Developer by Chris Coyier
- From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
- Move Fast and Don’t Break Things by Scott Jehl
- Mobile Planet by Luke Wroblewski
- Unsolved Problems by Beth Dean