Web Components: What are web components?

Web Components are a set of technologies that allow developers to create custom tags for their web projects. The technologies that make up web components are:

  • Custom Elements allows you to create custom tags for your project-specific needs. These can be brand new tags like book-index or extensions of existing elements with added UI or functionality (super-button or footnote-link)
  • HTML Templates defines a template for your new element. These templates are inert until you instantiate your elements in your page
  • Shadow DOM encapsulates CSS to your custom element. This makes the styles in your components independent of your main document. It has proved to be one of the most problematic aspects of web components but I still think that it’s the most useful… if it wasn’t then browser vendors wouldn’t use it in sliders and video elements
  • HTML Imports extends the link element that we use to import CSS style sheets to import web components stored in an HTML element using a similar syntax like so: <link rel="import" href="/path/to/some/import.html"/>

By themselves each standard under the umbrella of web components is awesome but it’s the combination of these technologies that has really deep implications for web developers everywhere.

The first way to build web components is to use the bare specifications: custom elements, templates, HTML imports and shadow DOM. This is the most direct yet most complex way to build components. Both X-Tags and Polymer abstract the complexities from the specifications as we’ll see below. For more information on web components check the Introduction to Web Components from the S3C

X-Tags provides a partial implementation of web components. Mozilla believes that ES6 modules will be a better solution than HTML imports for the same task. See https://developer.mozilla.org/en-US/Apps/Tools_and_frameworks/Web_components for more information on X-Tags (the library) and Bricks (the components built with X-Tags)

Polymer provides the basics of web components and opinionated sugar on top of web components to make building applications easier.

One thing to note is that, if you’ve worked with Polymer before 1.0, Polymer has changed considerably from prior versions. See the 1.0 release blog post for more information about changes and how to get started and Road to Polymer for ideas and processes on upgrading existing Polymer apps.

Web Components: Why? How? What? When? Where?

Now that Polymer has reached 1.0 and that browser vendors are talking about web components, it is time to revisit web components with a more critical eye and ask the following questions:

  • What are web components?
  • Why use web components? Why not?
  • How to use web components?
  • Where to use web components?
  • How to build web components?
  • Should we use web components now?

We will discuss 3 web component implementations:

  • Vanilla web components built by hand using only HTML, CSS and Javascript
  • Mozilla’s x-tags
  • Google’s Polymer project

In order to make web components work on all modern browsers we must rely, to some degree, in a set of web components polyfill libraries to make sure that the components will work as intended. The only browser to fully support web components is Chrome (as of version 36.) The polyfill is smart enough to know when to let the native systems take over and, if you’re not convinced, there are ways to conditionally load the polyfill only if the elements you need are not supported.

With all that out of the way, let’s dive to web components.

One Final Thing

One final thing

For those of us who have been playing in/with ‘the web’ for 10 years or longer remember pages like the ones in the figures below. There was no Javascript and, I believe, the original CSS specification was released in 1996 so there was no CSS to play with.

Netscape 0.9
Netscape 0.9
Wikipedia in Netscape 1.22
WIkipedia in Netscape 1.22
Hyperreal.org circa 1996 (via Internet Archive}
Hyperreal.org circa 1996 (via Internet Archive}

Why do I bring this up? Because we’ve gotten spoiled by riches. We talk about critical rendering path, page load and web typography and that’s good. But we forget that what may be an acceptable page load in Mountain View, California may not be acceptable in Thailand where the dominant form of Internet access is the mobile smart phone (Tech Wire Asia).

As Eric Meyer reminds us the web is more than just JavaScript, CSS and the latest and greatest Framework, API or micro service. We need to make sure that the content is accessible whether we have CSS and JavaScript enabled or whether they are in a broadband Gigabit connection or in a very slow dial-up connection in Africa or India or for people using assistive technology devices.

This Web App Best Viewed By Someone Else – Eric Meyer keynote at Fluent 2015

As content developers we need to continually ask ourselves what would happen if we can’t download the CSS or if the user has JavaScript disabled. We need to make this a part of our testing and development process.

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

Derek Featherstone

Test the hell out of everything

Testing on web applications is usually a pain and testing for our typographical work is no exception. We’ll discuss how to build a cross-platform arsenal with a single laptop, Open box and 2 virtual machines and how to use that arsenal to test our content, do screen shots and even start adding ebook apps on all of them. Here we go:

What do we need to test with?

I’m a Mac user so that’s my primary platform for testing and development. In my Mac I have the following browsers and applications:

Desktop

  • Chrome release and Canary The Canary channel has the latest and greatest additions to Chrome and it will not overwrite your standard Chrome installation
  • Firefox release and developer edition
  • Safari comes installed with OS X
  • I used to include Opera as an option but since they moved to WebKit and then to Blink, they are too close to an existing browser to merit download. If you still want it, you can download it directly from Opera

Open box Virtual Machines

I’d rather not have to get a brand new computer to download the browsers

  • Download Virtual Box from its website
  • Microsoft makes virtual machines available for all the versions of IE and Edge in different versions of Windows
  • If you’re planning on working with MS Edge and IE 11 in a windows 10 environment you can join the Windows Insider program and get an ISO image that you can install as a Virtual Machine
  • You can download an ISO of your favorite Linux Distribution (I favor Ubuntu LTS) and install it as a virtual machine. There are also alternative installation methods you can use if the default doesn’t work for you

The Windows virtual machines you get from Microsoft have one version of IE and one version only. I’d always stay with IE 10 on Windows 8.1 in one machine and IE 9 on Windows 7. To the default IE browser you can then add the same browsers as listed under Desktop (if supported by your Linux distribution)

Mobile devices

Most browsers available for mobile devices come bundled with phones and tables which make testing in the actual devices a little more complex. We need the following:

  • Table and/or Phone running Android to run WebView, Chrome, Firefox and, optionally, Opera Mini
  • iPhone/iPod Touch running different versions of iOS (7, 8 and 9) using Safari Mobile. Even though there are

Optional e-readers

Since proofing ebooks usually entails building epub and multiple versions of Kindle format packages they will take a second rung in our testing but you can download apps for the following ebook vendors. Note that the apps do not replace testing the books in the devices themselves because the experience in the apps can be radically different than reading the same book in the devices themselves.

If you can, get at least one iPad (retina would work best), one iPhone, one Android phone and one Android tablet. If you can’t then get the following applications:

  • iBooks is a Mac only application that comes installed in later versions of Yosemite and El Capitan or can be downloaded from the App Store
  • Kindlegen is both a previewer and a generator for Kindle files. It requires Java 6 so it may or may not work on your system
  • Kindle Previewer let’s you preview your content using simulations of multiple Kindle devices
  • Nook
  • Kobo

Actually testing your content

If we’re working with mostly static content then all you need to do is make sure that it looks close to the design brief in all browsers you test with. We are not talking about unit test or Test Driven Development (TDD)

External (paid) services

If you don’t want to bother with installing virtual machines and operating systems that take gigs out of your hard drive you have alternatives. Paid alternatives but alternatives none the less.

Browserstack provides testing support in a comprehensive list of supported browsers and platforms. It is paid but the prices are reasonable for the services it gives you.

Quirktools Screenfly provides a simpler way to test your design on multiple browsers. The price is better (free) but the support doesn’t seem to be as complete as Browserstack’s

Explorations and Experiments

Jen makes a great point on her presentation. Where are the awesome layouts that we see in print reflected on the web? We are not tied into the “rectangular boxes” wisdom of the web anymore. We have technologies like shapes, clip paths, masks and many other technologies that make square boxes almost obsolete.

Don’t get me wrong… rectangles have their place and we shouldn’t make all out content replicas of printed material but, Rather than taking the challenges and opportunities of print as a source of ideas and inspirations we became stuck in the Holy Grail layout (and we’ll leave aside, for the moment, the fact that the Holy Grail Layout only became practical with the advent of CSS Flexbox as explained by Philip Walton.)

So what happens when you stop thinking about rectangular, Holy Grail style, layouts? You can start thinking of layouts like those on magazines and start really pushing the envelope with technologies like WebGL, D3, CSS Blends, transitions and animations and all the technologies that we have available on the web stack.

We can also avoid pitfalls likes the ones in the Noise versus Noise Flickr set where the creator has attempted to identify the actual content of websites in the midst of ads and other irrelevant content.

Lea Verou‘s CSS Secrets is another good source of inspiration for CSS and how far to push the technologies. The book is based on two of her presentations: CSS3 secrets: 10 things you might not know about CSS3 and More CSS Secrets: Another 10 things you may not know about CSS and it provides crazy ways to use what we’re already familiar in CSS.

Why can’t it look like print? Why should it look like print?

One example of pushing the web: non-linear narratives

But it’s not just whether we move the words around the box or the the boxes around the screen. It’s also the way we incorporate web technologies (typography, new web APIs, new semantic HTML5 tags) into our written content to create more engaging user experiences and the way in which we interact with the content on screen across a variety of devices and form factors.

For the longest time we’ve been told that ‘the web is not print’ and we grew into holy grail layouts. A fair question would be to ask what’s next. How can we push the boundaries of the web even further without loosing sight of accessibility and universal access?

Some examples that show how much and how far we can use web technologies are:

How tos and tutorials