At HWC London tonight, I worked on a small thing – figuring out why my avatar was appearing blurry when pulled in to other sites following a webmention I’ve sent to them.

For example, on this like of one of Chris’ posts at

There’s me at the bottom left, cheerfully blurry.

I wasn’t quite sure why, because the h-card I added into my WordPress theme links to a profile image on my site that is 654×654.

Looking at this with Calum we saw that I have multiple h-cards appearing on any given page, and (other than the one I’ve hard coded) they all point to my image on Gravatar.  Not only that, they are specifically pulling out a 40px square version of my gravatar.

With a little inspection it turns out that every post on my site has a h-card embedded in it.  It’s in the post footer that is added to each post, like this:So the bit that says ‘by’ and my name, also includes h-card microformats.  And in that h-card markup, the image source is my gravatar image, at size 40px.

I wasn’t sure if having an h-card in every single post even made sense, but a bit of discussion with Barry helped me to understand the places you might have the h-card, and that while there’s various ways of doing it, an explicit h-card per post is certainly fine.  Barry pointed me to the authorship page on the wiki for more details on this.

OK, so where does the h-card per post come from in my site?  Given that it contains microformats, and I don’t think WordPress has much microformats built in, the most likely candidate is for it to be somewhere in my fork of the Sempress theme.

A quick search for h-card in the code of my theme for h-card shows yup, that’s where that post footer is being rendered.  It’s in the sempress_posted_on function – there’s a call to get_avatar, a built-in WordPress function.  In that call, the argument for the desired avatar size is being passed in as 40.

So I’ve bumped that up to 96, and all should now be well.




Paradigm shifts for the decentralized Web

As separate markets for data and apps emerge, Web development needs to adopt a new shape.

Interesting article on the Solid (Social linked data) platform.  It describes a lot of the decentralisation concepts that are explored and implemented in the indieweb movement (surprised the article doesn’t mention indieweb, in fact, given the W3C link), but comes at it from a Linked Data angle.  The language around markets and competition doesn’t really appeal to my personal politics, but good to see the philosophy of moving away from centralised silos being explored in different ways.

A big of a long-off goal with the indieweb BDD specs, would be for it to be a generic way to automate how many of the features of indieweb a site had implemented.  Kind of an automated IndieMark.  But really, just something to give you an idea of which features you could choose to implement, and which ones you’ve already implemented successfully.  It should of course be implementation agnostic – it’s just testing functionality after all (the point of BDD).

Why do BDD with my site?  It’s mostly as excuse to play around and learn about a few different things – indieweb, BDD, codeception.  I’m also a big fan of the BDD approach, forcing you to think about why you’re implementing something, what’s the value, before you go ahead and implement it.  Plus, regression tests FTW.

Started working on BDD specs for my site.  Using codeception – very impressed with it so far, quite a mature BDD tool.  After all the initial faffing around with setup, I’m at a point where I have a Gherkin spec that navigates to a page, checks for some content, and takes a screenshot.