A neat little tool when you need a reminder about what elements can go in other elements.
Saturday, October 23rd, 2021
Saturday, October 2nd, 2021
A very comprehensive collection of standalone little tools for web design and development—tools that do one thing.
Tuesday, August 10th, 2021
Resigning from the AMP advisory committee
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:
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,
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.
Wednesday, May 19th, 2021
This is a great (free!) course on learning CSS from the basics up. Nicely-pitched explanations with plenty of examples.
Thursday, April 1st, 2021
A very comprehensive directory of accessibility resources.
Monday, March 22nd, 2021
Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.
Saturday, January 16th, 2021
An excellent collection of advice and examples for making websites responsive and accessibile (responsive + accessible = responsible).
Wednesday, November 18th, 2020
Tuesday, November 10th, 2020
Sunday, November 1st, 2020
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.
Thursday, October 1st, 2020
Did you know there’s an
imagesrcset attribute you can put on
link rel="preload" as="image" (along with an
I didn’t. (Until Amber pointed this out.)
Wednesday, September 16th, 2020
This was an absolute delight to read! Usually when you read security-related write-ups, the fun comes from the cleverness of the techniques …but this involved nothing cleverer than dev tools. In this instance, the fun is in the telling of the tale.
Thursday, August 20th, 2020
Friday, June 26th, 2020
A useful resource for CSS grid. It’s basically the spec annoted with interactive examples.
Saturday, May 23rd, 2020
Scott is brilliant, therefore by the transitive property, his course on web performance must also be brilliant.
Wednesday, May 13th, 2020
…for old CSS problems.
Friday, May 1st, 2020
A collection of articles and talks about HTML, CSS, and JS, grouped by elements, attributes, properties, selectors, methods, and expressions.
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.
Kimberly was spelunking down the original source code, when she came across this line in the
#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.
Tuesday, March 10th, 2020
A really nice open-source font-previewing tool for the Mac.
Friday, March 6th, 2020
Everything you ever wanted to know about variable fonts, gathered together into one excellent website.