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.
There is a famous Portuguese-English phrasebook, published in the 19th Century, with the title “English As She Is Spoke”. It contains many unintentionally hilarious translations of words and expressions, including such familiar phrases as “that are the dishes whose you must be and to abstain”, and “I not make what to coughand spit”. The author, Pedro Carolino, had the best of intentions in producing this book, but suffered from one major drawback: he didn’t speak English. The book was apparently translated from an earlier Portuguese-French phrasebook, using a French-English dictionary.
The reason I bring this up is that I think this is a fairly common problem in coding. Many people know how to write code in order to get a result, but they don’t know the language at hand in enough depth to realise that the result doesn’t always make sense.