My wife Liz and I have been running the OpenBenches project for about 8 years - it's a crowd-sourced repository of memorial benches. People take a geotagged photo of a bench's plaque, upload it to our site, and we share it with the world. Might sound a bit niche, but we have around thirty-nine thousand benches catalogued from all over the world.

From the start, we had a comment form under each bench. Of course, we pre-moderate any comments. That helps with our Online Safety Act obligations and prevents spam from being published. We don't collect any personal data, to reduce our GDPR exposure. Our comments are self-hosted using the excellent Commentics - which means we don't send people's data off to a 3rd party.

We thought that this would be used to tell us that an inscription was wrong, or if a bench had moved, or something like that.

We were completely wrong!

People use OpenBenches comments for all sorts of things. Of course, there are a few which provide details about the bench itself:

Other provide a little context about the person:

But those sorts of comments are hardly the majority. The comments break down (roughly) into these categories:

I want to know more about this person

I sat on this bench, searched for the inscription and found this site. I want to share my feelings

Thank you for putting a bench here

This has moved me

My heart has broken

I can't visit this bench, but I'm glad someone has shared a photo

Thank you for adding a photo

I don't know the person this bench commemorates, but I want to let them know they're still loved and remembered

That's nice

Hundreds of people sharing connections. Wanting to express their feelings. Understanding the terrible pain of loss and the hope that, someday, someone will think fondly of us.

You can view all the comments on OpenBenches.org.

The modern web isn't like that.

You can make your HTML as malformed as you like and the web-browser will do its best to display the page for you. I love the todepond website, but the source-code makes me break out in a cold sweat. Yet it renders just fine.

Sure, occasionally there are weird artefacts. But the web works because browsers are tolerant.

You can be crap at coding and the web still works. Yes, it takes an awful lot of effort from browser manufacturers to make "do what I mean, not what I say" a reality. But the world is better for it.

That's the crucial mistake that XHTML made. It was an attempt to bring pure syntactic rigour to the web. It had an intolerant ideology. Every document had to precisely conform to the specification. If it didn't, the page was irrevocably broken. I don't mean broken like a weird layout glitch, I mean broken like this:

The user experience of XHTML was rubbish. The disrespect shown to anyone for deviating from the One True Path made it an unwelcoming and unfriendly place. Understandably, XHTML is now a mere footnote on the web. Sure, people are free to use it if they want, but its unforgiving nature makes it nobody's first choice.

The beauty of the web as a platform is that it isn't a monoculture.

That's why it baffles me that some prominent technologists embrace hateful ideologies. I'm not going to give them any SEO-juice by linking to them, but I cannot fathom how someone can look at the beautiful diversity of the web and then declare that only pure-blooded people should live in a particular city.

How do you acknowledge that the father of the computer was a homosexual, brutally bullied by the state into suicide, and then fund groups that want to deny gay people fundamental human rights?

The ARM processor which powers the modern world was co-designed by a trans woman. When you throw slurs and denigrate people's pronouns, your ignorance and hatred does a disservice to history and drives away the next generation of talent.

History shows us that all progress comes from the meeting of diverse people, with different ideas, and different backgrounds. The notion that only a pure ethnostate can prosper is simply historically illiterate.

This isn't an academic argument over big-endian or little-endian. It isn't an ideological battle about the superiority of your favourite text editor. There's no good-natured ribbing about which desktop environment has the better design philosophy.

Denying rights to others is poison. Wishing violence on people because of their heritage is harmful to all of us.

Do we want all computing to go through the snow-white purity of Apple Computer? Have them as the one and only arbiters of what is and isn't allowed? No. That's obviously terrible for our ecosystem.

Do we want to segregate computer users so that an Android user can never connect their phone to a Windows machine, or make it impossible for Linux laptops to talk to Kodak cameras? That sort of isolation should be an anathema to us.

Why then align with people who espouse isolationism? Why gleefully cheer the violent racists who terrorise our communities? Why demean people who merely wish to exist?

The web runs on tolerance. Anyone who preaches the ideology of hate has no business here.

Every site that I sign up for asks me to upload an avatar to represent myself. Whenever I change my photo, I have to log in to a hundred sites and change it there⁰.

Perhaps they could all use Gravatar - but that's a centralised service¹ and doesn't work with wildcard email addresses. Libravatar also relies on email addresses and requires implementers to set up new DNS entries.

So I'm proposing .well-known/avatar. Here's how it works (for now). I'd like your feedback before going further².

I sign up to a service and use the email address whatever@shkspr.mobi.

The service looks up my avatar using a well-known path. For example, request https://shkspr.mobi/.well-known/avatar?resource=acct:whatever@shkspr.mobi and you'll get back this JSON:

{
    "subject": "acct:whatever@shkspr.mobi",
    "links": [
        {
              "rel": "http:\/\/webfinger.net\/rel\/avatar",
             "type": "image\/webp",
             "href": "https:\/\/shkspr.mobi\/.well-known\/avatar\/avatar-1024.webp",
            "sizes": "1024x1024"
        },
        {
              "rel": "http:\/\/webfinger.net\/rel\/avatar",
             "type": "image\/jpeg",
             "href": "https:\/\/shkspr.mobi\/.well-known\/avatar\/avatar-512.jpg",
            "sizes": "512x512"
        }
    ]
}

That's a slightly enhanced https://webfinger.net/rel/#avatar which adds a sizes parameter. The service can then pick the appropriate MIME and size.

Alternatively, you can request the same URl but with a header of Accept: image/gif and receive the default sized avatar in that specific format.

Try it by running:

curl -H "Accept: image/avif" https://shkspr.mobi/.well-known/avatar/ --output "test.avif"

You should receive an auto-converted version of my avatar.

Some Thoughts

Please add your thoughts to the comments box. Here's some feedback I've received so far.

Perhaps this is too complicated? What's wrong with just serving up an image when the URl is requested? That would make it easier for static sites.

Simon Josefsson

@jas@fosstodon.org

@Edent Thinking about this, while I like content negotiation as a clever hack, I wonder if maybe it isn’t too clever. The nice thing with WKD is that you can deploy it with any normal static HTTP file without any special magic. Maybe the protocol could be dumbed down to simply rely on WKD-style URLs? I’m not sure how to configure my web server (Apache) for your avatar well known URL with negotiation magic.

2025-10-23, 16:50 0 boosts 1 favorites

What about a size parameter?

Chip

@chip@talking.dev

@Edent It'd be nice if the query could limit the size of the avatar being returned. If only there were `Accept-Max-Size`, but maybe a query param? I wouldn't want my performance taking a dive if Alice has a 35M avatar that my client starts downloading. If my client had requested with `max_size=3072` I'd rather not see the avatar than degrade performance/pull excess data

2025-10-23, 15:02 0 boosts 1 favorites

Will anyone actually use it?

Andreas Gohr

@splitbrain@fedi.splitbrain.org

@Edent good luck with getting the hundreds of services to implement it. I mean it. it would be awesome and you might be well connected enough to make it happen.

2025-10-23, 15:03

What about hashing the email?

David Bushell 🎮

@db@social.lol

@Edent would using a hash of the email address in its place improve privacy? 🤔

2025-10-25, 11:52 0 boosts 0 favorites

You've already given the service your email address, and your domain already knows your account name - so there's no privacy leak here. Obviously, a service shouldn't hotlink to your avatar image.

How about DNS?

I like it. Is there an argument that service / endpoint should be specifiable at the DNS level?As others in your comments pointed out, if your site is currently just static, some users might prefer to run an entirely separate dedicated avatar service.

— Emily Shepherd (@emi.ly) 2025-10-25T11:57:43.456Z

Personally, I think that's a bit complicated, but I'm happy to be convinced.

Is this restricted to email?

No! For example, if you know my GitHub username then you should be able to get the avatar from https://github.com/.well-known/avatar?resource=acct:edent

How can a service tell if the avatar has been updated?

Perhaps a hash, timestamp, or something else?

Can requests for multiple accounts be sent at once?

I'm not sure how / if WebFinger handles this. I suppose there ought to be some limit to avoid overwhelming a server.

Proposal

I think the default should be to return an image.

If an accept of image/… is requested, the server should try to return an image in that format.

If an accept of application/json or similar is requested, the server should return a JSON document listing the available avatars.

I don't think a ?size= GET parameter is necessary; services can resize once they've downloaded, or use the JSON document to get the right size.

A limited amount of alt text could be added using the title attribute in the JSON.

Before I start writing up anything formal - I'd love your constructive criticism on this.

Safelinks allow your administrator, or someone at Microsoft, to stop you visiting a link which is malicious or suspicious. Rather than going to example.com, your link now goes to safelinks.protection.outlook.com/?url=example.com.

Hurrah! If you accidentally click on a naughty link you won't cause chaos and ructions.

Except, there's a tiny problem. People like to copy and paste links that they receive. Someone sends an email which says "here's the link to that report you asked for" which then gets copied into a document or a web page.

For example, I was reading this official document from the UK's Department of Health and Social Care. Slap bang in the middle is a link to another report:

That forces everyone who visits that link to go through Microsoft's proxy. That might protect users if a link later becomes suspicious. But, more likely, it will be used in analytics to further profile users who click on links. It also undermines a user's ability to see the final destination of a link unless they can manually URl-decode content in their head.

It appears that every large organisation which uses Microsoft is prone to this failure. Lots of UK Government departments publish content with safelinks:

The US Military too:

It's all over Twitter:

And there are hundreds of academic works infested:

Look, I get why people do this. They copy a link from an email, paste it in, click it, and it works. No one writes raw HTML by hand, nor should they have to. Our WYSIWYG tools work really well and hide all the mumbo-jumbo. Copy editors look at text; not hypertext. It's only nerds like me who hover over a link before clicking on it.

Perhaps I should stop worrying? Perhaps it is OK that Microsoft intercepts the clicks from people all around the world? Perhaps they can competently run a proxy which detects and blocks inappropriate content? Perhaps they won't ever abuse that facility?

Here's my prediction. In the next five or so years, Microsoft is going to accidentally shut off *.safelinks.protection.outlook.com and a million copy-and-pasted links across the web are going to break.

Think I'm over-reacting? A decade ago, Microsoft got rid of their MS Tag product and, shortly after, all their proxy links were shut off. Similarly, other proxies like McAfee have shut down with little warning.

Or maybe Microsoft's sub-domains will be hijacked?

Either way, if you work in digital publishing, please make sure that your links point directly to the content that you want; not to Microsoft's safelinks service.

That meant I couldn't see the images on the other half of the page for the rest of the journey. I had a sea of broken images.

Even though the page had fully loaded, the images were set to "lazy" loading. When my browser sees <img src="example.jpg" loading="lazy" /> it defers downloading the picture until it is about to scroll into view.

There's a few reasons why this is a good thing. If I leave the page before scrolling down, the browser doesn't waste time, energy, or bandwidth downloading images which will never be seen. That's good for my battery life and cheaper for my bill. It also saves the server from flinging bits around the world which are promptly trashed⁰.

And yet...

It seems that every time I'm on a train - or somewhere else with spotty Internet access - I run in to a situation where I previously had plenty of bandwidth and battery, but my user-agent decided it knew best. So it didn't attempt to load images until after I lost signal.

There's no way to disable Lazy Loading on Android Chrome or Android Firefox.

So, I guess I'm stuck. Lazy loading seems like one of those things which is great in certain circumstances, but has a pretty horrible failure mode¹.

Anyone else feel this way?

Foolishly, I missed the 10 year anniversary, but let's see how we're doing against those predictions a little over halfway through.

My prediction for the Web?

The same speed. Faster pipes & processors – more bloated markup & JS.

Well... fuck! Bang on the money there. The web is faster than it was on dial-up. But I can't say that it's noticeably better since I got ADSL. Sure, it's faster to download big files and stream 4K video. But for day-to-day browsing? Between the unoptimised "hero" images, multi-megabytes of JS, and thousands of trackers, it sometimes feels like we've taken a step backwards in speed.

We all know that bloat expands to fill available bandwidth. But perhaps we could rein it in a little? Please?

A few of the predictions are already here. Better, smarter phones. Computers becoming pervasive and invisible. And, yes, lots of cat gifs.

Some of the other predictions are - I think it's fair to say - not quite on track.

We haven't returned to an AOL model where AT&T charge us per minute. And I don't see any path to that.

Internet censorship is a tricky one. There are some countries which routinely shut off net access. There's still a cat-and-mouse game with pirates. There are still people crying censorship when their inflammatory posts are removed. But, outside of a few jurisdictions, you remain as free as ever to criticise whoever you want.

Holograms aren't even close to real. And, no, Facebook's laughable attempts at the MeTAvErSe don't count. Perhaps Apple's iBalls (or whatever they're called) will get us to that point before 2031? But I doubt it.

There are a lot of predictions about 3D printers. Look, they're pretty nifty, but it is clear that most homes don't need an endless supply of rapidly printed plastic doodahs.

Finally, there are a couple which I still think are feasible by 2031. Take this one from Santiago Ochoa:

Companies like Google, Facebook, PayPal, Amazon, will create virtual currency systems linked to our social reputation. The more friends, posts, contacts, and comments we have, the more +1s, “like it”s or whatever points we’ll accumulate. These points will then be used to buy real things like you do now with PayPal and Amazon. Good social communicators will be able to make a living out of social networking points. Similar to Second Life but not limited to a virtual world. Our cell phones will be used as wallets and even some salaries will be paid with virtual money.

Social credit scores aren't mainstream… yet. But Twitter is experimenting giving revenue to some posters based on their social reach. Facebook's currency dreams are dead for now, but I bet another social network will try to use virtual money as its hook. Some people are, no doubt, being paid in volatile cryptotokens. And many of us use our phones as tap-to-pay wallets.

There's also this by Pedro Henrique Monteiro Padilha:

Internet will more and more allow people to work to companies on other countries or continents. It will also create a new way for all our social behavior, we will have web shows and maybe web pubs. The large bandwidth will help us connecting everywhere and we will no longer need TV as we know. Every TV show will be a stream to be brought in different languages.

That's pretty much the Covid experience, isn't it? Remote working, Zoom quizzes, livestreaming, and endless Netflix. Perhaps by the end of this decade streaming services won't be geo-restricted and decent subtitles will be available to all?

It's fun to see how accurate people's guesses are. But making predictions is usually less about future gazing and more about understanding our current reality. It isn't about being right or wrong - it's about daring to dream of something brighter than today.

(It's the latter, obviously.)

We'll never know exactly whether users want this because Google is pathologically adverse to performing or publishing user research.

Anyway, I have a solution to all of Google's problems. Forget this notion of untrusted "user agents" executing code on untrustworthy computers. I have a foolproof way of getting pixel-perfect rendering on every device. It also stops scraping. And, as a little side effect, completely defeats ad blocking.

It's VNC.

This takes "Server Side Rendering" to the extreme. Render exactly how you want the page to look and then stream it over a remote framebuffer protocol. Users get to see exactly what you want them to see - ads included!

Just imagine the possibilities. No more worrying about which browser is being used - render everything through Chrome and stream to everyone!

Users simply can't alter the content they see - which keeps them safe from hackers, and protects your advertising revenue.

Low bandwidth? VNC will simply degrade the quality of what you see. Look, do you really want poor people viewing your expensive website?

Those naughty hackers won't be able to copy and paste your content - the trusted VNC viewer simply won't let them.

Want to track users across multiple sites? Might be tricky. Just route all your content through Google's AMP VNC service!

...ugh... I've reinvented Opera Mini and given myself a sad.

There are so many decent people working at Google. And all the good they're trying to do is being drowned out by mediocre and mendacious crap like this. Google desperately needs to be broken up. It's simply untenable to have the largest browser in the hands of the largest web advertising firm. Android isn't safe with a firm which priorities their advertisers' needs over their customers' needs.

The thing is, this is coming. There is literally nothing you can do to stop it. Your protests are meaningless next to the desire for some people at Google to sanitise the web.

Over time, the branding faded and GU.com became a URL shortening service. Tiny URls like gu.com/abc could be printed in papers, sent via SMS, or posted on Twitter. They made a huge fanfare about how it would help with analytics.

You can read some of the history of the shortner to understand why it was created.

Rev Dan Catt

@revdancatt

Niche twitter thread time. I'm raising a glass to the end of the @guardian's URL shortener gu.com, which is now on sale for £2.5 million.

Back when twitter was only 140 chars & didn't shrink url links itself, making short URLs a whole important thing.

1/8 pic.x.com/wu9joo3vkw

---

And now, for reasons best known to themselves, The Gaurdian have stopped the service and put GU.com up for sale.

The starting price is TWO AND HALF MILLION DOLLARS!

Look, if I had an asset that valuable and was looking at declining revenue, I'd sell it.

But breaking that URl comes with a problem. I've written before about why URl shortening is bad for users and bad for the web. I've even helped publish government guidance about it. But all of those were based on the premise that the shortener was a 3rd party service. I never thought someone would be as daft as to switch off their own service.

Here are some of the problems this sale causes.

Terence Eden is on Mastodon

@edent

Whoever buys the gu.com domain will effectively get to rewrite history.
They can redirect links like these - and change the nature of the content being commented on.

Joyce Alene

@JoyceWhiteVance

The Steele Dossier asserted Russian hacking of the DNC was "conducted with the full knowledge & support of Trump & senior members of his campaign.” Trump's war against the FBI & efforts to obstruct make sense if he thought they could prove it. gu.com/p/axa7k/stw

---

---

Is there a tweet somewhere of a future politician saying "I support this 100% GU.com/...."? Redirect that to something horrific and you have a potential scandal on your hand.

There are lots of academic papers with gu.com shortened links. Those are all now dead.

Millions of links around the web - including many on the Grauniad itself - are all now broken.

The Guarrdian could fix this by publishing a list of all the shortened URls. That wouldn't stop links breaking, but would make it possible for researchers to reconstruct the original destination.

For decades, we've tried to remind people that "Cool URls Don't Change". We'll just have to hope that the people of the future find a way to decipher all these obsolete links.

I thought I'd take a look at how they stack up today. And investigate whether the BBC is still living up to them.

Here are the slides if you want to play along at home:

1. Build Web Products that meet user needs

This is still good advice! Sadly, there are still too many services around the web which are built on business needs. People grudgingly sign up for accounts to basic services which don't really need it - all because a business wants to see a number go up.

I find my needs being increasingly unmet by the BBC - other than them continuing to produce Doctor Who. I suspect I'm not their demographic target. But, more importantly, I see lots of digital products (like Sounds) which seem to go against the grain of user needs and instead focus on what the BBC wants.

2. The very best websites do one thing really well

An extension of the UNIX tools philosophy.

I have mixed feelings about this. I don't think there's anything inherently wrong with a site which does multiple things. It's just rare for any site to do two things well. For example, both Twitter and Facebook could have created something like TikTok - and it would fit in relatively well with their existing site. But the business culture of most organisations just doesn't allow any deviation from a central mission.

Does it make sense to have a website which does both cake recipes and Estonian literary criticism? If you can do both, great! But that's a rare skill.

Does the BBC still embodies this principle? I think it depends on how you define a website. They have multiple sites doing multiple things.

3. Link to other high quality sites

The BBC's news pages still don't do this regularly. When reporting on a publication, it is rare that they ever link to primary sources. There's a real reluctance in most organisations to let people leave the site.

But it is still a relevant principle! The web is a series of links. It only works because people can trace backwards through your sources.

4. Fail Forward, Fast

A bit of early-2000s culture there! For new services, it still makes sense. For larger and more established services, it isn't OK to "move fast and break things".

But the principle of trying new things and being prepared to admit that they've failed is wonderful. It's humbling and informative. I don't see much evidence of this in the BBC. I'm not a regular user of their services - but there have been a few big launches recently which seem to have failed - but haven't yet been put out of their misery.

Failure is only a problem if you don't learn from it.

5. Treat the entire web as your creative canvas

This is a bit of a weird one. I think they're trying to say that users exist outside of your site. You need to have a presence on other sites - and then use them in the appropriate way.

For example, the BBC has multiple Twitter accounts. They exist independent of the main BBC web site.

This is mostly good advice. If you have the resources, you should be playing around with other sites and maximising your presence there. You've got to meet people where they are.

6. The web is a conversation, join in

I despise the faux friendly tone of voice adopted by most organisations. Nevertheless, you can't ignore what people are saying about you. You don't have to take the advice of your critics, but you probably ought to show that you've heard them.

The BBC is usually good at joining in with conversations - but like all large institutions, it has a pathological fear of expressing contrition.

7. Any website is only as good as its worst page

Oooh! A spicy take! 100% accurate. We've all seen a shiny front page, and then an absolute shitshow of a subsequent page. Think of all those airline websites which make it so easy to book a flight and then horrific to cancel your booking.

People do remember negative experiences. If you've ever run a moderately popular site, you'll know that people lovel complaining about how awful it is based on an obscure and unloved section.

8. Make sure all your content can be linked to. Forever.

You would have thought, after flushing the early Doctor Who recordings down the memory hole, the BBC would have learned from this mistake. Apparently not.

Timbl was writing about this problem in 1998!

I get that the BBC might have licencing agreements that make keeping some stuff online impossible. And old webservers need to be continually fed, watered, and patched to stop them from becoming a liability. But too many of the Beeb's early sites and links are dead.

This is still good advice. Keep your content up as long as you can. You never know when someone will stumble across it.

9. Remember your granny won't ever use Second Life

Ooof! A bit of casual sexism and ageism there. But probably accurate in that no one is using Second Life.

The underlying point - late adopters have different needs from early adopters - is helpful. The words we use, the tropes we employ, and the interfaces we design all need to be accessible for new users.

I wonder how well the new BBC sites work for that demographic?

10. Maximise routes to content

Again, still good advice. I suppose we'd call this an "omnichannel strategy" today. Get your links out on social networks, videos, TV screens, and anywhere your audience are.

But, the BBC kinda breaks this. So many of their routes in are "download this app" or "search for us on". That obscures the direct link to specific content.

People don't live on one site. Well, OK, maybe Facebook! You have to accept that they won't all come through your front door. Make it easy to go from outside your site straight to a specific part of it.

11. Consistent design and navigation needn't mean one-size-fits-all

I think we all know the power of consistent branding, and it is reassuring to users if they understand how to get back to the start of a page. I agree that navigation needs to adapt depending on the size of the device.

Judging from the few BBC sites I visit, this isn't a priority for them any more. Each site seems desperate to push its own brand identity - which is a business need, not a user need.

12. Accessibility is not an optional extra

Tattoo that inside people's eyelids! Excellent advice.

13. Let people paste your content on the walls of their virtual homes

Things like OEmbed make this pretty easy nowadays. There will always be sites which want to jealously guard their own content, but it's still good advice.

The BBC seems reasonable at doing this. Of course, copyright often gets in the way.

14. Link to discussions on the web, don't host them

The BBC seems to flit back and forth on this. Some of their sites embrace comments, others don't.

I have mixed feelings. I don't think sites should "own" the user and try to force them to comment in one officially sanctioned place. And moderation is a complex and costly business. It probably makes sense to let people know how to join in with a conversation on social media ("Hashtag Strictly!").

But the downside is that you're exposing your users to unmoderated and unfiltered content. Is that best for you? Is it harmful to them?

15. Personalisation should be unobtrusive, elegant and transparent

Ha! The BBC have reversed this in the last few years. Almost every one of their sites and apps begs you to sign in with an account. And, judging from the account they forced me to get on iPlayer, the personalisation is crude and obvious.

Do users want personalisation? That's hard to answer. Every power-user swears they want complete control and hates algorithmic choice. But for more casual users, it is a great way to find interesting content.

The real problem is that the algorithms are usually designed to promote profitable content. That is, content the business wants users to see - not what users would choose.

And now?

There's a fair bit of early-web-2.0 idealism in these 15 principles. In truth, I'm hard pressed to disagree with any of them. Throughout the web - not just on the BBC - they are often observed mostly in the breach.

I wonder if the BBC is culturally capable of producing something like this in 2022? And, more importantly, enforcing it on its own sites?

What will the next 15 years bring?

Suppose you have an article written in HTML. The basic layout might be something like:

<body>
   <main>
      <article>
        The content of your article
        ...

Pretty standard. Now suppose you let users add comments to the article. I have two questions:

1. Where in the tree should they go?
2. What HTML element should be used to group them?

It is, I think, a question where reasonable parties can justifiably come to distinctly different conclusions.

Where?

Are comments a part of the article or are they apart from the article?

If you wrongly think that user-generated content is indivisible from the text of the article, then the answer is:

<body>
   <main>
      <article>
         The content of your article
         <div>
            Comments

If, however, you're fool enough to believe that commentary is separate from what is commented on, then you'll probably pick:

<body>
   <main>
      <article>
        The content of your article
      </article>
      <div>
         Comments

Some idiots will insist that comments shouldn't even be considered next to the purity of the content of <main>. Hence:

<body>
   <main>
      <article>
        The content of your article
      </article>
   </main>
   <div>
      Comments

As ever, let us see what wisdom the HTML editors passim have given us.

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry.

4.3.2 The article element

Ah! This is evidence that comments should be inside the article itself.

The code they give is (simplified):

<article>
   <h1>Page Heading</h1>
   <p>...</p>
   <section>
      <h1>Comments</h1>
      <article>
         <p>Comment text</p>
     </article>

But, that's not the whole story!

A section forms part of something else. An article is its own thing. But how does one know which is which? Mostly the real answer is "it depends on author intent".

[…]

A comment on an article is not part of the article on which it is commenting, therefore it is its own article.

4.3.12.1 Article or section?

Although that section is non-normative, I think it is instructive.

The article is its own thing. A comment may relate to an article, but it is not part of the article. Therefore, it's perfectly reasonable to place the comments outside the original article.

What?

Ideally, there would be a <comment> element. There isn't.

Bruce Lawson

@brucel

The <dialog> element is added to #html5 dev.w3.org/html5/spec/com… I'm glad to see it (accessible dialogue boxes!) even if it is badly mis-spelled

---

Terence Eden is on Mastodon

@edent

Replying to @brucelWhy the hell isn't there a <comment> element in #html5? @brucel? Who's arse do I need to ki[ss|ck] to make this happen?

---

As shown in the above code example, comments can be enclosed in a <section> element. And each comment itself can be wrapped in an <article>.

article
A complete, or self-contained, composition in a document, page, application, or site […] This could be a forum post, […] a blog entry, a user-submitted comment […] or any other independent item of content.

Article Usage Summary

I had thought the <aside> element might also be suitable. It represents:

content that is tangentially related to the content around the aside element, and which could be considered separate from that content.

Are comments tangentially related? Not really. And comments don't generally appear inside the thing they're commenting on. So I discarded that idea.

Why is this important?

It isn't, really. Good semantic metadata should make clear what is content and what is commentary.

But not everyone consumes metadata. Bots, scrapers, and search engines should have a sensible way of heuristically determining what is relevant to them based on the markup of the document. Unless we get a new <comment> element, we need to provide hints to user-agents about exactly what we mean.

I took an extremely scientific poll on Twitter to see if my acolytes agreed with me.

Terence Eden is on Mastodon

@edent

A two part question about semantic HTML.

1) What's the "correct" HTML elements for user generated comments?
Why?

---

<aside>: (42)
42
<section>: (64)
64
<div>: (30)
30
<bgsound>: (15)
15

---

Terence Eden is on Mastodon

@edent

Replying to @edentContinuing:
2) What should the document tree look like?
Why?
Currently, I have
<body>
<main>
<article>
</article>
<~comment~>
But should the comments be inside the article? Or perhaps outside the main?

---

<article><~comment~></art: (16)
16
</article><~comment~>: (36)
36
</main><comment>: (4)
4
<div><div><div><div><div>: (9)
9

---

So, <section> wrapped around a group of <article>s, all of which are outside the <article> being discussed seems to me to be a sensible way to demarcate content from commentary. Leaving us with:

<body>
   <main>
      <article>
        The content of your article
      </article>
      <section>
         <h1>Comments</h1>
         <article>
            Comment
         </article>
         <article>
            Comment
         </article>
      </section>
   </main>
</body>

Do feel free to tell me I'm wrong in the comments. The box is down there, somewhere…

I remember, years ago, working on a mobile web service which had a URl bar - so users could tap in bbc.co.uk on their T9 keypads - and a separate search bar. I thought that was pretty nifty. But it turns out, users tried searching for URls and they tried going to "http:// When is the Next Bus?". Bloody users!!

Users find input bars confusing. A good example of this is Amazon's search bar. It faithfully records what everyone is searching for and uses that big data to suggest to other users what they might be interested in. Which leads to some "interesting" results.

Here's what happens if you start searching for https://

(And, yes, I used an incognito browser so it wouldn't be polluted with my own demented midnight searches for corrugated iron flavoured pogo sticks.)

There are a few lessons to take away from this.

• Users don't really understand interfaces
• Computers don't really understand users
• Big Data assumes that users are behaving in semi-rational manner

I needed to download a Windows Virtual Machine in order to upgrade the firmware on a device (long story). The official Windows 10 VM is 20GB

TWENTY GIGA-FUCKING-BYTES!!!

It downloaded reasonably quickly - yay fibre! But I had to wait almost as long to unzip the bloody thing. Whereupon, I discovered that zipping the file - and it was only one single file in there - saved a whole 200MB. Yup, a 1% saving.

As it happens, I downloaded the wrong VM. So I downloaded the right one. A similar size, although this had couple of files in it - but the ZIP didn't save much space.

At which point, my laptop - not unreasonably - threw a wobbly because I'd suddenly consumed 80GB of space!

I'm sure you're about to tell me that there's an esoteric Linux command that will automagically extract a file, delete the original archive, and repartition my SSD for optimal layout - but that's not the point.

Every web server can - and should - gzip files on transmission. Manually zipping a single file on your server doesn't save any download time. It doesn't save any bandwidth.

Perhaps it makes sense to bundle a few related files together - but if it is a single large file, a .zip just wastes the time and disk space of anyone who downloads it.

A few years ago I was doing policy research in a housing benefits office in London. They are singularly unlovely places. The walls are brightened up with posters offering helpful services for people fleeing domestic violence. The security guards on the door are cautiously indifferent to anyone walking in. The air is filled with tense conversations between partners - drowned out by the noise of screaming kids.

In the middle, a young woman sits on a hard plastic chair. She is surrounded by canvas-bags containing her worldly possessions. She doesn't look like she is in a great emotional place right now. Clutched in her hands is a games console - a PlayStation Portable. She stares at it intensely; blocking out the world with Candy Crush.

Or, at least, that's what I thought.

Walking behind her, I glance at her console and recognise the screen she's on. She's connected to the complementary WiFi and is browsing the GOV.UK pages on Housing Benefit. She's not slicing fruit; she's arming herself with knowledge.

The PSP's web browser is - charitably - pathetic. It is slow, frequently runs out of memory, and can only open 3 tabs at a time.

But the GOV.UK pages are written in simple HTML. They are designed to be lightweight and will work even on rubbish browsers. They have to. This is for everyone.

Not everyone has a big monitor, or a multi-core CPU burning through the teraflops, or a broadband connection.

The photographer Chase Jarvis coined the phrase "the best camera is the one that’s with you". He meant that having a crappy instamatic with you at an important moment is better than having the best camera in the world locked up in your car.

The same is true of web browsers. If you have a smart TV, it probably has a crappy browser.

My old car had a built-in crappy web browser.

Both are painful to use - but they work!

If your laptop and phone both got stolen - how easily could you conduct online life through the worst browser you have? If you have to file an insurance claim online - will you get sent a simple HTML form to fill in, or a DOCX which won't render?

What vital information or services are forbidden to you due to being trapped in PDFs or horrendously complicated web sites?

Are you developing public services? Or a system that people might access when they're in desperate need of help? Plain HTML works. A small bit of simple CSS will make look decent. JavaScript is probably unnecessary - but can be used to progressively enhance stuff. Add alt text to images so people paying per MB can understand what the images are for (and, you know, accessibility).

Go sit in an uncomfortable chair, in an uncomfortable location, and stare at an uncomfortably small screen with an uncomfortably outdated web browser. How easy is it to use the websites you've created?

I chatted briefly to the young woman afterwards. She'd been kicked out by her parents and her friends had given her the bus fare to the housing benefits office. She had nothing but praise for how helpful the staff had been. I asked about the PSP - a hand-me-down from an older brother - and the web browser. Her reply was "It's shit. But it worked."

I think that's all we can strive for.

Here are some stats on games consoles visiting GOV.UK

Matt Hobbs (@TheRealNooshu@hachyderm.io)

@TheRealNooshu

Replying to @TheRealNooshuInterestingly we have 3,574 users visiting GOV.UK on games consoles:
• Xbox - 2,062
• Playstation 4 - 1,457
• Playstation Vita - 25
• Nintendo WiiU - 14
• Nintendo 3DS - 16

20/22

---

Websites can access your system's camera and microphone. That's how modern video conferencing works in the browser. In an effort to retain user privacy, the browser asks the user for permission to use the camera and mics. No audio or video will be sent until the user agrees.

But some metadata gets shared before you agree!

Visit the WebRTC Detection Experiment site. You'll notice that without you agreeing, the site is able to determine how many microphones you have:

And how many cameras you have:

Having two cameras is perhaps a reasonable proxy for being a mobile phone / tablet. One main cam, one selfie cam.

Multiple microphones could be an indicator that the user is on a laptop. Built in microphone and an external USB microphone. Although some phones also present multiple microphones.

The names of the devices aren't sent until after you agree to the permission prompt.

There are inconsistencies between browsers:

It is useful to present to the user a selection of input devices. But does the site need to know how many devices are attached before permission has been granted?

The way the iPhone does it, is to present a fake set of data - one mic and one camera - until permission has been granted. Then it shows the real information.

Personally, I think the browser should only indicate a boolean to the site that AV inputs are available. Once permission is granted, then the site can request the number of devices and their names.

What do you reckon?

It downloads HTML and renders it at blazing fast speed. If you ever wondered just how slow modern web development has made the web - Lynx will show you the meaning of haste.

I use Lynx most days. Not as my exclusive browser - I'm not a masochist - but as a handy tool. If I'm on a bandwidth constrained connection, or a site is overloaded, or I just want to browse without distraction. Lynx is where it's at. It is also brilliant for seeing what weird markup bugs your site has.

Linux users can install it with sudo apt install lynx or similar. Everyone else can download Lynx from the official website.

This is what it looks like:

Using it is simple. On the command line, type lynx example.com to go to example.com.

Arrow keys up and down move you... up and down. Left goes back a page, right follows a link. Q quits. And that's all you need to know for your first five minutes.

Pressing the letter O gets you to the option screen. There are a bunch of things you can change here - and it shows off the UI pretty well.

There are some things you can't change here. If you want to always accept or reject cookies - rather than be prompted every time - you'll need to edit the ~/.lyncrc file.

Set accept_all_cookies=TRUE.

Why is this important

Computers lie to us. CSS hides our worst sins. JavaScript covers-up our poor architectural choices. With Lynx, there's no escape. You see the HTML rendered and that's it. Lynx renders all the HTML5 elements:

It also does interactive elements as well:

I've found so many bugs this way. Little quirks of markup which show up in the most unexpected places.

To be clear, Lynx isn't about accessibility testing. You should do that with proper tools which expose ARIA, show colour contrast, and the like. But Lynx is a good first pass at seeing how the text renders and flows, whether images have alt text, and if the general structure is easy to navigate.

Take some time to use it on your favourite sites today.

One thing most websites try to do is try to serve you the page as fast as possible. So I've decided to do the opposite. I've made a (toy) web server which goes as slow as humanly possible. You can visit it at http://slowww.rf.gd - but you'll need to be patient.

This delivers a page at about 175 bits per second. Yes, bits. Not bytes. It is deliberately set to be about as fast as an adult human can read. Why do you need your pages delivered any faster than you can read?

Can slowing things down make the web calmer and less distracting? Will it become a more thoughtful place to engage in dialogue? That sounds nice.

Anyway, the http://slowww.rf.gd site has formatting, images, and one or two surprises. And bunnies.

It was originally built as a sort of HTML teaching aide. Or, perhaps I wanted to recreate the old character-by-character BBS experience. It might be a meditative exercise about frustration. Could it be a way to show off some modern HTML5 features in a quirky way? Most likely, lockdown has sent me gently loopy.

It doesn't use JavaScript or anything client side to simulate slowness. It genuinely serves you up pages a few bytes at a time.

The code itself is not very exciting.

header('Cache-Control: no-cache, no-store, must-revalidate');   //  No Cacheing
header('Pragma: no-cache'); //  No Cacheing
header('Expires: 0');   //  No Cacheing
header('Content-Encoding: none'); // Disable gzip compression
header('Content-Type: text/html; charset=utf-8');   //  Be nice to the browser
ob_end_flush(); // Stop buffer
//  The body
$str = <<<EOT
<!DOCTYPE html><html lang="en-gb"><head><meta charset="utf-8"><title>Very Slow Website ...
EOT;
//  Count character in a safe way
$len = mb_strlen($str, 'UTF-8');

//  Echo each character and wait
for ($i = 0; $i < $len; $i++) {
    echo mb_substr($str, $i, 1, 'UTF-8');
    ob_implicit_flush(1); // Implicit flush at each output command
    //  1 second is 1000000
    usleep( 40000 );
}

die();

I'm not clever enough to squeeze one of those intricate 1K JavaScript demos into the site. But that's not what it is for.

The site works pretty well in Firefox. Tolerably in Chrome. And is only a little bit broken in Safari. It's worth experiencing it in other browsers, to see how the cope with being drip-fed HTML.

I hope you will find it a calming, educational, and mildly entertaining way to spend five minutes.

http://slowww.rf.gd

Many thanks to my beta testers: Liz, Thomas, Tom, Dom, Mike, yet-another Tom, Anna, Saul, Coco, Hugh, Mark, Neil, Andrew, David, Kate, and Lola.

Quickstart

Stick this line in the <head> of your HTML page.

<meta name="monetization" content="$ilp.uphold.com/ieELEKD7epqw">

That's it.

You should replace my uphold address with your own. Unless you want me to get paid for your work.

What is web monetisation

This is a draft specification for seamless payments on the web.

This gives a website visitor a few ways to pay to use a website.

1. Passive payment. You load your browser up with, say £5 per month. Your browser works out which sites your spent your time on, then splits the fiver between them.
2. Active payment. You visit a website and hit a paywall. You can tell the browser to pay for it - rather than going through an arduous payments process.

There's a lot more to it than that - obviously - but that'll do as a brief explanation.

Get Started As A Creator

I was asked to beta test Coil - so that's what this section will focus on.

They have a pretty simple guide to getting started. In theory, you can choose a variety of payment providers. I went with Uphold because they don't require you to use a shitty pseudo-currency based on half-baked Blockchain tech. You can get your money in pounds, pesos, paʻanga, or most other world currencies.

Uphold, like any reputable financial institution, has to perform a Know Your Customer check. The usual thing of sending in copies of your ID and proving you are who you claim. Nothing too arduous.

Once you have an "Interledger Payments" address - $ilp.uphold.com/ieELEKD7epqw - you can use it to start receiving payments from visitors.

Coil has a range of plugins for things like WordPress, and can even connect your YouTube and Twitch accounts to enable monetisation there.

Thoughts

We need a better way to pay for the web - because advertising sucks. At best it is boorish and irrelevant interruptions. At worst it is... well, look around you.

Unfortunately, as popular as my blog is, I quite often get notifications like this:

I know every penny helps - but that's a bit ridiculous!

It's a chicken-and-egg problem. But I think it's important that content creators take the first step. Start putting the meta elements on your pages now. Get the content and infrastructure there, and wait for consumers to catch up.

Coil could do with a bit more fine grained detail on where payments are coming from. It would be useful for me to know which of my pages performs best, or whether payments have come from YouTube or Twitch. But it is early days - I'm excited to see how it develops.

So, get started now with Web Monetisation - and perhaps we can rid the web of the scourge of advertising.

Here's the code (formatted for readability):

<time datetime="{{page.first_published_at|date:"c"}}">
   {{page.first_published_at|date:"j F Y"}}
</time>

You can also use last_published_at if it is a page which has been updated.

WHY?!??!

Semantics. HTML5 contains the <time> element. The contents of it show up as normal running text, but the metadata gives information to anything that reads the source-code that the text relates to a date.

It's fairly easy to tell that <p>3rd of May</p> is a date - well, it's only easy if you know that you're only ever looking for English text formatted a specific way.

For example, does <p>3/5</p> mean three-fifth, or does it mean 3rd of May? Or, are you American, and it means 5th of March?

So, we can use a <time> element with the datetime= metadata. The datetime tag takes an ISO8601 string.

Luckily, we don't have to write it out by hand. Django has a built-in template for that.

Hey presto! Your blog posts now contain machine-readable data about when they were published.

I've had to manually change it on a dozen different Slacks, a bunch of social networks, a few forums, all my email accounts, and I'm still not done.

I just want to change my photo once. Because I'm vain and lazy.

For a nerd like me, the solution is obvious:

• My latest avatar image has a permanent web address - https://edent.tel/avatar.
• When I register for a service, it should ask me for my homepage address and automatically detect the URl for my avatar.
• Periodically, it should check for an update.

What about Gravatar?

The Globally Recognised Avatar project from WordPress is supposed to be a solution to this problem. But it doesn't work, for two main reasons.

1. Not everywhere uses it.
2. Works on a per-email basis.

Nothing we can do about (1), but I find (2) is annoying. I use a different email address for each website I use. Which means I have dozens of Gravatars!

Because Gravatar uses MD5 hashes, there's no way around this. It's also a (minor) privacy concern.

What about Libravatar?

The Libravatar project is basically an open source version of Gravatar. It also uses hashes for email addresses. And, sadly, very few sites use it.

What about Webfinger?

The documentation for Webfinger is comically absent.

What about Microformats?

Standards like microformats2 let you add an image to your profile.

Similarly, Schema.org an add an image to your personal metadata.

Social Networking Sites

This sort of exists. Services like Avatars.io let you use you Twitter & Facebook avatars as a URl - for example avatars.io/twitter/edent.

Sadly, the service isn't maintained any more, has broken images for Instagram, and doesn't include newer services like GitHub.

Regain Control

There are two fundamental mistakes we're making.

• An email address is not an identity.
• A 3rd party service is not an identity.

Given that Gravatar is promoted by WordPress - the largest website provider on the planet - and it still isn't universally accepted, I don't think there's any hope for smaller services.

So, I guess what I need is an app which can log in to all my accounts and automatically change the avatar whenever I want.

Or is there some other practical action I can take?

But what about interactive images? Like panoramas and photospeheres?

Here's a 360° image. You can drag it to see all around.

That uses the fantastic Pannellum JavaScript Library. At the moment, there's no native way to represent that in HTML. If you use an <img> you'll get a flat, equirectangular image like this:

Here's two possible ways I've just thought of...

(These are just sketches of ideas - think of them as a starting point for user research, rather than a completed product.)

Extend <img> to be like <video>

An HTML5 video element looks something like this:

<video controls=false autoplay=true>

That tells the browser to start playing the video, but not to show any playback controls in the UI. Panoramic images could use something like:

<img panorama=true photosphere=false xdegress=270 src="...">

That is, this image is a panorama - but not a sphere - with 270 degrees of movement on the horizontal axis.

Or

<img panorama=true photosphere=true startx=120 starty=330 src="...">

Display a photosphere, make the initial view start at the following co-ordinates.

Use <picture>

As I've said before, I'm no fan of the <picture> element. I think it is inconsistently designed compared to other parts of HTML5.

Perhaps we could use it like this:

<picture>
  <source type="image/jpeg;panorama=true" srcset="pano.jpg">
  <img src="flat.png" alt="your browser doesn't support panoramics">
</picture>

That gives the MIME type of the image an extra parameter. Obviously, you'd need to put in other configuration options something.

What next?

A quick search didn't show anyone working on this as a proposal. That normally means either I'm not looking in the right places, or no one else is interested.

If you think this could be developed into a future standard, please let me know!