Tags: pen

298

sparkline

Thursday, September 9th, 2021

Meet the Self-Hosters, Taking Back the Internet One Server at a Time

Taking the indie web to the next level—self-hosting on your own hardware.

Tired of Big Tech monopolies, a community of hobbyists is taking their digital lives off the cloud and onto DIY hardware that they control.

Monday, September 6th, 2021

Solarpunk Is Not About Pretty Aesthetics. It’s About the End of Capitalism

Hannah Steinkopf-Frank:

At its core, and despite its appropriation, Solarpunk imagines a radically different societal and economic structure.

Tuesday, August 10th, 2021

Resigning from the AMP advisory committee

Inspired by Terence Eden’s example, I applied for membership of the AMP advisory committee last year. To my surprise, my application was successful.

I’ve spent the time since then participating in good faith, but I can’t do that any longer. Here’s what I wrote in my resignation email:

Hi all,

As mentioned at the end of the last call, I’m stepping down from the AMP advisory committee.

I can’t in good faith continue to advise on the AMP project for the OpenJS Foundation when it has become clear to me that AMP remains a Google product, with only a subset of pieces that could even be considered open source.

If I were to remain on the advisory committee, my feelings of resentment about this situation would inevitably affect my behaviour. So it’s best for everyone if I step away now instead of descending into outright sabotage. It’s not you, it’s me.

I’d like to thank the OpenJS Foundation for allowing me to participate. It’s been an honour to watch Tobie and Jory in action.

I wish everyone well and I hope that the advisory committee can successfully guide the AMP project towards a happy place where it can live out its final days in peace.

I don’t have a replacement candidate to nominate but I’ll ask around amongst other independent sceptical folks to see if there’s any interest.

All the best,

Jeremy

I wrote about the fundamental problem with Google AMP when I joined the advisory committee:

This is an interesting time for AMP …whatever AMP is.

See, that’s been a problem with Google AMP from the start. There are multiple defintions of what AMP is.

There’s the collection of web components. If that were all AMP is, it would be a very straightforward project, similar to other collections of web components (like Polymer). But then there’s the concept of validation. The validation comes from a set of rules, defined by Google. And there’s the AMP cache, or more accurately, Google hosting.

Only one piece of that trinity—the collection of web components—is eligible for the label of being open source, and even that’s a stretch considering that most of the contributions come from full-time Google employees. The other two parts are firmly under Google’s control.

I was hoping it was a marketing problem. We spent a lot of time on the advisory committee trying to figure out ways of making it clearer what AMP actually is. But it was a losing battle. The phrase “the AMP project” is used to cover up the deeply interwingled nature of its constituent parts. Bits of it are open source, but most of it is proprietary. The OpenJS Foundation doesn’t seem like a good home for a mostly-proprietary project.

Whenever a representative from Google showed up at an advisory committee meeting, it was clear that they viewed AMP as a Google product. I never got the impression that they planned to hand over control of the project to the OpenJS Foundation. Instead, they wanted to hear what people thought of their project. I’m not comfortable doing that kind of unpaid labour for a large profitable organisation.

Even worse, Google representatives reminded us that AMP was being used as a foundational technology for other Google products: stories, email, ads, and even some weird payment thing in native Android apps. That’s extremely worrying.

While I was serving on the AMP advisory committee, a coalition of attorneys general filed a suit against Google for anti-competitive conduct:

Google designed AMP so that users loading AMP pages would make direct communication with Google servers, rather than publishers’ servers. This enabled Google’s access to publishers’ inside and non-public user data.

We were immediately told that we could not discuss an ongoing court case in the AMP advisory committee. That’s fair enough. But will it go both ways? Or will lawyers acting on Google’s behalf be allowed to point to the AMP advisory committee and say, “But AMP is an open source project! Look, it even resides under the banner of the OpenJS Foundation.”

If there’s even a chance of the AMP advisory committee being used as a Potempkin village, I want no part of it.

But even as I’m noping out of any involvement with Google AMP, my parting words have to be about how impressed I am with the OpenJS Foundation. Jory and Tobie have been nothing less than magnificent in their diplomacy, cat-herding, schedule-wrangling, timekeeping, and other organisational superpowers that I’m crap at.

I sincerely hope that Google isn’t taking advantage of the OpenJS Foundation’s kind-hearted trust.

Monday, July 19th, 2021

Solarpunk

My talk on sci-fi and me for Beyond Tellerrand’s Stay Curious event was deliberately designed to be broad and expansive. This was in contrast to Steph’s talk which was deliberately narrow and focused on one topic. Specifically, it was all about solarpunk.

I first heard of solarpunk from Justin Pickard back in 2014 at an event I was hosting. He described it as:

individuals and communities harnessing the power of the photovoltaic solar panel to achieve energy-independence.

The sci-fi subgenre of solarpunk, then, is about these communities. The subgenre sets up to be deliberately positive, even utopian, in contrast to most sci-fi.

Most genres ending with the -punk suffix are about aesthetics. You know the way that cyberpunk is laptops, leather and sunglasses, and steampunk is zeppelins and top hats with goggles. Solarpunk is supposedly free of any such “look.” That said, all the examples I’ve seen seem to converge on the motto of “put a tree on it.” If a depiction of the future looks lush, verdant, fecund and green, chances are it’s solarpunk.

At least, it might be solarpunk. It would have to pass the criteria laid down by the gatekeepers. Solarpunk is manifesto-driven sci-fi. I’m not sure how I feel about that. It’s one thing to apply a category to a piece of writing after it’s been written, but it’s another to start with an agenda-driven category and proceed from there. And as with any kind of classification system, the edges are bound to be fuzzy, leading to endless debates about what’s in and what’s out (see also: UX, UI, service design, content design, product design, front-end development, and most ironically of all, information architecture).

When I met up with Steph to discuss our talk topics and she described the various schools of thought that reside under the umbrella of solarpunk, it reminded me of my college days. You wouldn’t have just one Marxist student group, there’d be multiple Marxist student groups each with their own pillars of identity (Leninist, Trotskyist, anarcho-syndicalist, and so on). From the outside they all looked the same, but woe betide you if you mixed them up. It was exactly the kind of situation that was lampooned in Monty Python’s Life of Brian with its People’s Front of Judea and Judean People’s Front. Steph confirmed that those kind of rifts also exist in solarpunk. It’s just like that bit in Gulliver’s Travels where nations go to war over the correct way to crack an egg.

But there’s general agreement about what broadly constitutes solarpunk. It’s a form of cli-fi (climate fiction) but with an upbeat spin: positive but plausible stories of the future that might feature communities, rewilding, gardening, farming, energy independence, or decentralisation. Centralised authority—in the form of governments and corporations—is not to be trusted.

That’s all well and good but it reminds of another community. Libertarian preppers. Heck, even some of the solarpunk examples feature seasteading (but with more trees).

Politically, preppers and solarpunks couldn’t be further apart. Practically, they seem more similar than either of them would be comfortable with.

Both communities distrust centralisation. For the libertarians, this manifests in a hatred of taxation. For solarpunks, it’s all about getting off the electricity grid. But both want to start their own separate self-sustaining communities.

Independence. Decentralisation. Self-sufficiency.

There’s a fine line between Atlas Shrugged and The Whole Earth Catalog.

Friday, June 25th, 2021

Robin Rendle ・ The web is too damn complex

The modern web wouldn’t be possible without big ol’ JavaScript frameworks, but—but—much of the web today is held back because of these frameworks. There’s a lot of folks out there that think that every website must use their framework of choice even when it’s not necessary. And although those frameworks solve a great number of problems, they introduce a substantial number of trade-offs; performance issues you have to deal with, complex build processes you have to learn, and endless dependency updates that can introduce bugs.

Friday, June 4th, 2021

Two articles on SPA or SPA-like sites vs alternatives — Piper Haywood

On framework-dependency and longevity:

So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. Any tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.

Wednesday, April 21st, 2021

PlymouthPress – A Letterpress Image Font

An experimental image font made using the University of Plymouth’s unique letterpress workshop.

Grungy!

The font is intended for display purposes only, and not is suitable for body text.

Friday, March 12th, 2021

Vendor by default - macwright.com

I never knew that the way I add other people’s code to my projects is called “vendoring.” I thought it was just copying and pasting.

Saturday, March 6th, 2021

Why Generation X will save the web - Hi, I’m Heather Burns

Today’s young tech policy professionals are are, quite rightfully, responding to the only internet in the only world they have ever known. The awful one. The one where the internet was and is a handful of billion-pound companies. The one where the internet has only ever been petrol on a fire. The one where the internet has been essential infrastructure like water and heat, not a thing you had to request and master. The closed internet made for them. Not the open internet I got to make.

So if you think that the biggest threat to encryption is elderly politicians who still need their secretaries to print out emails for them, it’s time you found yourself in a meeting with someone under the age of 30 who is going to war against encryption because he has never needed encryption in his life.

Friday, February 12th, 2021

Why The IndieWeb? (Webbed Briefs)

Heydon keeps on producing more caustically funny videos that are made for me. After the last one about progressive enhancement, this one is about the indie web.

This is the story of the birth of the web, its loss of innocence, its decline, and what we can do to make it a bit less gross.

Monday, February 1st, 2021

Sunday, January 3rd, 2021

My stack will outlive yours

My stack requires no maintenance, has perfect Lighthouse scores, will never have any security vulnerability, is based on open standards, is portable, has an instant dev loop, has no build step and… will outlive any other stack.

Wednesday, December 16th, 2020

npm ruin dev

This was originally published on CSS Tricks in December 2020 as part of a year-end round-up of responses to the question “What is one thing you learned about building websites this year?”

In 2020, I rediscovered the enjoyment of building a website with plain ol’ HTML, CSS, and JavaScript—no transpilin’, no compilin’, no build tools other than my hands on the keyboard.

Seeing as my personal brand could be summed up “so late to the game that the stadium has been demolished”, I decided to start a podcast in 2020. It’s the podcast of my agency, Clearleft, and it has been given the soaringly imaginative title of The Clearleft Podcast. I’m really pleased with how the first season turned out. I’m also really pleased with the website I put together for it.

The website isn’t very big, though it will grow with time. I had a think about what the build process for the site should be and after literally seconds of debate, I settled on a build process of none. Zero. Nada.

This turned out to be enormously liberating. It felt very hands-on to write the actual HTML and CSS that will be delivered to end users, without any mediation. I felt like I was getting my hands into the soil of the site.

CSS has evolved so much in recent years—with features like calc() and custom properties—that you don’t have to use preprocessors like Sass. And vanilla JavaScript is powerful, fully-featured, and works across browsers without any compiling.

Don’t get me wrong—I totally understand why complicated pipelines are necessary for complicated websites. If you’re part of a large team, you probably need to have processes in place so that everyone can contribute to the codebase in a consistent way. The more complex that codebase is, the more technology you need to help you automate your work and catch errors before they go live.

But that set-up isn’t appropriate for every website. And all those tools and processes that are supposed to save time sometimes end up wasting time further down the road. Ever had to revisit a project after, say, six or twelve months? Maybe you just want to make one little change to the CSS. But you can’t because a dependency is broken. So you try to update it. But it relies on a different version of Node. Before you know it, you’re Bryan Cranston changing a light bulb. You should be tweaking one line of CSS but instead you’re battling entropy.

Whenever I’m tackling a problem in front-end development, I like to apply the principle of least power: choose the least powerful language suitable for a given purpose. A classic example would be using a simple HTML button element instead of trying to recreate all the native functionality of a button using a div with lashings of ARIA and JavaScript. This year, I realized that this same principle applies to build tools too.

Instead of reaching for all-singing all-dancing toolchain by default, I’m going to start with a boring baseline. If and when that becomes too painful or unwieldy, then I’ll throw in a task manager. But every time I add a dependency, I’ll be limiting the lifespan of the project.

My new year’s resolution for 2021 will be to go on a diet. No more weighty node_modules folders; just crispy and delicious HTML, CSS, and JavaScript.

Saturday, December 12th, 2020

Make it Personal | CSS-Tricks

On your personal website, you own your work. You decide what and when to publish. You decide when to delete things. You are in control. Your work, your rules, your freedom.

Thursday, December 10th, 2020

Grow the IndieWeb with Webmentions | Amber Wilson

Amber describes how she implemented webmentions on her (static) site. More important, she describes why!

Thursday, November 19th, 2020

Standardizing `select` And Beyond: The Past, Present And Future Of Native HTML Form Controls — Smashing Magazine

While a handful of form controls can be easily styled by CSS, like the button element, most form controls fall into a bucket of either requiring hacky CSS or are still unable to be styled at all by CSS.

Despite form controls no longer taking a style or technical dependency on the operating system and using modern rendering technology from the browser, developers are still unable to style some of the most used form control elements such as select. The root of this problem lies in the way the specification was originally written for form controls back in 1995.

Stephanie goes back in time to tell the history of form controls on the web, and how that history has led to our current frustrations:

The current state of working with controls on the modern web is that countless developer hours are being lost to rewriting controls from scratch, as custom elements due to a lack of flexibility in customizability and extensibility of native form controls. This is a massive gap in the web platform and has been for years. Finally, something is being done about it.

Amen!

Wednesday, November 18th, 2020

The Long Now Foundation: “Nadia Eghbal Talk”

This is a great talk by Nadia Eghbal on software, open source, maintenance, and of course, long-term thinking.

Monday, November 9th, 2020

Bookshop

Back at the start of the (first) lockdown, I wrote about using my website as an outlet:

While you’re stuck inside, your website is not just a place you can go to, it’s a place you can control, a place you can maintain, a place you can tidy up, a place you can expand. Most of all, it’s a place you can lose yourself in, even if it’s just for a little while.

Last week was eventful and stressful. For everyone. I found myself once again taking refuge in my website, tinkering with its inner workings in the way that someone else would potter about in their shed or take to their garage to strip down the engine of some automotive device.

Colly drew my attention to Bookshop.org, newly launched in the UK. It’s an umbrella website for independent bookshops to sell through. It’s also got an affiliate scheme, much like Amazon. I set up a Bookshop page for myself.

I’ve been tracking the books I’m reading for the past three years here on my own website. I set about reproducing that list on Bookshop.

It was exactly the kind of not-exactly-mindless but definitely-not-challenging task that was perfect for the state of my brain last week. Search for a book; find the ISBN number; paste that number into a form. It’s the kind of task that a real programmer would immediately set about automating but one that I embraced as a kind of menial task to keep me occupied.

I wasn’t able to get a one-to-one match between the list on my site and my reading list on Bookshop. Some titles aren’t available in the online catalogue. For example, the book I’m reading right now—A Paradise Built in Hell by Rebecca Solnit—is nowhere to be found, which seems like an odd omission.

But most of the books I’ve read are there on Bookshop.org, complete with pretty book covers. Then I decided to reverse the process of my menial task. I took all of the ISBN numbers from Bookshop and add them as machine tags to my reading notes here on my own website. Book cover images on Bookshop have predictable URLs that use the ISBN number (well, technically the EAN number, or ISBN-13, but let’s not go down a 927 rabbit hole here). So now I’m using that metadata to pull in images from Bookshop.org to illustrate my reading notes here on adactio.com.

I’m linking to the corresponding book on Bookshop.org using this URL structure:

https://uk.bookshop.org/a/{{ affiliate code }}/{{ ISBN number }}

I realised that I could also link to the corresponding entry on Open Library using this URL structure:

https://openlibrary.org/isbn/{{ ISBN number }}

Here, for example, is my note for The Raven Tower by Ann Leckie. That entry has a tag:

book:ean=9780356506999

With that information I can illustrate my note with this image:

https://images-eu.bookshop.org/product-images/images/9780356506999.jpg

I’m linking off to this URL on Bookshop.org:

https://uk.bookshop.org/a/980/9780356506999

And this URL on Open Library:

https://openlibrary.org/isbn/9780356506999

The end result is that my reading list now has more links and pretty pictures.

Oh, I also set up a couple of shorter lists on Bookshop.org:

The books listed in those are drawn from my end of the year round-ups when I try to pick one favourite non-fiction book and one favourite work of fiction (almost always speculative fiction). The books in those two lists are the ones that get two hearty thumbs up from me. If you click through to buy one of them, the price might not be as cheap as on Amazon, but you’ll be supporting an independent bookshop.

Sunday, November 1st, 2020

Copying is the way design works || Matthew Ström: designer & developer

A people’s history of copying, from art to software.

Designers copy. We steal like great artists. But when we see a copy of our work, we’re livid.

Wednesday, September 16th, 2020

A polyfill for button type=”share”

After writing about a declarative Web Share API here yesterday I thought I’d better share the idea (see what I did there?).

I opened an issue on the Github repo for the spec.

(I hope that’s the right place for this proposal. I know that in the past ideas were kicked around on the Discourse site for Web platform Incubator Community Group but I can’t stand Discourse. It literally requires JavaScript to render anything to the screen even though the entire content is text. If it turns out that that is the place I should’ve posted, I guess I’ll hold my nose and do it using the most over-engineered reinvention of the browser I’ve ever seen. But I believe that the plan is for WICG to migrate proposals to Github anyway.)

I also realised that, as the JavaScript Web Share API already exists, I can use it to polyfill my suggestion for:

<button type="share">

The polyfill also demonstrates how feature detection could work. Here’s the code.

This polyfill takes an Inception approach to feature detection. There are three nested levels:

  1. This browser supports button type="share". Great! Don’t do anything. Otherwise proceed to level two.
  2. This browser supports the JavaScript Web Share API. Use that API to share the current page URL and title. Otherwise proceed to level three.
  3. Use a mailto: link to prefill an email with the page title as the subject and the URL in the body. Ya basic!

The idea is that, as long as you include the 20 lines of polyfill code, you could start using button type="share" in your pages today.

I’ve made a test page on Codepen. I’m just using plain text in the button but you could use a nice image or SVG or combination. You can use the Codepen test page to observe two of the three possible behaviours browsers could exhibit:

  1. A browser supports button type="share". Currently that’s none because I literally made this shit up yesterday.
  2. A browser supports the JavaScript Web Share API. This is Safari on Mac, Edge on Windows, Safari on iOS, and Chrome, Samsung Internet, and Firefox on Android.
  3. A browser supports neither button type="share" nor the existing JavaScript Web Share API. This is Firefox and Chrome on desktop (and Edge if you’re on a Mac).

See the Pen Polyfill for button type=”share" by Jeremy Keith (@adactio) on CodePen.

The polyfill doesn’t support Internet Explorer 11 or lower because it uses the DOM closest() method. Feel free to fork and rewrite if you need to support old IE.