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
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.
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.
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).
This Web App Best Viewed By Someone Else – Eric Meyer keynote at Fluent 2015
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.
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:
Chrome release and Canary The Canary channel has the latest and greatest additions to Chrome and it will not overwrite your standard Chrome installation
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
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)
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
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
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.
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.
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: