Over the Edge: Web Components are an endangered species

Last week I ran the panel and the web components/modules breakout session of the excellent Edge Conference in London, England and I think I did quite a terrible job. The reason was that the topic is too large and too fragmented and broken to be taken on as a bundle.

If you want to see the mess that is the standardisation effort around web components right now in all its ugliness, Wilson Page wrote a great post on that on Mozilla Hacks. Make sure to also read the comments – lots of good stuff there.

Web Components are a great idea. Modules are a great idea. Together, they bring us hours and hours of fun debating where what should be done to create a well-performing, easy to maintain and all around extensible complex app for the web. Along the way we can throw around lots of tools and ideas like NPM and ES6 imports or – as Alex Russell said it on the panel: “tooling will save you”.

It does. But that was always the case. When browsers didn’t support CSS, we had Dreamweaver to create horribly nested tables that achieved the same effect. There is always a way to make browsers do what we want them to do. In the past, we did a lot of convoluted things client-side with libraries. With the advent of node and others we now have even more environments to innovate and release “not for production ready” impressive and clever solutions.

When it comes to componentising the web, the rabbit hole is deep and also a maze. Many developers don’t have time to even start digging and use libraries like Polymer or React instead and call it a day and that the “de facto standard” (a term that makes my toenails crawl up – layout tables were a “de facto standard”, so was Flash video).

React did a genius thing: by virtualising the DOM, it avoided a lot of the problems with browsers. But it also means that you forfeit all the good things the DOM gives you in terms of accessibility and semantics/declarative code. It simply is easier to write a <super-button> than to create a fragment for it or write it in JavaScript.

Of course, either are easy for us clever and amazing developers, but the fact is that the web is not for developers. It is a publishing platform, and we are moving away from that concept at a ridiculous pace.

And whilst React gives us all the goodness of Web Components now, it is also a library by a commercial company. That it is open source, doesn’t make much of a difference. YUI showed that a truckload of innovation can go into “maintenance mode” very quickly when a company’s direction changes. I have high hopes for React, but I am also worried about dependencies on a single company.

Let’s rewind and talk about Web Components

Let’s do away with modules and imports for now, as I think this is a totally different discussion.

I always loved the idea of Web Components – allowing me to write widgets in the browser that work with it rather than against it is an incredible idea. Years of widget frameworks trying to get the correct performance out of a browser whilst empowering maintainers would come to a fruitful climax. Yes, please, give me a way to write my own controls, inherit from existing ones and share my independent components with other developers.

However, in four years, we haven’t got much to show.. When we asked the very captive and elite audience of EdgeConf about Web Components, nobody raised their hand that they are using them in real products. People either used React or Polymer as there is still no way to use Web Components in production otherwise. When we tried to find examples in the wild, the meager harvest was GitHub’s time element. I do hope that this was not all we wrote and many a company is ready to go with Web Components. But most discussions I had ended up the same way: people are interested, tried them out once and had to bail out because of lack of browser support.

Web Components are a chicken and egg problem where we are currently trying to define the chicken and have many a different idea what an egg could be. Meanwhile, people go to chicken-meat based fast food places to get quick results. And others increasingly mention that we should hide the chicken and just give people the eggs leaving the chicken farming to those who also know how to build a hen-house. OK, I might have taken that metaphor a bit far.

We all agreed that XHTML2 sucked, was overly complicated, and defined without the input of web developers. I get the weird feeling that Web Components and modules are going in the same direction.

In 2012 I wrote a longer post as an immediate response to Google’s big announcement of the foundation of the web platform following Alex Russel’s presentation at Fronteers 11 showing off what Web Components could do. In it I kind of lamented the lack of clean web code and the focus on developer convenience over clarity. Last year, I listed a few dangers of web components. Today, I am not too proud to admit that I lost sight of what is going on. And I am not alone. As Wilson’s post on Mozilla Hacks shows, the current state is messy to say the least.

We need to enable web developers to use “vanilla” web components

What we need is a base to start from. In the browser and in a browser that users have and doesn’t ask them to turn on a flag. Without that, Web Components are doomed to become a “too complex” standard that nobody implements but instead relies on libraries.

During the breakout session, one of the interesting proposals was to turn Bootstrap components into web components and start with that. Tread the cowpath of what people use and make it available to see how it performs.

Of course, this is a big gamble and it means consensus across browser makers. But we had that with HTML5. Maybe there is a chance for harmony amongst competitors for the sake of an extensible and modularised web that is not dependent on ES6 availability across browsers. We’re probably better off with implementing one sci-fi idea at a time.

I wished I could be more excited or positive about this. But it left me with a sour taste in my mouth to see that EdgeConf, that hot-house of web innovation and think-tank of many very intelligent people were as confused as I was.

I’d love to see a “let’s turn it on and see what happens” instead of “but, wait, this could happen”. Of course, it isn’t that simple – and the Mozilla Hacks post explains this well – but a boy can dream, right? Remember when using HTML5 video was just a dream?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Endangered species of the web: the image

Once the Web was a thriving ecosystem of happily evolving, beautiful creatures. Like with any environment, sooner or later man will step in and kill a lot of things – actively or by accident – and diminish the diversity and health of said ecosystem. In this series we will look at some of the strange animals that make up the Web as we know it, re-introduce them and show how you can do your part to make sure they don’t die out.

Today we are looking at an amazingly popular pet animal that is more than often treated not the way it is meant to be treated: the image.

JAXPORT Gallery: Artist Keith Doles

Show me your colours

Images are what made the web pop. Ever since the first browser started supporting them, we had a web that was interesting to publishers beyond the academic community. Show me, don’t tell me, and all that. At the start, things were pretty clear cut:

When Marc Andreesen proposed the IMG tag in 1993 he defined it as thus:

This names a bitmap or pixmap file for the browser to attempt to pull over the network and interpret as an image, to be embedded in the text at the point of the tag’s occurrence.

He also defined what should be done when the image can not be loaded (and also mentioned now very obscure image formats as ones that could be used):

Browsers should be afforded flexibility as to which image formats they support. Xbm and Xpm are good ones to support, for example. If a browser cannot interpret a given format, it can do whatever it wants instead (X Mosaic will pop up a default bitmap as a placeholder).

Simply put, this is what you needed to do in order to add an image of a canyon to the document:

<img src="canyon.png">

This was when things got wrong: what happens when the image could not be loaded or shown? Show a placeholder. But the placeholder has no meaning, right? All you tell is the end user that something went wrong. Not what the meaning of the image was.

The Object element came later and already explained a few of the shortcomings of the original idea:

Previous versions of HTML allowed authors to include images (via IMG) and applets (via APPLET). These elements have several limitations:

  • They fail to solve the more general problem of how to include new and future media types.
  • The APPLET element only works with Java-based applets. This element is deprecated in favor of OBJECT.
  • They pose accessibility problems.
<object data="canyon.png" type="image/png">
This is a <em>closeup</em> of the Grand Canyon.

The big thing here is that this could be extended to all kind of embeddable media – music, video, applets and whatever might come next. Instead, we got the IMG tag, and then we got the video element, the audio element and the iframe element – each delivering a highly defined subset of what the generic object element could have done.

Despite the shortcomings of the humble img, it has a few amazing attributes that can work for you:

  • alt – the alternative text to give a user agent when the image can not be displayed, which could mean it could not be loaded or that it couldn’t be decoded
  • longdesc – a linked document to explain in much wordier fashion what the image describes. This could be for example a longer description of the data and the findings in the data relationships of a chart. Never heard of that one? Join the club!
  • name – the name of the image used for scripting (only added for backwards compatibility)
  • height and width – to resize images to a certain size or to tell the browser what the size is instead of it having to read that from the image metadata
  • usemap and ismap for client side image maps (those were all the rage before we had CSS and could stack elements on top of another)

In addition to that there is always the title attribute, which can be added to almost anything.

As an image is pointing to an external resource, it also allows you to do a lot with JavaScript. You can detect if it was loaded by subscribing to a load event handler and react if there was a problem by subscribing to its error handler. This gives you quite granular control over what is going on.

Hurting images: misuse of alt and title

Things got weird when people didn’t use images they way they are meant to because of how they display in browsers. The alt attribute (no, there is no such thing as an alt tag) doesn’t get the information it should contain, instead the title attribute gets a lot of information as it is visible when the user hovers over the element.

A great example how to make the image happy is XKCD. Their makers give the image sensible alternative text in the alt attribute and add extra information in the title. They use the title as a sort of “easter egg”, which is totally fine, and works well for them:


<img src="http://imgs.xkcd.com/comics/automation.png" 
title="'Automating' comes from the roots 'auto-' 
meaning 'self-', and 'mating', meaning 'screwing'." 

Of course, to be totally accessible, this image should have a longdesc attribute pointing to a textual representation of the image’s message. This could also be the alternative text, but might be a bit long as there is not only a text displayed in the image to be explained, but also its implications and nuances. If that needs to be done, you could also use a FIGURE and FIGCAPTION construct. HTML5Doctor has an amazingly detailed, yet easy to understand post on those.

Back to alt and title: title should always be treated as a “nice to have” and can not be relied on to ever be accessible to the end user. Alt, on the other hand, is absolutely and utterly needed. If the image for one reason or another can not be displayed (which is totally possible) it is what the user gets. In Firefox and Chrome, for example, instead of the image you only get the text displayed in the browser:

Merry hedgehogs frolicking in the moonlight

Alternative text is most important for non-sighted users, as screenreaders will announce that text in their stead. If there is no alternative text specified, assistive technology might fall back to reading out the file name, which could be an exercise in annoyance and futility in equal measures.

Images getting a bad reputation: performance

Images lately got a bit of a bad reputation, as they’ve been singled out as a huge source of performance issues with web pages. This is true: the more images you use in your document, the more HTTP negotiation has to happen and the more external files have to be loaded, decoded and displayed. The first big solution came as early as 2004, when Dave Shea coined the term and explained the techniques behind “Image Sprites”. Image sprites were the fabulous idea of using a single image with all the images on the page in one document. Thus, you only load and decode one image and crop and position it visually with CSS in all the different places you need it. The drawback of this technique as described by Dave is that you have no textual fallback – no alt attribute – but that can be remedied as I explained in a comment on the original article using image replacement techniques.

Other problems that occurred in the past (and maybe even now) are that images seem to do a bad job when used in mobile devices. The mobile version of Flickr, for example, used to be much slower when using img elements instead of background images on DIVs, as decribed in the “Creating Responsive HTML5 Touch Interfaces” talk from 2 years ago.

Throwing images out and moving it all to CSS

Nowadays, we can do magic in CSS. We really can. Gradients, drop shadows, rounded corners, background sizing, all the good things we have make creating images for purely artistic parts of our designs (“screen furniture”) utterly unnecessary and give us much more flexibility. A gradient in CSS can clearly resize to any element, a gradient in PNG or JPG would wash out or pixel out.

No argument there. However, lately a lot of showcases use CSS to paint, which, if only a visual aid, is totally fine. Images that are semantically valuable though should not be achieved that way but instead should be an img, for the reasons mentioned before – you can create a textual fallback that will be shown when things go wrong and you can even react when the image was unable to load or decode (using the load and error handlers). Neither is possible in CSS, all you can do is hope that everything is alright. Most browsers will be OK hiding a text in an element you use CSS to style, but not all are able to render the final visual construct you create with lots of CSS instructions. Thus, if things go wrong, you give the user nothing instead of a text to understand.

In other words: while it is possible to create a MacBook using only CSS from one element, you have no idea if it displays correctly. If it is a nice-to-have, all fine. If that MacBook were the logo of your company or a chart explaining information to your readers – bad idea. Painting complex images in CSS using lots and lots of DIVs and SPANs is a parlour trick – it is neither reliable across browsers, backwards compatible nor makes any sense semantically. An image is more than a visual construct – it also gives meaning and you should provide a way to make that meaning obvious when the image can not be seen or is displayed wrongly. That images “painted with HTML and CSS” scale nicely on different resolutions is a problem we need to solve on an image format level (SVG comes to mind), not something we should hack together by abusing HTML for the sake of its visual outcome. We stopped painting with table cells – remember, we did tables with background colours on 1 pixel wide or high rows and columns to create borders – we should not go back to these days.

How to treat images humanely

The technology we have these days allows us to use images in amazing ways. It is up to you to use it wisely:

  • If the image is purely there to be pretty, use a CSS background and benefit from the resizing and positioning options you have. Make sure to use a fallback background colour with enough contrast to the text colour in case the image could not be loaded.
  • If the image is there to be part of a visual design and needs to scale consider using gradients, rounded corners and drop shadows in CSS instead. Be aware though that these could be bad when moving the element or scrolling the page so use them sparingly.
  • If the image plays an important role to the message of the document, or represents an interactive element like a button, use an img tag. These allow for alternative texts and error handling much easier than CSS solutions do. If you use an img give it a sensible alternative text, do not omit the alt attribute or give it an empty attribute or [image].

Not that hard, now is it? Make those images dance and sparkle, I dare you!

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Endangered species of the Web: the Link

Once the Web was a thriving ecosystem of happily evolving, beautiful creatures. Like with any environment, sooner or later man will step in and kill a lot of things – actively or by accident – and diminish the diversity and health of said ecosystem.

In this series we will look at some of the strange animals that make up the Web as we know it, re-introduce them and show how you can do your part to make sure they don’t die out.

We start with the most important part of the Web: the Link.

not the weakest link
A Link is what makes the web, well, the web. It is an address where you can access a certain resource. This could be an HTML document (another animal we’ll cover soon), a video, an image, a text file, a server-side script that does things like sending an email – anything really.

In order to make links work two things are needed: a working end point where the Link should point to (URL or URI – for the difference meet a few people who have too much time and not enough social interactions in their lives and discuss) and an interaction that makes a user agent try to fetch the Link. That could be a user typing the URL in an address bar of a browser, a cURL request on a command line or an HTML element pointing to the URL.

Links are kind of magical, insofar that they allow anyone to have a voice and be found. Check Paul Neave’s “Why I create for the web” to read a heartfelt ode to the Link. And it is true; once you managed to publish something at a URL all kind of wonderful things can happen:

  • People can go there directly
  • Search engines can index it so people can find it searching for similar terms
  • Consumers can get the content you published without having to identify themselves and enter their credit card details (like they have to in almost any App Marketplace)
  • Consumers can keep the URL for later and share it with others, thus advertising for you without being paid for it
  • And much more…

It is the most simple and most effective world-wide, open and free publishing mechanism. That it is why we need to protect them from extinction.

In HTML, the absolutely best animal to use to make it easy for someone to access a URL is an anchor element or A. But of course there are other elements – in essence anything with an href or src attribute is a link out to the Web.

Endangering the interaction part

There are may ways people kill or endanger Links these days. The biggest one is people not using real links and yet expect Web interaction to happen. You can see anchor elements with href attributes of “javascript:void(0)” or “#” and script functionality applied to them (using event handling) to make them load content from the web or point to another resource. Ajax was the big new shiny thing there that made this the practice du jour and so much better than that awful loading of whole documents.

This is not the Web and it will hurt you. In essence these people do something very simple very wrong and then try to cover their tracks by still using anchor elements. Of course you can glue wings on a dog, but you shouldn’t expect it to be able to fly without a lot of assistance afterwards. There is no need for not pointing your anchors to a real, existing URL. If you do that, anything can go wrong and your functionality will still be OK – the person who activated the link will still get to the resource. Of course, that only works if that resource exists where you point to, which does lead to the second problem we have with Links these days.

Cool URLs don’t mutate

The practice of creating script-dependent links has also lead to another mutation of the link which turned out to be a terrible idea: the hashbang URL. This Frankenstein URL used fragment identifiers acting as Web resources, which they are not (try to do a meta refresh to a fragment if you doubt me). Luckily for us, we have the history API in browsers now which means we don’t need to rely on hashbang URLs for single page applications and we can very much redirect real, valid URLs on the server to their intended resource.

The second, big player in the endangerment of the Link is them dying or mutating. One of the traditional ways of dealing with Links to make them happy is to herd them in enclosures like “bookmarks” or “blog posts” or “articles” where you can group them with like-minded Links and even feed them with “tags” and “descriptions”, yummy things Links really love to chew on. Especially the “description” helps a lot – imagine giving a user a hint of what the anchor they click on will take them to. Sounds good, doesn’t it? People would only call those Links they want to play with and not make them run around without really caring for them.

Catch me if you can?

Talking about running around: social media is killing a lot of Links these days using an evil practice called “shortlinking”. Instead of sending the real URL to people to click on or remember we give them a much shorter version, which – though probably easier to remember – is flaky at best.

Every jump from URL to URL until we reach the endpoint we actually wanted to go to is slowing down our web interactions and is a possible point of failure. Try surfing the web on a slow connection that struggles with DNS lookups and you see what I mean.

Instead of herding the real Links and feeding them descriptions and tags we add hashtags to a URL that might or might not redirect to another. Bookmarks, emails and messages do not contain the real endpoint, but one pointing to it, possibly via another one. It is a big game of Chinese Whispers on a DNS lookup and HTTP redirect level.

In essence, there is a lot of hopping around the web happening that doesn’t benefit anyone – neither the end user who clicked on a link nor the maintainer or the resource as their referrers get all messed up. Twitter does not count the full length of the URL any longer but only uses 19 characters for any URL in a tweet (as it uses a t.co redirect under the hood to filter malicious links) thus using URL shorteners in Tweets is a pointless extra.

How can you help to save the Links?

Ensuring the survival of the Link is pretty easy, all you need to do is treat it with respect and make sure it can be found online rather than being disguised behind lots of mock-Links and relying on a special habitat like the flawless execution of scripts.

  • If what you put inside a href attribute doesn’t do anything when you copy and paste it into a browser URL field, you’ve killed a Link
  • If you post a URL that only redirects to another URL to save some characters, you killed a Link

You can do some very simple steps to ensure the survival of Links though:

  • If you read a short article talking about a resource that has a “/via” link, follow all the “via”s and then post the final, real resource in your social media channels (I covered this some time ago in “That /via nonsense (and putting text in images)“)
  • Tell everybody about server-side redirects, the history API and that hashbangs will not bring them any joy but are a very short-lived hack
  • Do not use social media sharing buttons. Copy and paste the URL instead. A lot of these add yet another shorturl for tracking purposes (btw, you can use the one here, it uses the real URL – damn you almost got to say “isn’t it ironic, that…” and no, it isn’t)
  • Read up on what humble elements like A, META and LINK can do
  • If you want to interact with scripts and never ever point to a URL, use a BUTTON element – or create the anchor using JavaScript to prevent it from ever showing up when it can’t be used.

Please help us let the Links stay alive and frolic in the wild. It is beautiful sight to behold.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)