What kind of Web Components do we need?

Published 02 July 2015 category: thoughts

Web Components will allow web developers to create their own elements: custom elements. Last week I attended the Web Component panel and accessibility break-out at Edge Conference, and left both sessions full of questions. One was: what kind of custom elements do we need?

The idea of Web Components and specifically their custom elements, is that you no longer depend on the browser to provide you with elements: you can bring your own. Many blog posts about the subject emphasise how exciting this is. Yes, this is exciting new tech. It gives website owners lots of freedom, but also a big responsibility. I think Web Components have their use case for the web at large, but I can’t help but feeling that for many websites, it will be too costly to create and unnecessary to use custom elements.

Existing HTML elements come with benefits

Many of the existing, standardised HTML elements come with semantics, and browsers can do all kinds of smart things with them. Some examples:

With existing HTML elements, the browser takes care of a lot of your accessibility, usability and design.

Custom elements come with responsibility

Contrary to most existing elements, a <custom-element> is much like a <div>: it has no meaning to the browser, so browsers have nothing built-in to deal with it. It doesn’t expose to the accessibility tree, has no usability or default appearance. Indeed, this is what a component creator has to take responsibility for themselves:

For each platform.

The Gold Standard gives a great checklist for making Web Components “to be as predictable, flexible, reliable, and useful as the standard HTML elements”.

To increase a component’s accessibility, one could provide meaning through ARIA roles and properties. Or, if we use native elements within our components, we can have our cake and eat it too: when embedding existing elements, you would inherit their benefits. I have not been able to find a definite resource confirming this can be done.

It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

To provide usability, you would have to provide ways to interact with your element for whichever method your user chooses (or is forced to use by personal or indeed corporate circumstances). This is hard, because in most cases, as a website, you do not know a lot about the circumstances under which you are accessed. It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

Design means designing for many different contexts: phones, watches, desktops, etc. And there are probably going to be contexts that we currently don’t know of: a future fridge with a web browser will probably know how to most suitably render a <select>, but it will not know how to deal with your <custom-datepicker>.

Chris Heilmann once said it makes sense to use what already works and build on top of that. I think this applies to custom elements, too. They would only have benefit, if they combine existing elements to bring something we need that does not exist yet.

Does building Web Components sound complex? In the Web Components panel, Google’s Alex Russell noted that “tooling will save you”. Tools can make it much easier to build better Web Components, for example by making them render both on the server and the client for progressive enhancement. But aren’t tools the problem?

Benefits of Web Components

Web Components are not just hard to build well, there are also many benefits to using them.

With Web Components, browsers (will) give website owners the power to bring their own elements. This gives a lot of freedom and is a big addition to the web as a platform. It is innovation we should welcome.

Web Components also bring developers the convenience of style/DOM encapsulation: if you work on a custom element’s CSS, you know it is only going to apply to that component.

Thirdly, a Web Component can be very portable: once you have created a <custom-element> and built all its behaviour and style, you can then use it where you like. As Peter Gasston noted in the EdgeConf Slack channel, “[They take] more effort to build, less effort to use”.

A fourth advantage of Web Components is for search engines: they can potentially start recognising widgets if they are used enough throughout the web, which would improve their search result listings.

An additional benefit of Web Components as a project is that it helps find missing platform APIs (a fascinating project by Domenic Denicola).

What kind of custom elements do we need?

In summary, custom elements can be good for the web as a platform, for developers and potentially for users, too. But building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap. So what kind of custom elements do we need?

Building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap

Some say custom elements will be a bit like jQuery plug-ins: you need a carousel in your page, but instead of building it yourself, you peruse a third party carousel. You want your content to appear in tabs, so you go and use a third party tabs script. Instead of borrowing someone’s CSS and JS, you borrow their <fancy-carousel> or their <the-ultimate-awesome-tabs>, which have their styles and scripts nicely hidden inside their Shadow DOM. We should take care choosing only properly built ones. Also, we should be careful not to repeat the “just another plugin doing $x” mistakes.

I have the feeling that custom elements make most sense for huge companies that have many different websites and apps that have or should have shared elements. Google, who came up with Web Components, have a search engine, maps, Word processing tools, online storage, a social network, an operating system and many other products. It makes lots of sense for them to want to share many of their controls across their products. And they have plenty of designers and developers available to work on the usability, accessibility and design of such components, so it is more feasible for them to do it well (and even they do not have unlimited time and resources).

The same probably goes for big social network enterprises like Twitter and Facebook. They could create things like a Twitter timeline widget for people to embed in their site. Currently, I advise clients against using those, as they come with privacy and performance issues. If offered as a custom element, these issues might still be there, but now buried away in the Shadow DOM. Instead, offering the data as JSON, as Twitter used to do, would probably be more helpful for developers. But I guess that would add less value for Twitter’s shareholders.

Or perhaps media organisations like the BBC. Their video player seems a huge part of what they do, so they might have time to work on a custom element for it, that plays video exactly in the way they need it. For their own site(s), they have many, or perhaps for people to embed elsewhere.

Web Components could also bring a big benefit to people that create ‘apps’, websites where people go to do stuff, or maybe even games. They might need very specific controls, that do not exist in browsers yet.

How about smaller sites?

I’m not sure about the use case for smaller websites. One of the messages of Web Components seems to be that we can soon control style and behaviour of all the elements. But that’s not the full story: it is also very hard to do it well. I am afraid we will end up with lots of badly built components, if we do not tell the full story. What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard? Should we instead trust the capabilities of larger, Bootstrap-like projects, and use their components?

What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard?

Some have suggested Bootstrap and Foundation should start converting their components into Web Components, but I fail to see how that would solve a problem people actually have. It would be interesting to do it as a research type of thing, but to make them the main way to use Bootstrap or Foundation components just feels wrong.

I’m not convinced either, that every company should come up with custom elements for all the things, just because they can. Most elements can be built very well with existing HTML, without costing as much design and development time. I feel many web projects will hardly have a use case for utilising custom elements, or the budget for creating them. They would overcomplicate things. It still feels like eating a 5 course dinner when all you wanted was a salad.

I hope Web Components will get used by those companies that have genuine use cases for which the current set of HTML elements cannot provide. That will help push the web forward, and potentially add new ways of interacting with the platform. We are given the chance to add new elements, before WHATWG, W3C or browser vendors have the time to do so. Or the chance to create elements that would not be suitable to be part of the web standards, yet very useful to one organisation’s strategy. But before that can happen, what we need most is agreement amongst browser vendors.

So, what kind of Web Components do we need? Well-thought-through additions to the existing set of HTML elements, solving problems that aren’t solved by existing elements: yes, please. Many variations on improvements of existing elements like checkboxes and selects? As far as I am concerned, probably not. New elements built without considering accessibility or the huge diversity of browsing contexts? No, thanks.

Update 03/07/2015: Peter Gasston points out on Twitter that a lot of potential value is in the use cases we haven’t thought of yet. This is probably true, I may have to adjust my view when such cases arrive.

Comments & mentions (5)

iamkeir 05 Jul 2015 09:47:40

Long live the div :)

Johan Ronsse 16 Jul 2015 11:05:35

I read this while on holiday so I didn’t have time then to put a proper comment.

This is based on my knowledge of web components from Google I/O in 2014 so if anything major changed in this time my comment might be off.

The way I think about web components is that they allow you to rebuild the standard UI library according to your wishes, in a more neat and structured way than before.

Imagine you are Apple and you are building Pages and Numbers for the web as part of the iCloud suite. There is a switch somewhere and you can call it “apple-switch” or “a-switch” (the <a-switch> element).

You prefix all your elements with the name name and it makes team communication much easier. So imagine there is a bug in a project with the on-off switch. The fact that your “thing” (the switch) is a separate thing (component) is inherently powerful.

You can talk about A-switch version 1.2 instead of <div class=“a-switch”></div> that ties to a Javascript file where it gets mentioned that it’s version 1.2.

In theory you could do all of this with standard HTML elements. But that is not entirely true; because with web components you can choose which attributes are accessible to end-users (custom attributes on your element) and which part of the CSS is encapsulated and which part is not.

The problem as mentioned in this blog post is that the standard UI library (what I mean by this are the standardized HTML form element) do way more than most people think. For example a select element allows you to select an option in the list by typing the first letter. For example you can get to “Carribean” in a list of countries by typing “c” followed by “a”. This is a tried and tested Apple implementation that has worked for years that doesn’t easily get rebuilt using a bit of Javascript. The same thing works in Windows, well at least Windows before Windows 10, because the last time I tested it they forgot to implement that – I should probably file a bug.

Now, even if you get a nice implementation going, it doesn’t have the built-in accessibility that the other elements have, nor can you trigger specific UI for mobile in a way that a select element can.

Like you mention in your blog post, building custom elements that are good is going to be hard, and having them to be accessible is going to be even harder.

But I think it’s entirely possible that people come up with great things that can replace the current juggling of poorly organized Javascript. Is a website including jQuery datepicker and select2 and a random carousel really such a good idea? Is it not nicer to get things from the same web component library that utilizes the same functions? The way Google is presenting Material design as a way of downloadable components is a prime example of this.

One of the disadvantages of web technology is if you have to rebuild functionality thate exists natively, you are also sending this data over the wire. So depending on what you are doing it might make more sense to re-use an existing HTML element than sending costly bytes re-implementing things that already exist.

What I think about when I think about web components are things like datepickers, datepickers with multiple months (common on travel websites), time pickers, color pickers, select elements with input functions (select2), autocomplete dropdowns (like Twitter’s typeahead.js), categorized autocompletes, …

In my ideal world a web component family of controls solves the problems we have with customizing form elements. This family of controls can then be made skinnable by exposing certain properties to the DOM. It would be the example for a native implementation.

Something like Material design but without the download cost. But maybe I’m dreaming :)

Hidde 16 Jul 2015 15:06:15

@Johan: thanks for your comment!

I agree with your point about how a web component potentially becomes a ‘thing’ rather than a somewhat arbitrary set of bits of mark-up, script and stylesheet. However, in a current project, I’m building a component library where each component has its own folder, and its own CSS and JS. They end up concatenated, but in development they are separated out. In the pattern library that is generated from it, they have their own page. This still makes it somewhat possible to see a component as a ‘thing’, although technically, in this setup the connection between markup/script/style is arbitrary.

The kind of things you think about for web components, are pretty much the kind of things I had in mind. The elements you think of, are also most in need of customisation. The standard browser date pickers just don’t look very appealing… :-)

But assuming they would be the first things people start to webcomponentise, for these sorts of elements, I’d be afraid they would come with less built-in awesomeness than native elements do (as in your Caribean example). I would also think they have less chance of adapting to new devices/browsers, because such devices/browsers know what a select is, but not what a <a-select> is. Diverting a bit, in this case, Apple Safari might know what <a-select> is, as it is a component they came up with, but Microsoft Edge would not. Your <a-select> might be recognised and extended to be extra useful on Apple’s new product, but not on Microsoft’s.

Anyway, like you, I am curious what the future will bring, and look forward to seeing some great examples for Web Components in the wild!

ant likes this
David Hund ✌ replied: Good points Jasper & Hidde. We're probably mostly on the same page here
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.