What kind of Web Components do we need?

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:

• The <select> element lets a user pick one option from a list of options. Every browser can decide how to represent this best. My phone shows a fruit machine style thingy, an old-fashioned Windows style selector is shown on old Windows machines, and easy to recognise for users of such machines. A future version of Siri may be able to talk us through the options, in fact, some assistive technology already does this.
• The <video> element lets a developer point to a video, or indeed a couple of videos in different formats. The problem of how to play the video is then solved by the browser. Each browser chooses the best video player it can offer, and lets the user watch the video in it.

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:

• accessibility / semantics
• usability
• what it looks like

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.