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.
I’ve had a really busy year for public speaking, having had the pleasure of being invited to speak at ten events so far, from local grassroots meetings to professional conferences (with more to come). Not all of the talks are recorded but many are, so below I’ve selected a few videos from the last few months in the vain hope that you may find them interesting.
I recently ran into a problem involving the removeEventListener()
method, which caused me a good half an hour of confusion before a lightbulb appeared above my head and I was enlightened by a solution – a solution which, it must be said, is very obvious in hindsight. So doubtless many people know this already, but I’m recording it here along with another approach I thought of afterwards, in the hope that they may be useful to someone in the future.
Sometimes the existing HTML attributes aren’t sufficient for describing an element’s content. We can use class
, ref
, rel
, title
and more, but even so there are occasions where that’s not enough. HTML5 addresses this problem with the introduction of Data Attributes, which allow you to add simple metadata to individual elements, largely for the purpose of providing information to make JavaScript functions easier.
A new version of jQuery has quietly been released over the weekend. It’s only a minor point release but has a couple of features which look amazing: some selector functions now work up to 8x faster than the previous release; and there is support – very clever support – for HTML5 data attributes. Take a look at the jQuery 1.4.3 release notes for more.
Also released was the first alpha of jQuery Mobile, a touch-optimised amalgam of jQuery and jQuery UI. It’s actually a little buggy on my Galaxy S Android phone, but as it’s an alpha release that’s perfectly forgiveable. It looks pretty smart and comprehensive.
JavaScript libraries like jQuery and Prototype are amazing; flexible and powerful, they standardise processes and make cross-browser scripting really easy. I rarely work on a project nowadays where a library isn’t used.
Their ease-of-use has a slight drawback, however: it’s easy to rely on them too much, and lose sight of new developments in JavaScript. This was the reason for my not really paying much attention to an exciting recent introduction, the Selectors API, until I had cause to use it on a personal project.