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.
At the recent unveiling of OSX Mavericks Apple also announced Safari 7, with greatly improved web standards support. It was left a little unclear as to which versions of OSX it would run on, but browsing through their developer area this week I found a downloadable pre-release of Safari 6.1, which I think clears that up: it seems Safari 7 will be exclusive to Mavericks, while 6.1 will run on Lion and Mountain Lion, with all of the web standards support of Safari 7, but only a limited set of new features.
As both versions are a major update for the browser, bringing almost a year’s worth of WebKit updates, I thought it would be useful to take a look through the new and updated features in each, as well as trying to identify where they differ.