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.
You may have heard of Web Components, a suite of emerging standards that make it possible to build secure reusable widgets using web platform technologies. One of the first specs to make its way into implementation is HTML Templates, embodied by the
template element, which as I write this is implemented in Chrome Canary and Firefox Nightly.
One W3C specification which seems to have slipped below most people’s radar is Media Fragments 1.0, which moved to Candidate Recommendation status in December last year. Media Fragments is a syntax which extends the URLs of media files so that only selected portions are made available to the user; let me explain that further with a couple of examples.
Back in March I wrote about HTML5 Form validation and the problem with the appearance of error messages. I proposed a syntax for styling the error messages, and shortly after I published the post, I submitted the proposal to the W3C via the www-style mailing list.
I’ll discuss quickly the result of that submission, but first I should mention that I’ve since found out that the Google Chrome developers have already implemented their own syntax, and it’s not too far removed from what I proposed. Before I get to that, however, allow me to gripe.
A lot of the attention paid to HTML5 Forms has been centred around the new input types.
This is great for the future, but although you can start using these functions now (in many browsers), they aren’t without their drawbacks – well, one big drawback really. I’m going to explain briefly the problem, and then propose a solution.