Don’t expect a visionary article on the future of the web. I’ve only been trying to understand some novelties, and here are some reflections, so bear on…

What are Web Components? They’re defined as encapsulated and interoperable custom elements that extend HTML itself. Boils down to: you define a custom HTML tag <my-blinky-winky-button> that contains custom markup (HTML), custom style (CSS) and custom behaviour (JavaScript), and you import the new tag in your HTML code and use it as if it were a built-in HTML tag.

Collect a number of such Web Components, and you have a web components boilerplate. Google Polymer and Mozilla Brick do this. Google is keen on making Polymer the platform to design and build web apps that implement their own design spec called Material Design.

Why is it called “Material Design”? At first, you’d think that Google just wants to provide an answer to Apple’s (ditched) skeuomorphism, replacing the wooden shelves and metal buttons by a cheaper material: paper. Or thinking further, that Material Design is about defining HTML elements or ‘web components’ that live beyond their appearance on the screen, just like the notes that you organize on your desk. Or is there even more to it?

Let’s have a break and hear a joke. HTML 5 was told to bring ‘semantic’ tags, that are meant to give the markup a meaning. If I look through the list of new elements, the only semantic elements are <time>, <meter> and <progress>, because they mean something in real world. All the other new tags are just specialized layout elements. I agree that <header> means more than <div>, but that doesn’t make it a semantic tag. And saying that <strong> means more than <b>, well that’s a good laugh…

So at first you’d think that Web Components are just a means to define even more specialized layout elements, linked to a rendering that mimics paper? And yes, so they are!

But potentially Web Components can be designed to be genuine semantic tags. If you define tags like <book>, <friend>, <recipe>, <photograph> or <quote>, they could become part of a website and be reusable and really mean something. Some of this is already done through microformats, which are special attributes added to HTML elements to indicate meaning. And part of it is indeed merging into HTML 5.

So the only thing that we need now, is another Web Components boilerplate that doesn’t focus on layout stuff (titles, lists, buttons and the like), but that provides components representing meaningful concepts. These components integrate layout, so lazy me can write some HTML code that looks like this:

<book author="x" title="y" isbn="abc" publisher="z" cover="pic.png" store="amazon">

and without any further markup, styles or scripting, the browser would render a suitable and responsive representation of all the attributes. And why shouldn’t these components be smart enough to respond to context? Just like ‘responsive’ now means that layout reacts to display width, semantic responsiveness could mean that layout of web components is left to the browser and/or boilerplate completely. Take the <book> example. If the element is part of inline content, it will render as plain text, and if the element is part of block content, it will render as a thumbnail together with the attributes, depending on the width and height applied.

But let’s not get carried away… websites are communication, and communication is words and words become text and as long as text is involved, the most important part of a semantic website will need titles and paragraphs and a decent overall layout that doesn’t step in the way of the real semantics: valuable content, stored in written text.