Jeremy Keith wrote a (typically great) post about metacrap, the unneccesarily verbose and repetitive metadata in the head of web documents, that’s required for content to be more easily shareable across social media. I fully agree with his broad point — there’s an awful lot of crap in
head — but there’s a flaw in his initial examples. It’s explained in this extract from Twitter’s Getting Started [with Cards] Guide:
You’ll notice that Twitter card tags look similar to Open Graph tags, and that’s because they are based on the same conventions as the Open Graph protocol. If you’re already using Open Graph protocol to describe data on your page, it’s easy to generate a Twitter card without duplicating your tags and data.
So actually the metadata you need to cater for most social sharing is Open Graph, with a few extra tags just for Twitter:
<meta name="twitter:card" content="summary"> <meta name="twitter:site" content="@adactio"> <meta property="og:url" content="https://adactio.com/journal/9881"> <meta property="og:title" content="Metadata markup"> <meta property="og:description" content="So many standards to choose from."> <meta property="og:image" content="https://adactio.com/icon.png">
I mean, it’s still perhaps too much, and (as pointed out) would probably be best written as JSON‐LD in the manifest. But there’s no redundancy, so is not quite as bad as painted in Jeremy’s article, even with his elegant squishing solution.
Yesterday Google announced ‘Eddystone’, a new open Bluetooth beacon format which works on Android and iOS. I’ve been doing a bit of reading about it to understand the technology and its potential, and I put together a briefing note about it for my colleagues. I’m a believer in maximising returns on my content, so it seems like a good opportunity to republish that briefing note here.
This is a very rapid and shallow look into beacons, and I’ve no doubt made some omissions or inaccuracies, so apologies in advance for that. If you think I’ve made any huge oversights or errors, please feel free to let me know in the comments.
I’ve spent a lot of time in my career writing and talking about future web features, from CSS3 to Web Components. But I’ve recently come to realise that, while I still think these features are important, I’ve been missing out on the bigger picture: the survival of the open web. That sounds hyperbolic, I know, but so many articles I’ve read, conversations I’ve had, and behaviours I’ve observed, have led me to the conclusion that the open web, in the form we know it now, is under threat.
It looks like custom elements, and web components in general, are beginning to break through into general developer consciousness, as I see more and more articles and talks discussing what they are, what they are good for, and how to make them.
As they’re not yet being used heavily in development, however, I think there’s a good opportunity to define best practices in the way we use them. In this post I want to propose a best practice method for writing custom elements: I’ll do that by comparing two methods for creating custom elements, along with the advantages and drawbacks of each.
Aside: it strikes me that I haven’t written about custom elements here on my own blog, despite having given a few talks and written a few published articles on the subject. In case you’re not sure what they are, I recommend you read my Detailed Introduction To Custom Elements first.
In September of last year I asked Google’s Eric Bidelman some questions about web components for a feature I was writing. Unfortunately it turned out there was no room in the article for Eric’s answers, but I recently stumbled across them again and decided they are too good to go to waste, so here they are.
Thanks very much to Eric for answering my questions, and apologies if the passage of time has outdated any answers.
On the 21st of March I had the pleasure of participating in the Web Components panel at Edge Conf, and the privilege of giving the introduction to the panel. I’m a strong advocate of Web Components and it was great to be able to provide my opinion on them, alongside some real experts in the field, as well as hear questions and feedback from the community. The main concern which was raised is that, as developers create their own elements, some important considerations — accessibility not least — could get forgotten about.