One of the things I always liked about Firefox is that you can right-click any canvas and select “save image as”. Chrome and others don’t do that (well, Chrome doesn’t). Instead you need to get the image data, create a url and open a new tab or something in that order.

One very simple way to allow people to save a canvas as an image (and name it differently – which would have to be done by hand in the case of right-clicking on Firefox) is to use the download attribute of a link.

You can see this in action in this JSFiddle. Simply paint something and click the “download image” link.

The relevant code is short and sweet (canvas is the reference of the canvas element):

var link = document.createElement('a');
link.innerHTML = 'download image';
link.addEventListener('click', function(ev) {
    link.href = canvas.toDataURL();
    link.download = "mypainting.png";
}, false);
document.body.appendChild(link);

Legos by C Slack

Web Components are a hot topic now. Creating widgets on the web that are part of the browser’s rendering flow is amazing. So is inheriting from and enhancing existing ones. Don’t like how a SELECT looks or works? Get it and override what you don’t like. With the web consumed on mobile devices performance is the main goal. Anything we can do to save on battery consumption and to keep interfaces responsive without being sluggish is a good thing to do.

Web Components are a natural evolution of HTML. HTML is too basic to allow us to create App interfaces. When we defined HTML5 we missed the opportunity to create semantic widgets existing in other UI libraries. Instead of looking at the class names people used in HTML, it might have been more prudent to look at what other RIA environments did. We limited the scope of new elements to what people already hacked together using JS and the DOM. Instead we should have aimed for parity with richer environments or desktop apps. But hey, hindsight is easy.

What I am more worried about right now is that there is a high chance that we could mess up Web Components. It is important for every web developer to speak up now and talk to the people who build browsers. We need to make this happen in a way our end users benefit from Web Components the best. We need to ensure that we focus our excitement on the long-term goal of Web Components. Not on how to use them right now when the platforms they run on aren’t quite ready yet.

What are the chances to mess up? There are a few. From what I gathered at several events and from various talks I see the following dangers:

• One browser solutions
• Dependency on filler libraries
• Creating inaccessible solutions
• Hiding complex and inadequate solutions behind an element
• Repeating the “just another plugin doing $x” mistakes

One browser solutions

This should be pretty obvious: things that only work in one browser are only good for that browser. They can only be used when this browser is the only one available in that environment. There is nothing wrong with pursuing this as a tech company. Apple shows that when you control the software and the environment you can create superb products people love. It is, however, a loss for the web as a whole as we just can not force people to have a certain browser or environment. This is against the whole concept of the web. Luckily enough, different browsers support Web Components (granted at various levels of support). We should be diligent about asking for this to go on and go further. We need this, and a great concept like Web Components shouldn’t be reliant on one company supporting them. A lot of other web innovation that heralded as a great solution for everything went away quickly when only one browser supported it. Shared technology is safer technology. Whilst it is true that more people having a stake in something makes it harder to deliver, it also means more eyeballs to predict issues. Overall, sharing efforts prevents an open technology to be a vehicle for a certain product.

Dependency on filler libraries

A few years ago we had a great and – at the same time – terrible idea: let’s fix the problems in browsers with JavaScript. Let’s fix the weirdness of the DOM by creating libraries like jQuery, prototype, mootools and others. Let’s fix layout quirks with CSS libraries. Let’s extend the functionality of CSS with preprocessors. Let’s simulate functionality of modern browsers in older browsers with polyfills.

All these aim at a simple goal: gloss over the differences in browsers and allow people to use future technologies right now. This is on the one hand a great concept: it empowers new developers to do things without having to worry about browser issues. It also allows any developer to play with up and coming technology before its release date. This means we can learn from developers what they want and need by monitoring how they implement interfaces.

But we seem to forget that these solutions were build to be stop-gaps and we become reliant on them. Developers don’t want to go back to a standard interface of DOM interaction once they got used to $(). What people don’t use, browser makers can cross off their already full schedules. That’s why a lot of standard proposals and even basic HTML5 features are missing in them. Why put effort into something developers don’t use? We fall into the trap of “this works now, we have this”, which fails to help us once performance becomes an issue. Many jQuery solutions on the desktop fail to perform well on mobile devices. Not because of jQuery itself, but because of how we used it.

Which leads me to Web Components solutions like X-Tags, Polymer and Brick. These are great as they make Web Components available right now and across various browsers. Using them gives us a glimpse of how amazing the future for us is. We need to ensure that we don’t become dependent on them. Instead we need to keep our eye on moving on with implementing the core functionality in browsers. Libraries are tools to get things done now. We should allow them to become redundant.

For now, these frameworks are small, nimble and perform well. That can change as all software tends to grow over time. In an environment strapped for resources like a $25 smartphone or embedded systems in a TV set every byte is a prisoner. Any code that is there to support IE8 is nothing but dead weight.

Creating inaccessible solutions

Let’s face facts: the average web developer is more confused about accessibility than excited by it. There are many reasons for this, none of which worth bringing up here. The fact remains that an inaccessible interface doesn’t help anyone. We tout Flash as being evil as it blocks out people. Yet we build widgets that are not keyboard accessible. We fail to provide proper labeling. We make things too hard to use and expect the steady hand of a brain surgeon as we create tight interaction boundaries. Luckily enough, there is a new excitement about accessibility and Web Components. We have the chance to do something new and do it right this time. This means we should communicate with people of different ability and experts in the field. Let’s not just convert our jQuery plugins to Web Components in verbatim. Let’s start fresh.

Hiding complex and inadequate solutions behind an element

In essence, Web Components allow you to write custom elements that do a lot more than HTML allows you to do now. This is great, as it makes HTML extensible (and not in the weird XHTML2 way). It can also be dangerous, as it is simple to hide a lot of inefficient code in a component, much like any abstraction does. Just because we can make everything into an element now, doesn’t mean we should. What goes into a component should be exceptional code. It should perform exceptionally well and have the least dependencies. Let’s not create lots of great looking components full of great features that under the hood are slow and hard to maintain. Just because you can’t see it doesn’t mean the rules don’t apply.

Repeating the “just another plugin doing $x” mistake

You can create your own carousel using Web Components. That doesn’t mean though that you have to. Chances are that someone already built one and the inheritance model of Web Components allows you to re-use this work. Just take it and tweak it to your personal needs. If you look for jQuery plugins that are image carousels right now you better bring some time. There are a lot out there – in various states of support and maintenance. It is simple to write one, but hard to maintain.

Writing a good widget is much harder than it looks. Let’s not create a lot of components because we can. Instead let’s pool our research and findings and build a few that do the job and override features as needed. Core components will have to change over time to cater for different environmental needs. That can only happen when we have a set of them, tested, proven and well architected.

Summary

I am super excited about this and I can see a bright future for the web ahead. This involves all of us and I would love Flex developers to take a look at what we do here and bring their experience in. We need a rich web, and I don’t see creating DOM based widgets to be the solution for that for much longer with the diversity of devices ahead.

I just got asked why Firefox doesn’t do the same thing as Chrome does when you copy a GIF into a canvas element using drawImage(). The short answer is: Chrome’s behaviour is not according to the spec. Chrome copies the currently visible frame of the GIF whereas Firefox copies the first frame. The latter is consistent with the spec.

You can see the behaviour at this demo page:

Here’s the bug on Firefox and the bug request in Webkit to make it consistent thanks to Peter Kasting there is also a bug filed for Blink.

The only way to make this work across browsers seems to be to convert the GIF into its frames and play them in a canvas, much like jsGIF does.

On Tuesday, Microsoft announced the end of support for Windows XP. For web developers, this meant much rejoicing as we are finally rid of the yoke that is Internet Explorer 6 and can now use all the cool things HTML5, CSS3 and other tech has to offer. Right? Maybe.

When I started web development my first real day-to-day browser was IE4 and then Netscape Navigator Gold moving on to Netscape Communicator 4. I saw the changes of IE5, 5.5 and finally IE6. I was pretty blown away by the abilities IE6 had. You had filters, page transitions, rotation, blurring, animation using marquee and even full-screen applications using the .hta extension. In these applications you had full JScript access to the system, you can read and write files, traverse folders and much more. Small detail: so had attackers as the security model wasn’t the best, but hey, details…

None of this was a standard, and none of it got taken on by other browsers. That probably wasn’t possible as features of browsers were the main differentiator and companies protected their USPs.

IE was never and will never be just a browser: it is an integral part of the operating system itself. For better or worse, Microsoft chose to make the web consumption tool also the file browsing and document display tool. Many of the very – at that time – futuristic features of IE6 were in there as they were needed for Powerpoint-style presentations.

That’s why the end of XP is a light at the end of the tunnel for all those suffering the curse that is IE6. Many users just didn’t bother upgrading their browser as what the OS came with was good enough.

A cracker’s paradise

Of course we now have a security problem: not all XP installs will be replaced and the lack of security patches will result in many a hacked server. Which is scary seeing that many ATMs run on XP and lots of government computers (the UK government alone spent 5.5m GBP on getting extended support for XP as moving on seems to be hard to do with that many machines and that much red tape). XP and IE6 weren’t a nuisance for web developers – they are a real threat to internet security and people’s online identity for a long time now.

The fast innovator in a closed environment dilemma

You can say what you want about IE6 - and it has been a running joke for a long time – having it and having it as the nemesis of web standards based browsers (Opera, Netscape6 and subsequently Firefox) taught us a lot. Having a browser that dared to dabble with applications in HTML years before the W3C widget spec or Adobe Air was interesting. Having a browser in the operating system that naturally was the first thing people clicked to go online helped the internet’s popularity. It didn’t help the internet as a whole though.

The big issue of course was that people didn’t upgrade and the OS didn’t force-upgrade the browser. This meant that companies had a fixed goal to train people on: if it works in IE6, it is good enough for us. That’s why we have hundreds of large systems that only work in IE. Many of those are enterprise systems: CRM, Asset management, Ticketing, CMS, Document management – all these fun things with lots of menus and trees and forms with lots of rules.

Nobody likes using these things. People don’t care for them, they just see them as a necessary thing to do their job and something created by magical hairy pixies called the IT department. When you don’t like something but need to use it any change in it is scary, which is why a lot of attempts to replace these systems with more user-friendly and cross-platform systems is met with murmurings or open revolt. I call this the Stockholm syndrome of interfaces: I suffered it for years, so I must like it, right? All the other stuff means more work.

Back to the browser thing though: The issue wasn’t IE6, the issues were its ubiquity, an audience that wasn’t quite web savvy yet and didn’t crave choice but instead used what was there, and Microsoft’s tooling centering around creating amazing things for IE first and foremost and maybe a fallback for other browsers. The tools locked into IE6 were most of the time not created by web developers, but by developers of .NET, classic ASP, Sharepoint and many other – great – tools for the job at hand. Everything seemed easy, the tools seemed far superior to those that cover several targets and when you stayed inside the ecosystem, things were a breeze. You didn’t even have to innovate yourself – you just waited until the platform added the next amazing feature as part of the build process (this even happened at awesome events that only cost your employer and means you can get an awesome T-Shirt to boot). Sound eerily familiar to what’s happening now in closed platforms and abstracted developer tools, doesn’t it? Look – it’s the future, now – if you use platform x or browser y.

What should we take away from this?

Which brings me to the learning we should take away from these years of building things for a doomed environment: browsers change, operating systems change, form factors change. What we think is state-of-the-art and the most amazing thing right now will be laughable at best or destructive to innovation at worst just a year ahead.

And it is not Microsoft’s fault alone. Microsoft have seen the folly of their ways (OK, with some lawsuits as extra encouragement) and did a great job telling people to upgrade their systems and stop targeting OldIE. They understand that not every developer uses Windows and made testing with virtualisation much easier. They are also much more open in their messaging about what standards new IE supports. If they understand this, we should, too.

Here are the points we should keep in our heads:

• Bolting a browser into an operating system makes it harder to upgrade it – you see this now in Android stock browsers or iOS. Many of the amazing features of HTML5 need to be poly-filled, not for old IE, but for relatively new browsers that will not get upgraded because the OS can’t get updated (at times on hardware that was $500 just a few months ago)
• Building software for the current state of the browser is dangerous – especially when you can’t trust the current state to even be stable. Many solutions relying on the webkit prefix functionality already look as silly as a “if (document.layers || document.all) {}” does.
• Stop pretending you can tell end users what browser to use – this is sheer arrogance. Writing software means dealing with the unknown and preparing for it. Error handling is more important than the success case. Great UX is invisible – the thing just works. Bad error handling creates unhappy users and there is nothing more annoying than being on a pay-by-the-minute connection in a hotel to be told I need to use another browser or update mine. Stop pretending your work is so important people have to change for you if all you need to do is being more creative in your approach.

There are only a few of us unlucky enough to have to support IE6 in a pixel-perfect manner right now. The death of XP wasn’t the big liberation we really needed. And by all means it should not mean that you write web apps and web sites now that rely on bleeding edge technology in newer browsers without testing for it. This will never go away, and it shouldn’t. It makes us craftsmen, it keeps us on the ball. We need to think before we code, and – to me – that is never a bad idea.

The rules did not change:

• HTML is king – it will display when everything else fails, it will perform amazingly well.
• Progressive Enhancement means you write for now and for tomorrow – expect things to break, and plan for it, and you can never be surprised.
• Browser stats are fool’s gold – who cares how many people in Northern America who have a certain statistics package installed use browser x or browser y. What do your end-users use? Optimise for form factors and interaction, not for browsers. These will always change.
• Writing for one browser helps that one in the competition with others, but it hurts the web as a whole – we’re right now in a breakneck speed rat-race about browser innovation. This yields a lot of great data but doesn’t help developers if the innovations vanish a few versions later. We have jobs to do and projects to deliver. There is not much time to be guinea pigs
• Real innovation happens when we enhance the platform – we need WebComponents in the browsers, we need WebRTC in browsers, we need a more stable Offline and Local Storage solution. What we don’t need is more polyfills as these tend to become liabilities.

So, RIP XP, thanks for all the hardship and confusion that made us analyse what we do and learn from mistakes. Let’s crack on with it and not build the next XP/IE6 scenario because we like our new shiny toys.

Being in the middle a communication nightmare is never fun, but it is an important learning experience. I am sure that most problems start with miscommunication and escalate from there.

Say something happens, that you very much disagree with. Someone says something that attacks you personally, your beliefs or a group that you very much identify you with.

This doesn’t feel good, and it starts a few other feelings. It could be anger, disgust, annoyance, helplessness, fear, embarrassment, insecurity, just to name a few. None of those are good feelings. Some can be turned to good results but most make you feel at the lowest level unproductive and at the other end utterly shattered.

Let’s take a look at the most common ones:

Fear

“Fear is the mind killer” is absolute truth. People who are afraid stop contributing and are silenced. This is how totalitarian regimes work: you show yourself as all-powerful and the one to make decisions and you silence all of those who speak against you in a very public and brutal fashion. This makes everyone live in fear – citizens and enemies alike. Fear makes you feel helpless, you don’t want to speak up as you don’t want to stand out. In the worst cases you don’t want to speak out as it would punish all the ones you love. You don’t want to speak as you will feel the brunt of the loud and aggressive masses. You have input to give but you feel that it isn’t fair that because of what you stand for you get pushed into a certain group in a loggerheads scenario of black and white.

Anger

Anger can be productive. I am angry at myself to let my flat get to the state it is in now, so I am cleaning up. Anger can also be the end of any sensible discussion or dangerous. I cycle a lot in London. People cut into my lane, people push closer to me than they should. I could knock on their cars or shout at them. That would most likely get me killed as it would distract them and startle them into violent movements. Sometimes the best is to count to 10 and let it pass. Anger has an unfortunate tendency to pile up.

Gloat

In most long communication problems sooner or later it turns out that one of the attackers isn’t without flaws and innocent either. This shouldn’t be a surprise – we’re all human. In many cases the most avid attackers of a cause are people who are just afraid of being the thing they attack. Fear again. Gloating about this is toxic. It is a game of throwing the blame back and forth that nobody can win.

What to do, what to be aware of?

Over the last few days I got many reassuring emails and messages from all sides of the debate thanking me for a less-heated stance and analysis. I am not a super-human with the patience of a saint. Instead I learned to analyse my own actions and think and reflect before throwing things out. I fail at times at this, too, but I get better and I am happy about this. The most important thing is to be aware of your effects, instead of your message.

Mistake to avoid #1: Twitter is terrible for emotionally loaded topics

Twitter is awesome. I like the 140 character limit, as it makes me think before sending something away. Sadly it also allows for very short and strong messages that can turn into a ping-pong game of snark and ultimately, hatred or a grumpy “agree to disagree”.

Before you send a tweet about a sensitive subject, think about the following:

• Tweets make great comments that can be taken out of topic by media and other people. Nobody cares about the whole thread. The juicy bit is what gets quoted. Then it is up to you to defend yourself and bring context, that only 10% (if you are lucky) of the readers will ever hear about. Instead they themselves start shouting the wrong quote.
• Tweets are archived – of sorts and can be used against you months later. Doesn’t matter if your views changed, as you can not change the tweet it can be attributed to you. Oh yes, you can delete a tweet, but for the press this is an even better message. “$company employee showed his criticism on twitter but subsequently deleted the tweet.” is a good hint to claim your company or peer group censors you.

Mistake to avoid #2: Get bullied into giving information you don’t have

Don’t assume things. You have a brain; question them instead. One thing is simple to follow and important to understand: if you do not know something, don’t assume. It is as simple as that. You don’t know, so don’t say yes or no as you can be quoted and then it is up to you to explain yourself again. This is especially bad when your choice of guess was very wrong and you end up being put in a group you don’t want to be in. There is nothing more annoying than to be applauded by people you don’t like as you helped their cause.

People will try to bully you into taking a side, especially on Twitter. These people don’t care about insight (although that is a common trick: “hey, you are on the inside, this is amazing, I’d love to hear your ideas about this”); they want to have ammunition for attacks. “how can you say that didn’t happen or isn’t true? $x of your company said so, I can prove it here”. Don’t fall for this. Instead, turn the tables and ask questions. Repeat your questions if needed. Here are some I used:

• Where did you get this information from? I don’t know about that and wasn’t part of this decision. Can you show me?
• That’s an interesting topic and question, but I don’t think it can be answered here and in this format.
• Would you like people to talk about this topic if it revolved around you without having full insight? I would feel bad about this.

Do not say “No comment”. This means you know, but you choose to or aren’t allowed to say. It is an invitation to pester you until you give out the information you’re hiding.

Mistake to avoid #3: Get scared and withhold information that is important

Be afraid of those who are out to get bad quotes, don’t be afraid of your colleagues. Unhappy silence doesn’t help – showing unity does. Talk to colleagues, talk to people who are near you and tell them about your feelings. Point out to people who you think are out of line directly and personally that they are. It is up to them to realise their mistakes and make amends, not for you to jump into the ring with them. The silent majority has important points to make, and you have the right to tell them to the loud ones.
If you are afraid of speaking out, tell people who do and ask them to bring your point of view into the mix. You don’t have to become the target, but you can be a helper to bring out the truth. Not the loudest should win.

Mozillians: This is an offer – if you have points that worry you and feel too intimidated to speak, tell me. I will keep you anonymous but do my best to tell people about your POV.

Mistake to avoid #4: Get consumed by anger

Very angry people don’t want to find resolutions. They want to vent, they want others to feel bad so they can feel better. They want to win and silencing someone by beating them verbally into submission is a big kick for them. Avoid becoming that person. It can happen. Do not feed the trolls. My mother always said “the one who screams, is wrong”. I do know punk bands with great lyrics and messages, but on the whole, I think she is right.

What can you do?

Don’t be silent too long. Don’t wait until things blow over and then give your opinion publicly. This just drags the issues out further. Instead, help finding solutions. Be part of the healing and learning process. Simple things work:

• Research and uncover obvious wrong messages – tell them to those who are paid to communicate for you. It is an arrow in their quiver
• Listen to people and offer help – if someone is obviously shaken, angry or feels helpless, contact them directly and offer a sympathetic ear. You might just help someone avoiding to become a target
• Tell people when they are destructive – personally and not in public. Don’t shout, just point out how what they said could be seen out of context and how it made you feel
• Take breaks – it is very easy to get into a frenzy by following everything that happens and our new happy social media world is made up of this. Information is an addiction and you want more and more and more and faster and faster. The fastest moving news is bad news (both news that is bad, and news that is shoddily researched but sounds important [thanks to Jesse Ruderman for asking for clarification]) and the most re-iterated information is most likely wrong but sounds important. (There was a lovely part in Hitchhiker’s Guide to the Galaxy where one race built a spacecraft powered by bad news. It was the fastest ever, but nobody was happy when it arrived on their planet)

Be nice to each other out there, protect yourself from being misquoted and ask lots and lots of questions. If you feel attacked by someone you didn’t expect to be attacked by, tell them directly and immediately and say how it made you feel.

Human communication is 20% what we say and 80% how we say it – voice, body language, facial expression. All of this is missing online, so let’s bring it back by talking to each other rather than shouting publicly trying to get heard.

We have two ears and one mouth, we should listen more than speak and more importantly listen all around before we do so.