
Saloon manicule.
Saloon manicule.
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.
I was very inspired by something Terence Eden wrote on his blog last year. A report from the AMP Advisory Committee Meeting:
I don’t like AMP. I think that Google’s Accelerated Mobile Pages are a bad idea, poorly executed, and almost-certainly anti-competitive.
So, I decided to join the AC (Advisory Committee) for AMP.
Like Terence, I’m not a fan of Google AMP—my initially positive reaction to it soured over time as it became clear that Google were blackmailing publishers by privileging AMP pages in Google Search. But all I ever did was bitch and moan about it on my website. Terence actually did something.
So this year I put myself forward as a candidate for the AMP advisory committee. I have no idea how the election process works (or who does the voting) but thanks to whoever voted for me. I’m now a member of the AMP advisory committee. If you look at that blog post announcing the election results, you’ll see the brief blurb from everyone who was voted in. Most of them are positively bullish on AMP. Mine is not:
Jeremy Keith is a writer and web developer dedicated to an open web. He is concerned that AMP is being unfairly privileged by Google’s search engine instead of competing on its own merits.
The good news is that main beef with AMP is already being dealt with. I wanted exactly what Terence said:
My recommendation is that Google stop requiring that organisations use Google’s proprietary mark-up in order to benefit from Google’s promotion.
That’s happening as of May of this year. Just as well—the AMP advisory committee have absolutely zero influence on Google search. I’m not sure how much influence we have at all really.
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. At the outset, it seemed pretty straightforward. AMP is a format. It has a doctype and rules that you have to meet in order to be “valid” AMP. Part of that ruleset involved eschewing HTML elements like img
and video
in favour of web components like amp-img
and amp-video
.
That messaging changed over time. We were told that AMP is the collection of web components. If that’s the case, then I have no problem at all with AMP. People are free to use the components or not. And if the project produces performant accessible web components, then that’s great!
But right now it’s not at all clear which AMP people are talking about, even in the advisory committee. When we discuss improving AMP, do we mean the individual components or the set of rules that qualify an AMP page being “valid”?
The use-case for AMP-the-format (as opposed to AMP-the-library-of-components) was pretty clear. If you were a publisher and you wanted to appear in the top stories carousel in Google search, you had to publish using AMP. Just using the components wasn’t enough. Your pages had to be validated as AMP-the-format.
That’s no longer the case. From May, pages that are fast enough will qualify for the top stories carousel. What will publishers do then? Will they still maintain separate AMP-the-format pages? Time will tell.
I suspect publishers will ditch AMP-the-format, although it probably won’t happen overnight. I don’t think anyone likes being blackmailed by a search engine:
An engineer at a major news publication who asked not to be named because the publisher had not authorized an interview said Google’s size is what led publishers to use AMP.
The pre-rendering (along with the lightning bolt) that happens for AMP pages in Google search might be a reason for publishers to maintain their separate AMP-the-format pages. But I suspect publishers don’t actually think the benefits of pre-rendering outweigh the costs: pre-rendered AMP-the-format pages are served from Google’s servers with a Google URL. If anything, I think that publishers will look forward to having the best of both worlds—having their pages appear in the top stories carousel, but not having their pages hijacked by Google’s so-called-cache.
Does AMP-the-format even have a future without Google search propping it up? I hope not. I think it would make everything much clearer if AMP-the-format went away, leaving AMP-the-collection-of-components. We’d finally see these components being evaluated on their own merits—usefulness, performance, accessibility—without unfair interference.
So my role on the advisory committee so far has been to push for clarification on what we’re supposed to be advising on.
I think it’s good that I’m on the advisory committee, although I imagine my opinions could easily be be dismissed given my public record of dissent. I may well be fooling myself though, like those people who go to work at Facebook and try to justify it by saying they can accomplish more from inside than outside (or whatever else they tell themselves to sleep at night).
The topic I’ve volunteered to help with is somewhat existential in nature: what even is AMP? I’m happy to spend some time on that. I think it’ll be good for everyone to try to get that sorted, regardless about how you feel about the AMP project.
I have no intention of giving any of my unpaid labour towards the actual components themselves. I know AMP is theoretically open source now, but let’s face it, it’ll always be perceived as a Google-led project so Google can pay people to work on it.
That said, I’ve also recently joined a web components community group that Lea instigated. Remember she wrote that great blog post recently about the failed promise of web components? I’m not sure how much I can contribute to the group (maybe some meta-advice on the nature of good design principles?) but at the very least I can serve as a bridge between the community group and the AMP advisory committee.
After all, AMP is a collection of web components. Maybe.
I can see how this would be good to have fixed at the browser level.
I’m a big fan of HTML5’s datalist
element and its elegant design. It’s a way to progressively enhance any input
element into a combobox.
You use the list
attribute on the input
element to point to the ID of the associated datalist
element.
<label for="homeworld">Your home planet</label>
<input type="text" name="homeworld" id="homeworld" list="planets">
<datalist id="planets">
<option value="Mercury">
<option value="Venus">
<option value="Earth">
<option value="Mars">
<option value="Jupiter">
<option value="Saturn">
<option value="Uranus">
<option value="Neptune">
</datalist>
It even works on input type="color"
, which is pretty cool!
The most common use case is as an autocomplete widget. That’s how I’m using it over on The Session, where the datalist
is updated via Ajax every time the input is updated.
But let’s stick with a simple example, like the list of planets above. Suppose the user types “jup” …the datalist will show “Jupiter” as an option. The user can click on that option to automatically complete their input.
It would be handy if you could automatically submit the form when the user chooses a datalist option like this.
Well, tough luck.
The datalist
element emits no events. There’s no way of telling if it has been clicked. This is something I’ve been trying to find a workaround for.
I got my hopes up when I read Amber’s excellent article about document.activeElement
. But no, the focus stays on the input when the user clicks on an option in a datalist.
So if I can’t detect whether a datalist has been used, this best I can do is try to infer it. I know it’s not exactly the same thing, and it won’t be as reliable as true detection, but here’s my logic:
Here’s how that translates into DOM scripting code:
document.querySelectorAll('input[list]').forEach( function (formfield) {
var datalist = document.getElementById(formfield.getAttribute('list'));
var lastlength = formfield.value.length;
var checkInputValue = function (inputValue) {
if (inputValue.length - lastlength > 1) {
datalist.querySelectorAll('option').forEach( function (item) {
if (item.value === inputValue) {
formfield.form.submit();
}
});
}
lastlength = inputValue.length;
};
formfield.addEventListener('input', function () {
checkInputValue(this.value);
}, false);
});
I’ve made a gist with some added feature detection and mustard-cutting at the start. You should be able to drop it into just about any page that’s using datalist. It works even if the options in the datalist are dynamically updated, like the example on The Session.
It’s not foolproof. The inference relies on the difference between what was previously typed and what’s autocompleted to be more than one character. So in the planets example, if someone has type “Jupite” and then they choose “Jupiter” from the datalist, the form won’t automatically submit.
But still, I reckon it covers most common use cases. And like the datalist
element itself, you can consider this functionality a progressive enhancement.
I completely agree with every single one of Terence’s recommendations here. The difference is that, in my case, they’re just hot takes, whereas he has actually joined the AMP Advisory Committee, joined their meetings, and listened to the concerns of actual publishers.
He finds:
- AMP isn’t loved by publishers
- AMP is not accessible
- No user research
- AMP spreads fake news
- Signed Exchanges are not the answer
There’s also a very worrying anti-competitive move by Google Search in only showing AMP results to users of Google Chrome.
I’ve been emailing with Paul from the AMP team and I’ve told him that I honestly think that AMP’s goal should be to make itself redundant …the opposite of the direction it’s going in.
As I said in the meeting - if it were up to me, I’d go “Well, AMP was an interesting experiment. Now it is time to shut it down and take the lessons learned back through a proper standards process.”
I suspect that is unlikely to happen. Google shows no sign of dropping AMP. Mind you, I thought that about Google+ and Inbox, so who knows!
Cassie’s terrific talk from Bytes Conf, featuring some wild CSS experiments.
(Conference organisers—you want Cassie on your stage!)
Tim takes a closer look at this Google Lite thing.
Following on from that proposal for a browser feature that I linked to yesterday, Tim thinks through all the permutations and possibilities of user agents allowing users to throttle resources:
If a limit does get enforced (it’s important to remember this is still a big if right now), as long as it’s handled with care I can see it being an excellent thing for the web that prioritizes users, while still giving developers the ability to take control of the situation themselves.
The start of a new year is the traditional time for making resolutions. I’ve done it in the past. Now I’m not sure it’s such a good idea.
Think about it. It’s January. The middle of winter. It’s cold outside. The days are short. The only seasonal foods available are root vegetables and brassicas. Considering this lack of sunlight and fruit, it seems inadvisable to try to also deny yourself the intake of sugar, alcohol, meat, carbohydrates or gluten. You’re playing with a stacked deck. And then when inevitably, in the depths of winter, you cave in and pour yourself a glass of wine or indulge in a piece of cake, you now have the added weight of guilt on your shoulders to carry through the neverending winter nights.
Of course not all resolutions involve the abnegation of material pleasures. Many a new year’s promise involves a renewed commitment to work, exercise, or culture-vulching. But again, is this really the best time of year to do that? Given the weather, are you really in the best frame of mind to tackle such a tall order?
No, I don’t think I’ll be making any new year’s resolutions. If anything, this is the time of year when I won’t feel bad about having a pint of ale or a comforting stew. It’s also the time of year when I’m going to cut myself more slack if I’m not exercising diligently or working hard. Let’s face it, just making it through these months intact should be achievement enough.
If I were to make a resolution, it would only be that, come summertime, I’ll take stock and maybe make a commitment to cut down on some guilty pleasure or increase some noble activity then. A midsummer’s resolution, if you will.
Until then, I’ll be cosying up and indulging in any bodily comforts I crave. My resolve to do that is strong.
Well, this an interesting format experiment—the latest Black Mirror just dropped, and it’s a PDF.
There’s something quite Bridlesque about these lovely books that Brendan is generating from git commits.
Dave uses just a smidgen of JavaScript to whip HTML5’s native form validation into shape.
Instead of being prescriptive about error messaging, we use what the browser natively gives us.
I’ve never been so excited by a single diff in a JSON file.
Service workers are coming to Safari.
If you feel you are being watched, you change your behavior. Big Data is supercharging this effect.
Some interesting ideas, but the tone is so alarming as to render the message meaningless.
As our weaknesses are mapped, we are becoming too transparent. This is breeding a society where self-censorship and risk-aversion are the new normal.
I stopped reading at the point where the danger was compared to climate change.
Joschi is documenting his commitment to “contribute at least one meaningful commit a day to a public Open Source project or a similar community effort.” So far it’s a really nice mix of coding and face-to-face activities.
Making fire, building shelter, throwing spears …all useful post-apocalyptic skills documented on the primitive technology blog.
Primitive technology is a hobby where you make things in the wild completely from scratch using no modern tools or materials. This is the strict rule. If you want a fire- use fire sticks, an axe- pick up a stone and shape it, a hut- build one from trees, mud, rocks etc. The challenge is seeing how far you can go without modern technology. If this hobby interests you then this blog might be what you are looking for.
This is so wonderful! A 3D fly-through of the Apollo 11 command module, right in your browser. It might get your fan whirring, but it’s worth it.
Click through for lots of great details on the interface controls, like which kinds of buttons and switches were chosen for which tasks.
And there’s this lovely note scrawled near the sextant by Michael Collins (the coolest of all the astronauts):
Spacecraft 107, alias Apollo 11, alias ‘Columbia.’ The Best Ship to Come Down the Line. God Bless Her.
Simon’s in-depth report on the Decentralized Web Summit.
One more reason to make the switch to HTTPS.