The Developer Bias

Every developer will understand and admit that we’re biased which browsers we want to support. Therefore a decision made with that bias will likely not reflect reality of people who will try to access the website/app.

The Analytics Fallacy

Okay, instead we’re now going to look at the current analytics data that we have from the current project. I mean, wouldn’t it be great if we build browser support based on who really uses our services?

The fallacy here is that this takes an existing project’s data and assumes that the audience will be the same. If we do that, we can be very assured that the audience will be the same. But this isn’t great. By taking the existing data we admit that we don’t want to provide a better solution to more people. People that couldn’t access the website before will likely not be able to do so in future. And these people won’t show up in your analytics.

When building an international website, have you considered that your Google Analytics will lack data from China? In China, Google Analytics is blocked at government-level, so all Chinese users won’t show up in your statistics. Now, with that in mind, would you reconsider supporting UC Browser if you know that you have thousands of users from China accessing your website via this mobile browser? In fact, for Asia, this browser accounts for 17.4% of the traffic (as of December 2016), more than Firefox or Internet Explorer together.

If your business or service should be available in Africa, have you considered that 35.4% (as of December 2016) of people there use a mobile phone and Opera Mini as a browser to access websites? Opera Mini here is on a race with Chrome for the number one position and quite even with it, leaving all common other browsers way behind. Now remember how Opera Mini works: It’s a proxy browser that won’t show up with its real user-requests in your Google Analytics as well.

With that facts in mind, we realize that we need to rethink our way to decide for browser support.

The Need for Assumptions

One way of defining proper browser support is to look at your actual statistics and try to figure out where there could be issues. If your website isn’t responsive yet, consider how different the numbers would look like if the project would be a great experience on a variety of devices, not only on Desktop or mainstream smartphones. If your website doesn’t have users from certain countries or continents, consider why that is and think about what needs to be done to include people from these countries. Think about connectivity, costs for internet access, different devices, different languages. The Web Worldwide helps you getting more context on that; it’s a research by Akamai, one of the biggest content delivery service providers worldwide and shows how people in different countries are connected to the internet with which connection speed and on which type of network and how much this costs them.

You see that I want to you assume what users your platform could get if only the circumstances are good for them. By doing that, we can suddenly think of reaching millions of new users with the project. Now it’s time to think about the consequences of including all of these possible users.

The Need for Trade-Offs

It’s clear that it would be a desire now for any product owner to reach all users worldwide. Unfortunately, nearly all capacities at projects are limited. This means we need and should find trade-offs now, and this is totally fine as we have thought of the available chances and now are able to evaluate how important they are for the project.

If your product affects German people, it’s okay to not translate the project into 42 or more languages. We should not forget to target as many users as possible, so a German language and English language for the non-German-speaking people living in Germany would still be desired. As the audience is Germany, we could happily decide now that we don’t need to support UC Browser (it’s not a thing here), and we can also think about not supporting Opera Mini (not much used here). We could decide not to host the infrastructure on Amazon Web Services or Google Cloud Engine and not to use a global CDN for it, since this causes more work but little value for German users.

But if your project needs to be available worldwide, we need to make the trade-off on the developer side. We must provide a basic experience to all the people and if that means that we can’t use certain technologies, then it should be decided to not use the technology. It’s often that we choose developer convenience over users (and that could comply with projects like the local one described above) but now is not the case where we should.

The Roundup

By expanding our view from current users towards possible users we’re reframing our bias towards an opportunity and can turn a project into success by opening up the availability of it to more users than previously.

Lastly, I can recommend this article by Chris Zacharias who worked for YouTube back when he wrote it and how they experienced this on their platform: By reducing the page weight of YouTube, suddenly the number of users increased drastically.

When we look at what has been added to browsers this year, you can see amazing statistics. Microsoft’s Edge browser got support for complete ES6 standard, and browsers pushed hard to implement security features and improve the performance. New features such as WOFF2 for webfonts, Web Notifications API, VP9 video playback, calc(), are great and some of them help every developer. Most of these features are not used by the majority of developers though. Who uses VP9 today, or the Web Notifications API? Not the normal developer. The issue is: We got plenty of new, great features but I’m pretty sure that most of these features are not used very frequently by developers. They might be used by some big sites, but not by the normal developer in an agency working on corporate websites and similar projects. Instead, these developers are still suffering from the lack of basic features in browsers. Which, you ask?

CSS Grids are still not supported anywhere to its full extend, meaning we as developers can’t use it for production.

SVG’s <use> method, used to display icons in a sprite, is still not usable from 3rd-party domains due to the missing CORS implementation.

<details><summary> is still not supported by every browser, clip-path is still not usable, we can’t use :has() yet, position: sticky, the vmax unit, tab-size, all: initial, font-size-adjust, Scroll Snap Points, and many other useful features.

Now for a fun fact: object-fit and object-position are still not supported in Edge despite the fact it’s been requested since over two years now and has over 2800 votes—a number most of the already implemented, edge-case ES6 features never reached. This shows quite good that all the browser companies follow a marketing strategy and instead of providing helpful features, rather spend time on completing a feature-set so they can claim 100% ES6 support. It’s nice that the people in the Edge team tell us that they listen to developers but it’s hard to believe that when I read through essential CSS features that are still not in Edge, but most other browsers.

In 2016, no single CSS feature that has a big impact for developers has been landed in all major browsers. It’s even hard to find significant additions in each browser, which makes me even more sad.

We don’t yet have any solution for locking down aspect-ratios. Hell yes, it’s 2016 and we can’t define an aspect-ratio for videos, images or other containers. I see people complaining about CSS hacks, about ugly markup and JavaScript solutions on photographic websites for displaying nice picture-grids. But there’s literally no way to do it with plain CSS at the moment since neither object-fit nor aspect-ratio is supported by all browsers.

In nearly every client-project that wasn’t a product itself but a website, I was requested to build a design where I need object-fit, aspect-ratio, position: sticky. And for most I could have saved a lot of hours if CSS Grids would’ve been available for all browsers. Instead, I now can use ES6 features I don’t even need for complex web applications (there’s still Babel for you) in the browser.

We have to think about the people we don’t have on our radar. The people that don’t participate on Twitter, Google Plus, Facebook, and are not raising their hands at conferences. They are still the majority of developers—not we, the little “Twitter-bubble”. We may shape the future of the web, but it’s our duty to care about all developers, not just us.

Now, can we please give this feedback nicely back to the browser vendors and W3C people? Yes, let them know. Write them on Twitter, via Email, on bug trackers, on uservoice, at conferences.

PS: It’s still hard to trace down what has been changed in Chrome since they’re the only company that publishes no useful changelogs. I expressed my feelings to the Developer Relations team on this often enough that I can now say: I don’t care about Chrome’s changes anymore. This sadly means I could be wrong on some things here by missing a Chrome change, but it’s certainly not a big change—otherwise we’d all know about it.

It’s Geek Mental Health Week again but this post is not limited to “Geeks” or any other group of people — it’s for everyone.

I recently read a comment by a reader of my weekly summary of web development resources. The comment targets my four week vacation that I took in September to clear my mind a bit and recover my motivation for work, and that it’s not my first time this year. As negative as this sounds, there’s a more important, hidden message in there: Taking more than two weeks of vacation per year is not a choice everyone has. And that makes me sad. I didn’t realize how privileged I am (among others in Germany and other countries) where by law an employer needs to offer employees at least 20 days of vacation per year, and most companies extending this to even 30+ days.

It makes me realize how crazily futuristic and careful some startups treat their employees by giving them the opportunity to choose as many days off as they want and even enforce them to take off at least 30 days a year.

But then you read such a comment where the author gets two weeks of vacation and even has a hard time to actually take those few days off. Then I also know how many startups and agencies encourage people to stay longer in the office, to not take days off, to not stop working when people are tired but only when the work is finished.

But while it’s a privilege to take five weeks off this year in summary (makes 25 vacation days), it’s important to take care of yourself. Who profits from an person that is mentally or physically not healthy anymore (burn-out, exhaustion)? No one, not even your employer. It’s them how then needs to find other people to get the work done, it’s them who need to pay for the people who can’t do their work anymore because of health problems. It’s just short-sighted to use people for quick work until they’re burnt-out.

I suffered from lack of motivation and exhaustion before I took my four week vacation. I now know that taking one four-week vacation in one year is not the best option, and I now also know that taking one or two days off to do sports is not relaxing for the body or the mind — it’s simply distraction from your main work but involves a lot of thinking and physical fitness as well.

As employers, we need to make sure that employees, contractors, anyone who works for the company takes appropriate care of themselves, takes vacation, gets relaxation. Encourage people to regularly take vacation, to make sports regularly, to enjoy a massage from time to time or something like that to stay healthy.

As employee or freelancers, we need to make sure to care about all this on our own. If the employer wants to force you to work more, have a talk, show them this article, let them know about more sustainable work concepts that don’t let people burn out.

If you have experience with these kind of issues or want to share your opinion, please do so and write me an email, or add a comment on Medium.

Yesterday, I read about a story where an artist lost his entire work when Google switched off the old Blogger platform. This threw thousands of blogs into nirvana. Google announced this, but the key problem remains: If the domain itself and all its subdomains are offline, no-one can set a redirect to a new location. With AMP, it’s a similar though a bit different topic.

AMP has been built to improve website’s performance. According to one of the core managers of the project, AMP has been built to live now and go away. In a few years when the media publishers integrated the technical concepts into their default websites, AMP will die.

If that is true, it’s already clear what happens in a few years: A massive scale of link rot. The main reason for it: The AMP project offers a CDN to host the pages currently. Of course this is in control of Google and not in control of the publisher. When project support ends, all CDN links will be broken (this is the example that triggered my thoughts about this issue, could be any other example).

Now, some publishers are clever enough to publish AMP version on their own hostname. That’s already a big step forward, but as maintainer of the WDRL I can say: When a technical URL change is being done, most people don’t redirect old URLs to new ones. And this is what will happen to most AMP URLs: AMP URLs will break.

Think twice if you want to share AMP URLs anywhere in public. No-one should link to them, and instead we should always try to link to the simplest, most likely preserved URL of a website that we can find.

Note/Addendum:

Medium isn’t much different here. Twitter isn’t. Facebook isn’t. Tumblr isn’t. Blogspot isn’t. The articles there will disappear at some point the same way Blogger blogs did. Blogger was big a few years ago and all people said: “This won’t go away, they can’t delete all this content”. In fact, they did. It’s a business and if the business isn’t sustainable, it gets shut down.

Apparently, this issue has been reported to Apple already months ago but until now, the “botnet” (I think it’s valid to call it like this in that case) is still behaving the same. Therefore to reduce my server load, I wanted to have a solution without adding Cloudfront or similar services upfront.

On an Apache Server it’s as easy as this:

# Block Apple News Bot
RewriteCond %{HTTP_USER_AGENT} AppleNewsBot [NC]
RewriteRule ^$ /status-429.php [L]

And this is the content of the PHP file:

<?php
header('HTTP/1.1 429 Too Many Requests', false, 429);
echo "Too Many Requests\n\nDear AppleNewsBot, please fix your Lets Encrypt support bug: https://www.slightfuture.com/webdev/excessive-applenewsbot-requests";

Now you might wonder why I used a PHP file here instead of returning a 429 HTTP-status code directly from Apache. The reason is quite simple though: My shared hoster uses the stable releases of RedHat Linux which ships only some 2.2 version of Apache. This old version (it’s getting bugfixes but no new features) does simply not know about 429 yet, introduced as late as in 2012.

So if you’re on nginx or Apache 2.4, you can return the 429 code directly from there. If you’re stuck on Apache 2.2, this is the solution you searched for.

Check a CDN’s Cache

If you use a CDN to serve your assets, you sometimes need to purge / invalidate the cache for a file. But most CDNs don’t do this instantly but take quite a while to do so. Especially Amazon Cloudfront can be quite unreliable for that but with a VPN, you can easily connect to various locations around the world to check what version of a document you get from the CDN’s Edge server.

Test on a slow connection

VPN providers won’t like this, but even when many VPN servers provide high-speed connections nowadays, you can easily enforce slow and unreliable network conditions using some special VPNs. NordVPN for example offers a Double VPN or Tor over VPN, and while they’re not super bad you’ll notice a high latency and slow connection. This can be useful to test your application under slow connections (and this is way more reliable than any simulated software connection throttling like in the Developer Tools of a browser).

Check regulations and performance issues from different locations

Being able to use remote connections in various countries and locations around the world enables you to test if something is being blocked, intercepted or modified through the ISP of the country. Also, you quickly notice performance issues for example when a country has no own CDN Edge server.

With the super-fast growing world of digitalisation and artificial intelligence, users cannot grasp the impact of it to our privacy anymore. Michael P. Lynch puts it right in this interview worth reading:

“Lots of people don't grasp the core reasons why privacy matters. Perhaps this isn't surprising. It's fundamentally a philosophical problem.” — Michael P. Lynch

Currently, we have two main issues here:

The one is developers for whom the easiest solution is still to build a private, locked-down cloud-based solution. This is because it’s super hard to do both, a good product with all its complicated features, and good, secure and maintainable infrastructure. There’s currently no real solution available to build distributed infrastructures for Artificial Intelligence — you need a lot of computing power, you need a secure environment while you as software provider still need feedback and issue reporting for improving the solution. Look at cars like Tesla, BMW, Mercedes or whatever luxury cars with security and convenience features; they offer you great drive assistants that “learn” how to prevent car accidents. This is great, but on the other hand, they only learn because they send the data to the cloud so that engineers and the system itself can learn from previous issues and improve. I personally would not know how to do this in a locked-down-to-the-owner solution. Also, how do you do software updates in a decentralised solution? This is not any safer than a centralised system. The only thing a company could do here is to provide a solid privacy policy to users and to tell users that one does not store sensitive personal data on the same system that has the car driving information. But for the user, he/she still needs to fully trust the company that this is true and not to be changed in future.

For the users, it’s an even tougher problem than for the developers. Most users do not even understand why privacy matters.

“To be honest, I’m tending towards saying that most people shouldn’t need to understand privacy. I’d love to have this as a ‘manifested’ standard in every government.” — Anselm

Of course, people want to profit from the tech-boom that’s still going on and that is not only promising but really producing convenient solutions. Most of the solutions available for home automation are convenient products that support people and make their lives easier. A smart thermostat is great because it saves energy while putting off the thinking-about-it load from people. A device that is in your kitchen and lets you buy things you need, is convenient because you will not have forgotten about the empty soy sauce bottle next time you are in the supermarket to make your groceries. You simply have not forgotten because you directly told your smart device that you need it when you recognise it and it’ll add it to you digital shopping cart. A messenger that lets you connect to people you hardly know is a great thing because human beings are social and are happier when we talk to other people. I’ve made lots of friends through Facebook groups for example with people who have the same interests as I. Why should I as user be in charge of finding out what a company stores of my private data? Does it even matter as we read in newspapers that metadata is the most important value and that even ‘true end-to-end encrypted services’ still produce and send metadata that can be used to track me or build a profile.

“A.I. assistants can give you the news, order you a pizza, and tell you a joke. All you have to do is trust them—completely.” — Will Oremus

A.I. assistants, because of the reasons I stated above for the developers, are convenient. All you have to do is trust them—completely.

What we need now is an ethical approach towards building software and services responsibly. This is where every single developer, product manager and company leader in the world can do something: If see it as our personal responsibility to protect our users’ privacy, data and security, we would build better solutions. I explicitly state we here as this targets me as well.

What I haven’t yet figured yet is out how we can achieve both, grasping technology that we need to build such solutions (I’m talking about all the languages we need to know, frameworks, technical backgrounds) and the lesser obvious know-how about accessibility, performance, privacy, decentralised infrastructures and security. The main reason why unpatched, insecure and non-accessible products exist so frequently nowadays is because people don’t know about all these specific topic but are still the persons who should lead the development in companies, agencies.

Let‘s remember that blaming Facebook or Google to be the bad guys is an easy thing to do but it’s not necessarily helpful in that context. In fact, I recognise this is often an excuse for oneself. But if we want to improve the situation, we need all developers in the world to understand that we are always to some point part of the problem and every successful big change was lead by someone changing its own habits, its own requirements to what one wants to deliver as quality work. If we set this goal for ourselves, we can teach others to do this as well.

This of course, will not alone change the data-collecting no-privacy mindset but I see this as the base for other actions to be taken.

Now, let me know what you want to change and how you think we could achieve more people to think about these problems so that the human population who’s not programmers don’t need to be frightened and end up in a society like it’s described in the (not so much anymore) “science fiction” book Nineteen Eighty-Four.

— Anselm

Note: This has been written as response to “Tech titans are busy privatising our data” initially, but turned out to be a lenghty response that is a blog post itself.

Note: This post is not a rant about Service Workers. I believe they are a great technology and help us as developers creating better services. This is just an expression of my initial thoughts as a browser user having a detailed view on this new technology.

A few weeks ago, I had a chat with Tobias Tom about Service Workers. He challenged it as we were talking about web performance, caching, and privacy. During that, we digged deeper into Service Workers and tried to find out how they are implemented currently in Chrome and Firefox. And for a feature that is available (partially) in stable versions of browsers, what I found out made me worrying about it.

First, it’s interesting to see that browsers have implemented a technology for which only a W3C editor’s draft is available on a personal github page by Alex Russell is available as “web standard”. It’s under heavy development and obviously misses quite some points. It seems I was wrong about no official standard being available because there is indeed a stable Working Draft spec. Thanks for point this out, Jake.

Permissions

The first thing I noticed after making sure that Service Worker are enabled (Chrome is behind flags) was that I found no user setting or any hint in the developer tools about service workers. From my first impression, I had expected to either get a notification (as it’s being done for geolocation or other APIs) or at least being able to debug it and see contents and details in the developer tools. Two points here:

• As a user I expected to be notified about a page wanting to store things for offline or later usage on my machine
• As a user I expected to be able to delete the cache of Service Workers and with it the Service Workers itself (this is not true for Firefox as of today)
• As a developer, I expect to be able to debug it and see Service Worker content in the developer tools in a dedicated view. This is not true as of today for Chrome and Firefox (although they claim support for this but it’s rudimentary and does not allow modifying the cache or similar things)
• As a specification reader, I expected the specification to contain something about permissions. As a matter of fact, neither the Permission API, User Notification API nor the word “permission” can be found in the spec as of today. The only thing that can be found is that there’s interest in making Web Notifications available to Service Workers so if a developer is responsible, he can ask for permission before starting the service worker offline action.

Concerns about Transparency and User Control

Currently, both Chrome and Firefox seem (I have no evidence on that, sorry) to use the generic browser cache for Service Workers. The problem with that is, I hadn’t expected this.

Firefox for example has the network settings view with settings for the Cache and a dedicated section about “Offline Web Content and User Data”, listing the permissions setting for that and the websites using this. However, websites using service workers are not listed nor affected by this setting. Going into the details, I found out that there is a dedicated Service Worker control page available under this URL: about:serviceworkers. This lists all the Service Workers that are registered. Unfortunately, a user is not able to unregister all of them at once—the cool thing is, it contains many details to find out what an active service worker is doing.

Chrome on the other hand, has changed this and does not offer any differentiation on that anymore. That means, you can only control Service Workers by deleting your entire browser cache. Fortunately, at least Chrome deletes also the service worker itself when doing that. You can keep track of Service Workers by typing in this URL into Chrome: chrome://serviceworker-internals/.

A Little Detail: Let’s just add a little detail on both of the internal browser control pages: None of them contains useful or semantic, let alone accessible markup here. So unless you’re able to see the page, that is completely useless. It’s also useless to parsers so I wasn’t able to write a script for Chrome that clears the workers as they use a span without a class or other reliable identifier as button here. Thanks for that, browser vendors!

Concerns about Storage Limits

So as the two big browser vendors that have implemented Service Workers so far agreed on using the generic browser cache for it, a user is out of control on what is stored on his/her device. That given, the only control is to limit the cache size—which is exactly what I’ve done to prevent Service Workers eating up my storage. The problem with that is, that by limiting the generic cache I fetch more data and create more traffic to servers.

So why did I limit my cache size manually? There is a simple few reasons for it:

1. I don’t want to let my browser eat up my disk space
2. There seems no limit what Service Workers can register to store offline per Service Worker. So any website I visit can store huge amounts of data in the background. This could include images, CSS, JavaScript, videos.
3. Ad providers or any malicious site can store JavaScript in Service Workers and might be able to track me and serve malicious code to me.
4. If someone compromises a usually trustworthy website, the attacker of course will register a service worker to be as persistent as possible in the user’s browser and can therefore alter the content of the website even if the server is not under his control anymore. Wanna know more about this? Yay, go here and to this PDF in Section 3.5.

Conclusion

Tobias immediately reflected on why Safari hasn’t started implementing Service Workers yet. We assumed, that as in the past, Safari cares about great user experience and therefore will only implement it if the permission issues are solved. Of course, this is only a vague assumption without any evidence here.

I really hope that no mobile browser will implement Service Worker without providing more control to the user here. And by raising these issues here, I want to ask the browser vendors and spec writers to fix that behavior before Service Worker become really popular.

Update 1

It seems I have offended people with my “badly researched” article. To be clear on that, this article may not be technically entirely correct – I said it before and can only repeat it. This article reflects my thoughts, my personal opinion and my open questions from what I know of Service Workers and from what I found out of using a browser and trying to change its settings (without opening developer tools or weird internal pages). It is a sharing of an experience as a normal web browser user that cares about his cache, privacy, security and storage quota.

Thankfully, Jake Archibald spend some time and replied to my article with some explanations. I also noted down additional thoughts as a comment over there after the new information I gathered from the gist.

Note that this isn’t a particular problem of Cloudflare but a disclosure of a common misapprehension of their service.

“The Challenge” aka “Marking HTTP as insecure”

With recent moves from browser vendors to push secure connections between the browser and the server, they started “deprecating HTTP”. But while the intention is good, it forces people to make decisions. Decisions about topics they don’t know much about.

For many web developers, and for nearly all non-professional website builders, HTTPS is a tough challenge. It’s never been easy to get a SSL (today TLS) certificate. It’s hard to configure your server properly, and even hosting companies fail at this these days. For most people, it’s either a costly option to add a certificate to their shared hosting service or impossible.

Since December, Let’s Encrypt is in public beta. This is a great thing because it enables many developers to get and deploy TLS-certificates easily. But it’s restricted to having CLI access, which, for the majority of website owners, is a big burden that they’re unwilled to take.

Having discussed this topic over and over again with various developers and site owners it’s clear to me, that if HTTPS is not a default option that comes with the hosting service for free, most people won’t be able to provide it to users. My hope is that in 2016, service providers and browser vendors together will get this sorted out and HTTPS is painless for everyone—not just a few developers with CLI access on their servers.

A 3rd party can’t fix it

So why did I start this article with Cloudflare? Cloudflare is a website optimisation service that also offers a pretty good free tier. It’s probably the most used performance optimisation tool out there and with that, it achieved to be one of the biggest DNS service provider world-wide.

I used Cloudflare back when my website and wdrl.info were hosted on github pages. I used it for the same reason most people do and I did because I also didn’t understood the security implications. I’m now here to make clear what services like Cloudflare can do and what not.

What can a 3rd party service do for me?

• Act as a CDN to deliver content faster to your users and to save load and bandwidth on your origin server
• Optimise your assets (compression, concatenation, etc)
• Protect your origin server from DDoS attacks and from SQL injections or similar things
• Show you statistics of your users
• Provide HTTPS support (note the wording here)

What can’t a 3rd party service do for me?

• Protect your origin server against security issues in your application
• Provide a really secure HTTPS connection (in some cases it could)

The privacy and security problem of 3rd parties

Now, as cool as Cloudflare seems at a first glance, there is a problem with it. They collect statistics and you can’t control what they collect. You move the DNS to their servers and they basically route every request through their servers. Their security policy for example states that they “sometimes log these visitors’ interactions in order to provide a better service”. They say that they add cookies on the users’ browser to track users. They even state that they may provide all collected data to third parties (although they say to strip data from IP, name, email).

Is that a service you want to expose every visitor of your website to? Even if the company itself has only the best intentions, an attacker could still steals this massive data-set and expose it.

HTTPS = Secure Hypertext Transfer Protocol

Now back to HTTPS, our original topic here. Browser vendors have been pushing hard to ensure that a connection between the browser and the origin server is secure. Usually, you can achieve this with a TLS-certificate. It’s been the way for more than a decade now but only recently, a few problems have been discovered with the technique. Thankfully, smart people are fixing them.

Let’s say you host your website at a service provider that doesn’t give you an affordable option to enable HTTPS on your custom domain. Cloudflare gives you the option to upgrade your connection with SSL for free. Cool eh? Not so much. What happens is that the user requests the website and sees it uses HTTPS (the green lock icon in the browser). But the connection from your origin server to Cloudflare’s servers is still unprotected, exposing all the data that is shared there to the public. The result: The user thinks it’s a safe website but it simply isn’t.

Okay, let’s now assume you have a hosting service that has some kind of SSL (github for example) and you now use HTTPS via Cloudflare. Cool, eh? Not so much. The Full SSL option does not even validate the certificate at all, the Strict SSL option does this. But still, Cloudflare reads your content, analyses it, optimises it (unencrypted, it’s even unknown how they communicate internally between their servers), re-encrypts the content and sends it over to the browser with their certificate.

To be honest, Cloudflare makes this as clear as they can. They never say anything else but yet, most people don’t know that their website is still insecure although it has a green badge in the browser bar. Most people don’t include Cloudflare in their privacy policy (but it’d be required).

Let’s change that. Don’t just recommend a service to people, tell them about the implications. Reflect twice before you give your data to a third party.

Update 1

I answered some more questions regarding HTTPS in this CSS-Tricks article. Check it out to understand some of the mentioned techniques here a little bit better.

Update 2 & 2.1

A reader of my article, Binyamin Laukstein contacted Cloudflare support and got some answers (Quote from email not altered by me).

1 - All internal cloudflare communication is encrypted.
2 - Our cached content is stored encrypted.
3 - We do provide separate encryption between our visitor <-> edge and from edge <-> origin. If we did not do this there would be no way to cache the resources our customers want, or provide many of the security benefits we provide.
4 - we do not provide re-encrypted data or origin content to third parties.

First, thanks for investigating and sending me the reply. However, I wonder why this is not written on the website anywhere. Unfortunately, the response from you doesn’t contain any details on what they encrypt how and what server logs they keep. I from their ToS that they cooperate with governments and its institutions and hand out all details they have to them if they need to (which at the minimum would be the server logs in this case).

But remember, as said in my article, Cloudflare is only one example. Another one could be Amazon Web Services that probably has the same issues. ;)

Appendix / Explanations

As said initially, this post is not a rant about a specific third party service but should only make people aware of some fatal misunderstandings of the used techniques. We’re all in this boat together to make the web more secure and I’m glad that Cloudflare does exactly that for thousands of sites. This post is about the thousands of sites that only make users believe a site is secure.

Here are a few more explanations to details in the article:

I’ve been experimenting quite a lot with Firefox’ new tracking protection recently. It revealed some quite interesting things about where we’re at in the web. Unfortunately, it’s not as good as you might think and here’s why.

You might have heard that Facebook has introduced 2G Tuesdays to make developers aware of the performance implications. We can do this in many more occasions, one of them is emulating package loss with mobile data, another one ad-blocking. And as ad-blocking and privacy-extensions are on a quick rise currently with native solutions coming up as well, we should consider this a common use-case for our products we build.

Here’s how you can enable it:

Grab it as gif here [33MB]

What does this mean? I can only encourage you enable Firefox’ Privacy Protection Strict Mode at last one day per week and see what works and what doesn’t. You might not think that it has much impact but in fact, the web is very broken. Many applications require jQuery from the Cloudfront service which is on the Disconnect block list. If you now have your own JavaScripts not on Cloudfront it can’t find $ as jQuery is blocked. If you have your JavaScript and CSS on Cloudfront as well, all these resources are blocked, too.

I can conclude that most problems I found occurred with SPAs. Trello couldn’t provide a login anymore, Todoist does show a blank page (not even their website is available anymore), and many other applications and websites are at least without JS and CSS, some without any content. The most common error besides using cloudfront.net hostnames for their assets was that they rely on some external JavaScript variables and don’t test for it, causing the whole JavaScript to break in case the 3rd party script was blocked.

You can avoid this by doing a few things:

• If you use Cloudfront, make sure to use a custom HTTPS certificate, and thus, a custom hostname that isn’t blacklisted. This doesn’t fix the root issue that Cloudfront tracks the user (statistics), but at least the app is still usable.
• Reduce the Single Point of Failure using Service Workers.
• Be sure to read this article on Third Party Content in an HTTP/2 and ad blockers world by Yoav Weiss.
• Always test if a variable exists, and if not, don’t let it break your entire JavaScript. Especially when your app is relying on JavaScript.
• Never (ever!) rely on the availability of any third-party (also not on an external CDN). Your app should work without it and you should have a backup plan when a 3rd party you rely on is not available.

Over the past months there have been a few articles taking care of different font loading optimization techniques. Reading all of them, I ran into a few other issues that are not covered there. Finally, I wanted to have one resource combining the information of the others. Some code snippets are borrowed or adapted from the articles I linked here.

The Goals

1. Load web fonts asynchronously
2. Avoid big reflows in layout
3. Load web fonts as fast as possible
4. Avoid loading web fonts for recurring visitors

Now let’s try to reach our goals step by step:

1. Load webfonts asynchronously

As you have to call the web font locally via @font-face you usually have a blocking request. To avoid this, you need to put the @font-face code into a separate stylesheet that you call via JavaScript. There is the simple loadCSS function from filamentgroup you can use. This is the most basic variant.

You can also use typekit’s webfontloader with custom web fonts which since version 1.6.8 uses native Font Loading API if available.

But now we also have the Font Face Observer, then we have a Font Loader making use of the fresh W3C Font Load Events and we have a script which Smashing Magazine makes use of which actually solves a few more of this article’s points (but not all).

So where do we start now? First, we exclude the Font Loader providing a polyfill for the latest web standard. It is too large to have this in as part of a performance optimization step. It will definitely be cool in future to use this but unless natively available it doesn’t make sense to use it. Instead, we can use Font Face Observer in the meantime. It only weighs in at 5kb (minified, not gzipped).

Cool, let’s start. You can get the Font Face Observer script via npm, bower or git(hub). Include the script into your <head>.
Note: Setting the async attribute randomly adds an unwanted FOIT additionally to the FOUT to your website.

Now we need to initialize the font face observer. You can do this with an inline script or with an external script included in the <head>. I’m showing the demo using the browserify / CommonJS variant in an external script and loaded the script as npm dependency:
First, we need to require the library:

    var FontFaceObserver = require('fontfaceobserver');

Now let’s define the fonts and font variants we want to observe:

    var observer = new FontFaceObserver('Fira Sans', {
        weight: 400
    });

You can use weight, style, variant, featureSettings, stretch here as options. Now we want to initialize the observer on our defined font settings. We still need to set the CSS class that the font has been loaded. That is done via the following Promise:

    observer.check().then(function () {
        document.documentElement.classList.add('webfont-loaded');
    }, function () {
        console.info('Web font could not be loaded in time. Falling back to system fonts.');
    });

    var fontfaceobserver = require('fontfaceobserver');
    var fontObservers = [];
    var fontFamilies = {
        'Fira Sans': [
            {
                weight: 400
            },
            {
                weight: 600
            }
        ],
        'Fira Mono': [
            {
                weight: 400
            }
        ]
    }

    Object.keys(fontFamilies).forEach(function(family) {
        fontObservers.push(fontFamilies[family].map(function(config) {
            return new FontFaceObserver(family, config).check()
        }));
    });

    Promise.all(fontObservers)
        .then(function() {
            document.documentElement.classList.add('webfont-loaded');
        }, function() {
            console.info('Web fonts could not be loaded in time. Falling back to system fonts.');
    });

With that, we’re done implementing the Font Face Observer and have set the class when the font is ready. Now we should reflect that in our CSS:

    body {
        font-family: sans-serif;
    }
    .webfont-loaded body {
        font-family: 'Fira Sans', sans-serif;
    }

2. Avoid big reflows in layout

We now have a seamless and reliable system to inject our web font when it’s available. That of course means that initially, users will get the fallback font you’ve defined. While this is a good thing because they can already start reading the text, it means users will get a flash and restyling, often resulting in a jump of words due to the font change.

We want to aim for a better experience here. This consists of two steps:

1. First, you need to find the best fallback fonts to your web font. This is best done with this little bookmarklet and the compatibility check over here. When you’ve found a good fallback font you’re half done. But no font looks the same and even the nearest fallback font has glyphs with a different width or a different x-height. Fortunately, CSS gives us some tools to optimize this. The fresh font-size-adjust property exists to adjust the fallback font to your web font or the other way round. Set this to to adjust the x-height of the typeset. It’s a bit tricky to use so I recommend to try some values in the dev tools (or read up the formula in the linked article if you’re more into maths). Usually you will end up somewhere between 0.40 and 0.70 as value.
   
2. After matching the x-height, we now start to adjust the letter-spacing. This is relatively easy and by setting the value in super small steps (i.e. -0.01em) you ensure it still looks good and is readable. Now you should be at a point where you have a very similar font rendering of the fallback font to your web font. To see the difference during testing, you can add a timeout to the function that sets the webfont-loaded CSS class.

3. Load webfonts as fast as possible

This one is relatively simple. In fact we’ve already done much to load our web fonts as fast as possible and inject them at the right time. The last thing you can do now is to add a preload header for the web font files.

Note/Update: I previously stated to use prefetch which is wrong. Instead, you should use preload which is nearly unsupported and has the drawbacks stated below.

    <link rel="preload" href="FiraSans-Regular.woff">
    <link rel="preload" href="FiraSans-SemiBold.woff">

As you can see I only used the woff fonts here. This is because we shouldn’t call all the different formats in here. This little snippet tells the browser that if possible it should download these resources already. If you’d add all formats here, the browser would download them all which is kind of useless. However, all browsers that support prefetch support WOFF, too. If you want to use woff2, this is not true anymore and you should avoid adding these headers.

4. Avoid loading web fonts again for recurring visitors

To avoid that the users have to re-download web fonts over and over again and don’t run the late JavaScript font face observer when the font is already available from cache, we can use cookies or localStorage. While the cookie script only looks if the font is in the browser’s cache, the localStorage variant will put the fonts in the longer lasting localStorage and retrieve it from there if a user visits the site again.

I won’t give a preference here as both have some advantages. While the localStorage will be safer to ensure it’s cached, it’s a bit slower than using cookies and the native browser cache. Use what you prefer and what will probably work better for your project.

This method is somehow unreliable. A browsers’ cache is not directly related to cookie storage so if one or the other is deleted but not both, this method can cause a blocking font load.

• Using cookies, the simplest code using SSI would something like that:

  
  <!--#if expr="$HTTP_COOKIE=/webfont-loaded=true/" -->
  <html lang="en" class="webfont-loaded">
  <!--#else -->
  <html lang="en">
  <!--#endif -->
  

• Using localStorage, you can use this gist with the code used by Smashing Magazine on their website.

While it works pretty good you should consider that using localStorage might still be a bit slower than using the native cache and, what is more important, this fills up the user’s disk space and is only per domain. So if a user visits another site using the same web font, the UA downloads it again.

What’s next?

As we have seen in the past months and years, the way we implement web fonts changes all the time. Browsers will implement the Font Load Events, there will even be CSS properties that help you dealing with the FOIT. font-rendering, font-rendering: swap will hopefully make all the things I described here much easier.

If you want to save some bytes by excluding several styles or weights of the web fonts, you can control the browser’s behavior if faux styles are allowed or not with font-synthesis.

It’s the new IE

Well, I can’t say that sentence is entirely wrong. With Apple’s engineers hiding all their development from the public and several occurrences where Apple invents their own “webstandard” (it isn’t – it’s just a proprietary, hurting the web invention) it is undeniable that Safari has the wrong process. They lack important features like WebRTC/ORTC, Service Worker, <picture> and have a comparably slow release-cycle. That way they are staying behind all the other browsers out there today and users will get a worse web experience than if they’d used Firefox or Chrome. That is based on the fact that progressive enhancement is not broadly used, and not all features can be enhanced progressively (like video chat).

It’s the user centric web

Other people say, Safari concentrates rather on the user than on the developer. And while I agree in some parts, I have to deny this, too. Fact is, the Apple engineers come up with cool things like the reader mode, the twitter update bar, shared links, AirPlay, Picture in Picture. That is cool but often relies on proprietary hard- and software (AirPlay). The engineers don’t take the recommended approach of finding a universal and standardized syntax to achieve such technologies but implement some custom code that sometimes even breaks other browsers. This comes at a cost: The open web suffers from such solutions and users cannot freely choose their browser when they want to have these features.

Safari curates their featureset better

I have to agree that Chrome is an example of implement most suggestions fast and easy. I don’t particularly like this approach because later on, a performance lack might be discovered leading to the removal of an already existing and used feature. That is really hurting the web and its technologies.

Safari does it differently by not adopting new stuff so fast. But they also don’t adapt long finished web standards which is also kind of wrong because they leave their users behind. And it’s not user-centric at all if the user can’t see some content in a nice way or can’t initialize/join a video call.

There is no public discussion

The probably biggest issue with Safari right now is that the Apple team is not having an open discussion. And because of that, they build proprietary, website breaking stuff and more important, they neglect their developers and users. A developer who does not communicate with the product’s users does not know what they want to have. Be it developers asking for ES6 support or be it a user who wants the web application he’s visiting offline (Service Worker) or less transferred bytes (<picture>) or a video call with another person only having a webbrowser available (WebRTC). That way it’s easy to say they are user-centric but it’s a denial of the users in reality.

What to do?

In fact there’s not much to do for us as developers. We can of course go the same way we went with Internet Explorer 6 when this one became too old but still wide-spread: Publicly shaming the browser. But if you remember, it took Microsoft quite a couple of years to take action and focus on the IE product again. I don’t think it’s a feasible way to do the same with Apple’s Safari.

I’d rather address issues with Safari, embrace use cases for the most wanted features and share them to the appropriate mailing lists (Apple engineers do indeed read WHATWG lists), in blog posts or ping WebKit/Safari engineers or DevRels on twitter. Apple needs a more direct contact to web developers and we should start this dialog.

Reasons for Switching

It’s super easy to set up github pages and as they have ruby installed it’s even easier to run your Jekyll based site on it. You can also add custom domains to it which I did. At some point in the past years I wanted to encrypt the user’s session and enabled SSL via Cloudflare. But there is an issue with the whole workflow while it’s super easy:

• GitHub owns your data. If it’s down (i.e. DDoS), your site is, too.
• GitHub has a problem with A-Record Domains using no www..
• GitHub has only unofficial HTTPS support on GitHub pages and none for custom domains.
• Cloudflare wants to handle your nameservers and DNS entirely.
• Cloudflare has only free shared SSL certificates (which have some drawbacks).
• Cloudflare only mocks your HTTPS connection to the next server. No one knows if it’s encrypted all the way back to GitHub.
• Both GitHub and Cloudflare are vulnerable to DDoS and might be down.
• In case you need to switch your site due to an outage / shutdown one of the companies’ will be down for at least (depending on Cloudflare settings) 48hrs completely.
• Cloudflare does not allow 3rd party CDNs anymore (at least in the free plan).

Preparations

First I needed to set up the project infrastructure for my Jekyll project. I wanted my workflow to stay the same so I needed git on the server. In fact, I preferred to do the jekyll build on my local machine now instead of the server so I don’t necessarily need ruby on the server, even though my shared hosting package at Uberspace does support that as well.

Second, I need my own SSL/TLS Certificate. I used sslmate for that creating Comodo certs in an super easy way. That was actually very easy already. I created them locally so I now needed to push them to the server via SSH (please be very careful here and keep everything secure and private in this step) and notified my hoster so he can configure the server to use it.

The domain was already allowed and configured for the server so now I only had to switch the nameserver and DNS to the uberspace host. This can take up to 48hrs to populate to everyone. Ready. My site runs on my own hosting service again, the certificate is my own which I can fully trust and I still have an easy workflow to push content to my site.

Trouble

But not everything went fine for me. In fact, there are a couple of drawbacks:

• My site might be slower for everyone far away from Germany as the site now runs from a single server in Germany again (previously was choosing nearest server worldwide by github). This can be done, too, but for now it’s too much effort.
• My site was down for a couple of hours due to me failing on the DNS change and my hoster to tell me that the IP running SSL services is another one than for HTTP.
• There is no easy integration for creating and configuriing SSL certificates at shared hosting services yet.
• You really need to know about the potential impacts of DNS, SSL, HSTS and changing nameservers.
• My Github website repository went on serving all content (solved manually by support staff)
• I needed to redirect gh-pages to their github.io domain on my server.

This experience again showed me how hard it still is for a normal user (and I’d call myself tech-experienced and CLI-aware already) to configure HTTPS properly.

It made me think about the hard push by browser vendors to HTTPS and question that in regard to people who don’t have the possibility to configure their webspaces (I know a lot of them where this wouldn’t have been possible at all without switching to a way more expensive package) or simply don’t have the skills and endurance of trying it out.

In the past week I visited a lot of different websites. Not the usual web development websites that I visit all the time but very different normal websites: Product pages and travel websites which are much more likely to be seen by normal users than my web development pages. But on some pages I experienced serious issues to navigate. Many of them used custom scroll behaviour. And not in a way you would assume, like binding animations (i.e. fading in elements on scroll) to scroll events but they actually altered the scroll behaviour itself. Some altered the speed which I found the worst, others blocked the scrolling entirely to jump to the next or previous section of a page.

The main issue with that is that even I as an experienced web user couldn’t read some product specifications as I failed to scroll slow enough (or more precisely, to scroll only a few pixels which seemed to be the threshold on a page to go to the next page), resulting that I always switched not one section but two or three and was unable to go where I wanted to.

The same issue occurred on sites making scrolling faster. It is a key principle of a scroll device experience that I can set the speed of scrolling to my own default in the OS settings. A page altering this now leads to issues because the user can’t scroll in the speed he’s used to. This means he can’t read the content of a site anymore which should be the ultimate goal of a website.

Do it right, do it properly

Now you could say: ‘Do it right, do it properly’. But what if people use Wordpress Themes that include this behaviour?

Facing the facts, that is what most people do and what causes most issues nowadays.

Again, why would you alter the default scroll speed? I agree that we probably shouldn’t prevent the jumping to next section behaviour on scroll because web-apps sometimes want to do this and although I think a proper responsive concept shouldn’t have a paging mode I also accept that people use this for an application style.

But maybe a smart browser would automatically fix issues like a threshold which is too small to navigate or disables the function then. Because currently, it’s going the other way round. It seems that Blink wants to provide native binding to scrolling. While they seem to be aware of some issues they want to allow hiding scroll bars (which is bad because it’s a great indicator for the user) and don’t prevent too fast scrolls on the snap point navigation.

For altering the default scroll speed I honestly couldn’t come up with a valid use-case. If you have one, let me know. To me this is one of the worst and contra productive UX ”improvements“ people have done so far.

What started out as a simple bullet point list on my blog now is a hand written letter with still some kind of list with links but very much personal (and sometimes biased) written lines in it. Each letter makes me more confident, stronger in sharing things to make the web and our web developers’ lives a better place.

Cheers,
Anselm

Addendum / Note: I’m not on either side in the following example. It just shows a hopefully neutral view on how different persons deal with others.

Ind.ie is a company that wants to re-invent how internet platforms nowadays work. They want such platforms to be de-centralized, user-focused, privacy-aware and still sustainable. This is an acknowledgeable goal and while I always thought it will be a challenge to achieve this with just a team of four people I wanted to support this goal.

In my opinion they haven‘t done everything the way I think they should’ve but no company does so. And every human fails at some things as well. So when they launched their crowd-funding campaign (which gladly exceeded their minimum goal) I didn’t thought it was the right way to ask people for money. Especially as I never got what I expected and every time at least half a year later than promised from similar campaigns I wanted to support their goals.

I want the independent, privacy aware web to succeed. I want to support people who are in search of new ways to make money on the internet without selling its users’ data to other companies. I want the web as it was thought to win.

It was confusing to read, that indie will re-focus their goals and will drop every product but their social network and will focus on get this running on Mac OS X.

I thought it was wrong to focus on the small portion of Mac users, leaving out all the normal PC users and not using the web’s full potential instead.

That’s why I asked them via email what the long-term goals are and if they’ll really drop the other things promised during the crowd-funding campaign.

But what I saw on Twitter really disgusted me: Suddenly, people started fights against indie, against the founder, Aral Balkan. People even took his letter introduction as offensive, inappropriate. In that he mentioned the cruelties that happened in Paris last week and how sad that was. Of course this is an unrelated event to their re-focus, of course he knows that. But he wanted to let people know how sad he’s about that day in the history and how important it is to do the best you can to make the world a better place.

It’s sad that people pick unrelated things up to fight against people who want to make the world a little better. It’s sad that people fight against something good.

It may not have been the most clever type of communication by indie. It may not be the best decision to disappoint their very own supporters. It may not even have been their intent though. And bear in mind, they’re just four people, most of them developers who want to create something. They’re not marketing people, they’re not big companies. For me, exactly this makes them personable. For me, this was the reason to support them. And for me this is the reason why I didn’t invest in four products but in these four people to let them do whatever they think is best with my $100.

You might not think the same (and that’s good). But is this a reason to personally attack and harass people in public? I wonder why nobody sees this as harassment. Especially people who are against harassment in general. And of course an offensive reply doesn’t help in such a context but if you try to be smarter than the one who’s talking with you, you will be heard and you will be the one who has better chances to succeed.

Wouldn’t it be better to suggest a helpful debate about the problems you feel? Wouldn’t it be better to write to the people that can help you with the problem you face directly? Maybe you have ideas that nobody else considered yet? I think it would.

Be smart and don’t fight. Peace is best done by being and behaving peaceful and showing respect to other people.

Have a good day, Anselm

Note: This is a personal article and there’s at least no technical take away in here.

2014 started with a big change. In December 2013 I said ‘yes’ to my biggest project yet in my career and I started January, 6th, in my new team. This included moving from Munich to Cologne for what I thought would last six month and took out 9.5 months. For me this was a tough decision as my girlfriend, my friends and my beloved mountains stayed in Munich. Nevertheless as it’s only planned for half a year and the opportunity was great, I decided to do this step and it was absolutely right. I had the chance to work with my friend Hans to build a super large-scale front end infrastructure at Vaillant and met a lot of amazing developers, managers, other people and with a lot of them, I became friends. I learned a lot about scalability, maintainability and working together as people in larger teams.

In fact, I really enjoyed the new city. Cologne is a beautiful, nice city with a lot of small coffee roasters, and other independent shops. It also has a lot of nice bars and people to meet. When I went to the park once to enjoy the sun, I stumbled over some slackliners and I became friends with them immediately. From that sunny and warm day in March I went slacklining every possible weekend, improving my personal skills a lot (previously I could walk around 25m, now I’m walking 50m and tried to walk even longer lines around 100 meters).

Work-wise I learned how to scale a front-end architecture to drive dozens of websites later on, build a toolchain around it and how to build it rock-solid with more than ten people working on the code-base. Together with Hans we built our own tools, scripts, decoupled tools from each other and came up with a very stable architecture that works for everyone in the team. I met a lot of great friends in this project and hope we’ll stay in contact in the future.

Over easter, I decided to make a short four day trip to Italy for some mountainbiking with one of my best friends. We took his car, put our bikes in and went to the Lake of Garda. The first two days were amazing and we had a lot of fun although the 2nd was very rainy and we went to the sunny Venice for an afternoon. Pssst... biking in the city is strongly forbidden (if you wonder).

The third day, it was Sunday, I saw that my mother had called me. Somehow I felt it was important and usually she tries not to call me during vacation. I called her back and she told me that my grandfather had died last night. He had been in hospital for some days before but initially all said it wasn’t something serious. Finally, on friday they re-checked him and found out that he’d urgently need stents and other stuff.

We all knew that he wouldn’t live forever but no one had expected it so quickly as he was all well, had no serious illness and most of the time was happy. But he always said “I don’t want to be in need of another person to live”. And as he heard that this wouldn’t be possible anymore (you will need assistance if you get stents at this age), I think he decided to not live anymore.

The following days were very tough and while I stayed the same day and went biking to think about it and get a clearer mind, we went back to Munich the next morning and I stayed the whole week with my family. It wasn’t tragic and we knew it’s the best for him and probably his own decision but still it’s very sad and forces you to think about family, life and all these things. He’ll always be remembered, I learned a lot from him.

In early May, me and Christian Schäfer (also known as “Schepp”) went to London to attend the netawards ceremony. I had been nominated as Young Developer of the Year 2014 and also opendevicelab.com was nominated as Game Changer of the year. And while I did not win, I enjoyed being there meeting lots of people and having a very fine dinner.

The obligatory visit to the btconf in Düsseldorf followed and was as always a great experience. Especially because we were able to see the impressive fireworks of the Japan festival and we had an amazing Web Platform Doc Sprint the day before the conference.

On a weekend I travelled to Rüsselsheim (near Frankfurt) to visit a large slackline festival. That was the chance to walk new lines I’ve never been able to do before. I finally were able to try out my first highline (about 15m high, 15 long), failed miserably (could walk like 3-4 steps) but it was a great (though painful) experience.

In June, my own conference PUBKON, took place for the third time. It was a lot of effort and a great success regarding what people left us as feedback, even though we struggled a lot in advance as tickets didn’t sell too well and break-even was reached only two weeks prior to the event.

Late June, I also met with Sebastian, Hans, Simon and David to speak about making an event in Cologne. Turned out we all want to do such a thing and the result was our own front-end conference which took place in September.

In July I decided to keep on working for my biggest ever project for three more months. The only change was that I was going to work from my homeoffice most of the time and I only was in the office for the sprint plannings and reviews. This meant I had two residences to manage and travel between each during the week which is quite exhausting if you do it regularly. But to be honest, being able to work remotely worked very fine. I could start working earlier (not the usual 9 to 5 schedule as in the office) and were more flexible. I could also focus more on my work as no one could distract me, except in HipChat (which you can easily set to N/A state). And communication with my team worked very good as well, we constantly chatted, WebRTC’ed and had a lot of fun. To summarise: Working remote in a 99% on-site team worked very fine for me, even better than I would have expected.

I started August taking two weeks off and go on vacation. Initially I planned to go to Switzerland’s Berner Alps with some friends and my mountainbike but the weather was very bad and made our plans impossible (it had snow over there). So we changed plans and went climbing in the Frankenjura in Germany, a great place with many many spots and interesting routes. I climbed my first 8- at the end of the week (okay, scale is not the same as in the Alps, but still…).

September started with Reasons To Be Creative where I met great friends again and made some new and also finally went to Brighton and Cambridge. It was very nice and I can only recommend the conference, if you’re up for creative inspiration.

Only two days later I attended the Red Bull District Ride in Nuremberg which was awesome. Mountainbikers rode directly though the masses of people in the city and did amazing tricks in the air.

Then, on September 26th, another side project I had been involved in for four months took place. Together with Hans Christian Reinl, Sebastian Golasch, Simon Koch, and David Yasli I organized my first web related conference. The so called NightlyBuild conference was thought as after-work conference was a lot of effort and we managed to invite speakers such as Aral Balkan, Alice Bartlett, Ian Feather, Nico Hagenburger, Jasmin Boje and Steffen Süpple to make the evening a great experience for every attendee. In summary it was a great success and we sold out only a couple of weeks after we launched tickets. We’re currently thinking about how we proceed with this project and if we want to make it happen again.

October was the last month for my main client this year and it turned out well. The project made great progress and as of now, most things I’ve helped building launched successfully.

I then attended the second border:none conference which was made in a completely new format as a creator-conference and it did make much sense to attend it. I learned a lot of new stuff about security, privacy and the indie web.

Then I travelled to Cardiff with Hans to attend TheWeb.is, a web conference by Craig Lockford, and flew back to Berlin where the first beyond tellerrand by my friend Marc Thiele in Berlin took place. It’s always a great place to meet a mass of nice people and friends.

The last conference of the year was on the list in November: dotCSS and dotJS in Paris, France. For that, I decided to make it a short-trip with my girl-friend and while I met nice people at the conferences and learned new interesting stuff we also had the chance to visit the city and enjoyed a few days of vacation together.

In December, I got an inquiry if I could help a Munich start-up cleaning up and refactoring their historically grown codebase. Unfortunately they had already started doing it and needed me as soon as possible which meant I only could work eight days for them. But in this short timeframe I still managed to re-build the principles of their infrastructure on a new toolchain, set up stricter coding conventions and decreased their output CSS code by nearly 80% on their production site. It was also a great team with a vision of their product and I’m eager to know when their re-factoring will be finished and go live.

Also in December I took some days to work on my own projects, like WDRL to refactor the code, improve the design and readability and to figure out how to make the project at least not a loss (money wise). I’m still not finished and have big plans with it but I think I at least gave it some love it really deserves. With over 4.5k subscribers receiving a fron-end article summary each week WDRL is my biggest side-project today and I am truly humbled by all the great feedback I get for it.

For Christmas I took some days off again and enjoyed it with my family and friends. I have made a couple of new year resolutions already; I hope you’ve made some, too, and together we can start improving the world, our livings and lifes a bit more. Happy new Year! :)

But first, I want to thank all my supporters, readers and all the people who wrote the stuff I’m linking to each week. You’re all amazing!

I wanted to change something

A few months ago, after more than a year spending many hours a month on this project, I recognized that this project as it was isn’t sustainable and I might not be able to continue my work on it in future if I don’t change something.

What I invest into WDRL

To figure out what I did and what to change I needed to do an anaysis of the current amount of work. Back then I counted about 5hrs per week spending on curating the content. That means re-reading the articles and decide if they fit into the list, sorting out articles, finding new content for sections that haven’t enough articles yet, writing the letter. It also means writing it for online, then converting all the links with goo.gl for the Newsletter service so it isn’t treated as spam (hopefully), send tests, review, send the email out and publish the new issue online, on twitter, etc.

Additionally I usually spend 1hr per month working on the website (mostly fixing stuff, reviewing issues for broken links, etc.) and 3hrs in communication (Twitter and replying to emails).

That makes around 25 hours a month I am investing into this project.

Money-wise I currently invest around 10 EUR per month for the domain and hosting. As soon as I hit 5000 subscribers I need to either search a sponsor for a newsletter service or need to pay at least around 80EUR per month for the service. This actually costs me money.

Seeing these numbers clearly showed me that this won’t work forever.

Make it sustainable

The first thing everyone thinks about when trying to make money from something ‘free’ is advertising. But there are a couple of reasons why I don’t like it on my project:

• I don’t have good statistics on my readers (TinyLetter doesn’t track much and I don’t want for privacy reasons)
• I don’t like having general ads in my front-end related letter
• I don’t have many subscribers (regarding what advertising companies say)
• I don’t like having ads in a high quality product myself

So I thought about other ways to get some money in. I added GratiPay and Flattr to the project to let people support me. Flattr is used by some people to support me but is making about 2-3EUR per month which is nearly nothing. GratiPay instead works better since I added clear statements about the costs on the website.

I now receive 19EUR per week from GratiPay, making 76 EUR a month (excluding Paypal costs to get the money). Adding the donation from Flattr and Bitcoin (which doesn’t make very much at the moment) this makes roughly 80EUR per month. This would still not cover my fixed costs when I need to pay for a Mailchimp account. But it’s a start and I’m glad that I could make the project nearly a not-loss project in only a few months.

The remaining problem

The biggest problem remains. With so many subscribers (for me 4.7k is incredibly much!) I have 12 regular supporters at the moment (GratiPay shares the total amount of weekly supporters), adding 3-4 irregular supporters who donate via Flattr or Bitcoin.

This means 0.31% of my subscribers currently support this project with money.

0.10EUR per month from each reader (only newsletter subscribers) would even pay ⅓ of my work time on the project.

0.50 EUR per month by each I could cover my work time and all expenses for services with my regular hourly rate so it would be completely sustainable business.

I know it will never happen that everyone pays for it but this calculation shows how incredibly low the amount would be if more people support such projects.

Start giving your help

This is not a crowd-funding, this is not the demand to give me money. This is a plea to you: If you profit from a service, from a resource, give back. Sometimes this can mean contributing, sometimes this means money*. Whatever it is—if you love something, support it.

Finally, this doesn’t only apply to WDRL, it does to so many other services made by people like you and me.

Thanks for reading, please give me feedback (via Email or twitter) and enjoy Christmas holidays! ♥

—Anselm

• * For WDRL, see: https://github.com/anselmh/wdrl/issues
• ** For WDRL, GratiPay me or help me implementing Stripe.

Interestingly, people always share jQuery plugins, huge chart libraries if you ask them for a solution. While this is fine if you have a lot of charts to display it probably serves a lot of overhead to websites that only need to show one simple chart.

My first approach was to use the Snap.svg library which is awesome because it has built-in animations for all charts and therefore produces very nice results in nearly no time. The thing that bothered me was that the library itself is heavy with 70kb (minified, not gzipped) and that the integration of it felt a little bit akward from the coding style. That said, this is a completely personal perference that didn’t fit to me.

So I wrote it on my own. Thankfully there are a few tutorials that explain how this works. I adapted some code examples, mainly this one by David Flanagan which helped me out on the mathematic formulae, and wrote my own code:

var pieChart = function (data, width, height, cx, cy, r, colors, labels, lx, ly) {
    var svgns = 'http://www.w3.org/2000/svg';
    var chart = document.createElementNS(svgns, 'svg:svg');
    var total = 0;
    var angles = [];
    var startAngle = 0;
    var i = 0;

    chart.setAttribute('width', width);
    chart.setAttribute('height', height);
    chart.setAttribute('viewBox', '0 0 ' + width + ' ' + height);

    // Add all data values so we know how big the whole pie is
    for (i = 0; i < data.length; i++) {
        total += data[i];
    };

    // Now figure out how big each slice of the pie is. Angles in radians.
    for (i = 0; i < data.length; i++) {
        angles[i] = data[i] / total * Math.PI * 2;
    };

    // Loop through each slice of pie.
    for (i = 0; i < data.length; i++) {
        var path = document.createElementNS(svgns, 'path');
        var labelColor = document.createElementNS(svgns, 'rect');
        var label = document.createElementNS(svgns, 'text');
        var endAngle = startAngle + angles[i];
        var x1 = cx + r * Math.sin(startAngle);
        var y1 = cy - r * Math.cos(startAngle);
        var x2 = cx + r * Math.sin(endAngle);
        var y2 = cy - r * Math.cos(endAngle);
        var big = 0;
        var d;
        var labelShare = Math.round(((data[i] / total) * 100)) + '%: ';

        if (endAngle - startAngle > Math.PI) {
            big = 1;
        }

        d = 'M ' + cx + ',' + cy + // Start at circle center
        ' L ' + x1 + ',' + y1 + // Draw line to (x1,y1)
        ' A ' + r + ',' + r + // Draw an arc of radius r
        ' 0 ' + big + ' 1 ' + // Arc details...
        x2 + ',' + y2 + // Arc goes to to (x2,y2)
        ' Z'; // Close path back to (cx,cy)

        // Now set attributes on the <svg:path> element
        path.setAttribute('d', d);
        path.setAttribute('fill', colors[i]);
        chart.appendChild(path);

        // The next wedge begins where this one ends
        startAngle = endAngle;

        // Now draw a little matching square for the key
        labelColor.setAttribute('x', lx);
        labelColor.setAttribute('y', ly + 30*i);
        labelColor.setAttribute('width', 20);
        labelColor.setAttribute('height', 20);
        labelColor.setAttribute('fill', colors[i]);
        chart.appendChild(labelColor);

        // Add label to the right of the rectangle
        label.setAttribute('x', lx + 30);
        label.setAttribute('y', ly + 30*i + 18);
        label.setAttribute('font-family', '"jaf-bernino-sans", sans-serif');
        label.setAttribute('font-size', '16');

        // Add DOM node for the text to the <svg:text> element
        label.appendChild(document.createTextNode(labelShare + labels[i]));
        chart.appendChild(label);
    }

    return chart;
};

// ServicesChart
var serviceChartWrapper = document.querySelector('#chart-a');
var serviceChartData = [80, 10, 2];
var serviceChartColors = ['#017E61', '#01A57F', '#02E4B0'];
var serviceChartLabels = ['Label 1', 'Label 2', 'Label 3'];
var servicesChart = pieChart(serviceChartData, 450, 200, 100, 100, 100, serviceChartColors, serviceChartLabels, 220, 50);

// Append Charts to DOM
if (serviceChartWrapper) {
    serviceChartWrapper.appendChild(servicesChart);
};

View the whole file here. The script generates a SVG pie chart and takes variables for the data (that is used to cut the slices), label descriptions and colors for the slices. For sure this isn’t the most flexible solution and the code could be abstracted a lot more but I really wanted to cut file size down and create it to display a few pie charts and nothing more. It’s as small as 2kb (minified, not gzipped) so it saved me about 68kb. Of course, it lacks of the chart animation for example but this wasn’t my goal.

Hopefully that short article and script helps you a little bit. If you have improvements or suggestions, just let me know via Twitter or E-Mail!

Preparations

Nearly none. Except you need to change your nameservers to Cloudflare nameservers so they can handle your requests. This can take up to 48hrs to be distributed to the nameservers over the world.

You also need:

• Free (or paid) Cloudflare account (if you use SharedSSL)
• A paid MaxCDN plan (but anyone of this will work if you use SharedSSL)
• A hoster which let’s you target your domain’s Nameservers to Cloudflares Namerservers (not all do)

Enable SSL and SPDY

Uhm, that was literally the easiest thing. Just sign in to your accounts, enable shared SSL options, enable SPDY / HTTP/2, too, to get the speed boost.

For MaxCDN, go to manage your pull zone, switch to the EdgeSSL tab, enable Shared SSL and SPDY in one go. You now need to rewrite all your URLs to be protocol relative (i.e. /) and to use the new SSL enabled hostname (it’s different if you don’t use custom domain and custom SSL). It took my 1 minute.

For Cloudflare, it’s a bit more complicated (by nature) as you have more options. First, set up your domain and target your domain to the new nameservers. You now adjust your settings. I chose low security profile, IPv6 support (yay, “full-in”), Pseudo IPv4 off, SPDY 3.1 on, Always online, and flexible SSL on. You want to disable RocketLoader if you’re using SPDY, and depending on how you deal with assets you also don’t want to let them minify your JS, CSS.

Drawbacks

As currently I’m only using a shared SSL option this means in some browsers users get a warning that the certificate doesn’t match my domain name. Some very restrictive, old proxies therefore will not show my site anymore without adding an exception. And, as I haven’t enabled IPv4 fallback, the user needs to support IPv6 to visit my website.

Well, that’s it. Nothing special, it was very easy. Try yourself and secure your site!

Further options

• GitHub Pages: Yup, that’s where my content lies. To redirect your http pages to SSL you need to set up a page rule in Cloudflare. Just set the pattern to http://helloanselm.com/* and add the rule Always use HTTPS: on.

• Get your own certificate: This avoids non-matching domain issues in browsers and can be even more secure. But in that case you’d need a paid Cloudflare account and also (if applicable) a paid premium MaxCDN account.

If you have a look at this example:

@media only screen (min-width: 43em) {
    /* Your CSS here */
}

This of course will work on your smartphone, tablet and desktop as expected. But if won’t apply if you, for example, print the page. Because you’ve limited the query to only apply to screen.

Did you really intend that? I guess not. It’s more effort to write and limits you. Instead, write this:

@media (min-width: 43em) {
    /* Your CSS here */
}

This will apply to all media types, even print. The cool thing is, all your adaptions for mobile will also apply to printed stuff. Because no, DIN A4 isn’t the only format people will print. Some print C4, DIN A5 / A3 or a totally different paper format and you layout will adapt accordingly.

Caution: The following technique is a proof-of-concept that might have a heavy impact on your CPU & GPU. Please do not ever use this technique in real / client projects until the performance issue has been resolved.

The Demo

Please wait a bit until the video starts playing. Embeded demo takes a little bit… works currently best in Chrome (Canary).

See the Pen Fullscreen Video Hue by Anselm Hannemann (@anselmh) on CodePen.

The HTML

The HTML is pretty straight forward. As the <video> element (just as <img>) don’t support pseudo elements, there’s no way to do this with just one element. If you fancy this solution to be ugly, feel free to create a web component including this source so it’ll be hidden in the ShadowDOM. Instead, use a simple video element with a source child (in this case only one but be sure to add more to support all browsers) and an empty div element. The 2nd element is only presentational which might not be ideal but as it doesn’t contain any special role or content in it, it doesn’t harm either regarding accessibility or similar.

<video controls="no-controls">
    <source src="http://media.xiph.org/mango/tears_of_steel_1080p.webm">
</video>
<div class="videohue"></div>

The CSS

Regarding the CSS, an animation is needed showing your animated hue on the video. Use autoprefixer to make it working in older browsers that only support a prefixed animation syntax. Further on, set up your hue element to match the size of the video by positioning it absolutely above the video element, stack it over it and call the animation. Done.

/*
 * The Animation
 */

@keyframes colorize {
    0% {
        background: rgba(255, 0, 0, 0.5);
    }
    25% {
        background: rgba(0, 255, 0, 0.5);
    }
    50% {
        background: rgba(0, 0, 255, 0.5);
    }
    75% {
        background: rgba(0, 115, 115, 0.5);
    }
    100% {
        background: rgba(125, 0, 115, 0.5);
    }
}

/*
 * Create the hue effect
 */

video {
    position: relative;
    width: 100vw;
    height: 100vh;
    object-fit: cover;
}

.videohue {
    display: block;
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    z-index: 10;
    animation: 20s colorize infinite both;
}

So this is the explanation for this cool effect but as written initially, using current machines and browsers this causes heavy performance issues so you shouldn’t use it in production. If you want to have this effect now, please read the next section…

The proper way to do it (currently)…

It’s simple: Just do the hue animation completely in the video editing / post-processing app of your choice (e.g. Adobe After Effects). This way, there’s no performance impact at all as you’re pre-processing the whole video colorizing effect in prior. But maybe some day we’ll have powerful enough machines and able to work with such techniques.

Final words and other experiments

There’s not much to add to it. Except, I played around a bit more and here is another demo I want to show you. Currently does only work in Chrome. Thanks to Tears of Steel for the open source video material.

See the Pen Fullscreen Video Hue by Anselm Hannemann (@anselmh) on CodePen.

(CC) Blender Foundation | mango.blender.org

Both, WHATWG and W3C landed patches in the past week including the <picture> element and its attributes to the HTML5 specification.

And here are the specifications for each on WHATWG and W3C sites:

• WHATWG <picture>
• WHATWG srcset
• WHATWG sizes
• W3C <picture>
• W3C srcset
• W3C sizes

This is the official part, the living standard is always to be found at picture.responsiveimages.org to which you can submit bugs and issues on GitHub via RICG.

This is a good point to say thank you to all who are involved into Responsive Images work. Special thanks goes to:

• Mathew Marquis, the chairman
• Marcos Cacares, the one who fought for it in the webstandard consortiums
• Yoav Weiss, the one who made all possible (technically, implementation-wise)
• Geri Coady, who did the design work
• Simon Pieters, Tab Atkins, Matthew Wilcox, Bruce Lawson, Eric Portis, John Schoenick, Robin Berjon, Adam Bradley, Jason Grigsby, Scott Jehl, Kornel Lesinski, David Newton, and a whole lot more people who are all awesome!

Long awaited, discussed over the past three years, a webstandard for responsive images will be usable in new browsers by mid of the year. The <picture> element and srcset, sizes will be the thing to use when you need to serve images in different sizes and resolutions.

The Future

With Chrome (therefore Opera) and Firefox supporting Responsive Images two major browser vendors support the webstandard. But still, two other big players are still missing: WebKit (Safari) and Internet Explorer.

WebKit / Safari

The RICG recently crowd-funded the implementation for Blink and WebKit. That means, Yoav Weiss has not only put massive work into the Blink implementation but has already started porting the codebase to WebKit, too. Hopefully, WebKit will approve the patch and therefore get Responsive Images as well.

Internet Explorer

FThe Internet Explorer team officially can’t say anything specific, but at least has both, <picture> and srcset ‘under consideration’ which is a good sign. Also, if three of the four big players will support it, they will likely follow up soon.

After three years of much trouble, many discussion and frustration this makes me very excited! Thanks to all the people supporting me, RICG and other people helping us making this dream become true.

Learn more

• Chris Coyier’s Screencast: Figuring out Responsive Images
• Martin Wolf’s blog post: The new srcset and sizes explained
• The whole picture about <picture> and srcset and everything else by the Responsive Images Community Group

See how to set up and configure PhantomCSS in the official docs and read how to write basic tests. (I’ll not explicitly cover this but focus on my advanced test)

TL;DR;

The following is a test case to find regression bugs in your component including CSS states like :hover, :active, :visited. This shows a basic test case that shows the general approach, not every single state in detail:

casper.start('http://localhost:8001/test/visual')
    .then(function () {
        phantomcss.screenshot('.selector', 'screenshotname');
    })
    .then(function () {
        this.mouse.move('.selector a.button'); // Trigger :hover state
    })
    .then(function () {
        this.mouse.down('.selector a.button--large'); // Trigger :active state
    });

casper.on('mouse.move', function(resource) {
    phantomcss.screenshot('.selector', 'screenshotname-hover');
});

casper.on('mouse.down', function(resource) {
    phantomcss.screenshot('.selector', 'screenshotname-active');
});

The Explanation

So what does it do? First, we start by creating a new instance of Casper with casper.start(). We add our location as parameter—in my case I started a server on port 8001 via grunt-connect and point it to my comonent’s visual test file.

You then can add your chain of actions / tests which should be executed by CasperJS. The then() function makes sure this is done in the given order as by default Casper handles things asynchronously. Inside, specify your test case. This can vary from simply creating a screenshot (like in the example above) up to a complex JavaScript test to trigger JS driven actions in your component. phantomcss.screenshot() creates a screenshot at the configured screen size (configuration is done in the grunt task).

Now the interesting part is when I say to move the mouse to a specific selector. This lets me trigger a :hover state as the mouse is now over my element with the styled hover-effect. The problem is, simply doing a screenshot now wouldn’t work as for whatever reason, the hover state isn’t triggered when PhantomJS makes the screenshot.

So I investigated searching for solutions, found many misleading but similar questions on Stack Overflow. Finally, after reaching out on Twitter, Ian Feather pointed me to the CasperJS Events, by luck. And, he was right. In fact, you need to listen to the mouse event with a casper event listener and then trigger the screenshot:

casper.on('mouse.move', function(resource) {
    phantomcss.screenshot('.selector', 'screenshotname-hover');
});

Looks easy, didn’t you know that?

This isn’t a big deal I think but still I didn’t found a single resource leading me to this solution to I thought to better write this down for everyone.

Hope you find it useful and if you have feedback, please let me know on Twitter or via E-Mail.

Please be aware this post is written as of April, 2014 and things might have changed when you read this post. You find the links with the proper information right here in the article.

Update: As of end of April, GitHub again updated their gh-pages infrastructure and wrote about it on their manual page. Check it out how to properly configure your custom domain to avoid the effect described here.

While I already wrote about problems with using GitHub pages as a CDN to serve static files I always was pretty convinced of the world-wide load performance with GitHub pages. As I optimized my website’s performance last week, I got a tweet from Andy Davies telling me a strange behavior about the initial load of the page:

@helloanselm @WebPerfNews 1st waterfall redirect pattern seems quite common with GH pages

— Andy Davies (@AndyDavies) March 30, 2014

I never have discovered this and it does not affect everyone. But as I could confirm it in the Webpagetests for 1st load, also from another location it bothered me so I reached out to the awesome GitHub support.

Only a few hours later I got the answer to this behavior:

What you're seeing is an intentional 302 redirect for GitHub Pages. Our DDoS mitigation technology samples the HTTP traffic in order to detect bots and DDoS precursors, and issues HTTP 302 responses to smoothly redirect users that are not bots.
This particular redirect activity only happens for GitHub Pages with custom domains that are set up with DNS A records pointing directly to our Pages IP addresses. In order to avoid the redirects, you could use a sub domain, e.g. blog.example.com, instead of an apex domain, e.g. example.com, as a CNAME for your GitHub Page. This sub domain will be backed by our Content Delivery Network and won't return a 302.

This behavior is also somehow documented in the Github blog under Faster, more awesome Github pages and Setting up custom domains with pages.

Comparing GitHub Pages to local hoster

Yesterday I got a newsletter from MaxCDN, the provider of my CDN, with announcements of new tools. They now offer a tool to compare the ping of two sites but also the first and last byte of two websites.

This came in handy to compare the first byte times between my local dealer site and my GitHub site leading to the following result which I already anticipated:

While my locale provider is much faster serving the site in my own country, GitHub does a far better job even with the redirect if you look at the request response time from e.g. Asia or America. Due to the long distance to Germany (where my local provider serves the site from) it’s much faster to go to Githubs Firewall and Servers which serve from their ‘always local’ servers than going the long distance half around the world.

What does that mean now?

If you use GitHub pages with custom domain depending on your configuration it might happen that people will experience a redirect and therefore a long response time before they can see your website.

If you are serving a locale community this means you might want to avoid using GitHub pages (state April, 2014) for your site. But if you’re serving a global community, you still might go better with GitHub pages than with your local provider. So as so often, it depends who’s your target audience.

Be aware that the following technique will only work if you have a SVG file of the font.

A common problem with iconfonts is that an icon is somehow related to a unicode character. Usually you display icon using pseudo-elements in CSS requiring the unicode of the character. But how do you determine what icon is used on which character code if you are not the creator of the font?

In a current project we use a lot of components and write visual tests for each of them. Except, the iconfont hadn’t had a proper one. For that test I needed to display all characters of the font somehow but didn’t know (and don’t want to) how the characters are referenced. But more importantly, I thought, would be extendability, when later on, characters are added.

How I came to my solution

This was the time when I thought about somehow it must be possible to parse a webfont to get that information or, worst case, running through a unicode table and show the results where applied. Fortunately the latter isn’t needed as we have a SVG font. SVG is written as ‘readable’ markup and so is a SVG icon-font. Each character has a DOM node with attributes and the vector points that define the character. And here we start:

The SVG WebFont

The following code snippet is a sample of a character from an SVG icon font:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" >
<svg xmlns="http://www.w3.org/2000/svg">
    <defs>
        <font id="vsir-iconfont" horiz-adv-x="250" >
            <font-face units-per-em="100" ascent="80" descent="-20" />
            <glyph unicode=" " horiz-adv-x="50" d="" />
            <glyph unicode="!" horiz-adv-x="100" d="M83.522656250000011
              38.628515624999999 C85.970996093749989 38.628515625000006
              90.867675781250000 38.628515625000006 93.316015624999977
              38.628515625000006 C94.026953124999977 38.628515625000006
              94.737695312500023 z" />
        </font>
    </defs>
</svg>

The interesting part here is the <glyph> element which wraps each character and its attribute unicode="!". We now have an identifier to get every glyph of the font (the DOM element) and its unicode reference which here is our unique identifier (as a font can only have one glyph for one unicode-expression).

Displaying the Icons in our HTML

To display the font icons we need three things:

1. The HTML Markup
2. The Scss/CSS styles that actually display the font through generated content
3. The JavaScript that dynamically fetches all available glyphs of the font

The HTML

Easy. Besides the reference to our CSS Style Sheet in the head of the HTML we only need two lines of HTML:

<div id="svg" style="display: none;"></div>
<table class="icons">
    <thead>
        <tr>
            <td>Symbol</td>
            <td>Unicode (CSS)</td>
        </tr>
    </thead>
</table>

The first is the container where we want to load our SVG font into to read the DOM. We will do this via AJAX load to ensure the font is loaded when we run our additional scripts through it. I tried some things with iFrames (objected because of no cross-browser seamless support) and <object> (didn’t work too good and I don’t like using the object element) but in the end the scripted solution works best for automated tests in my opinion. As we only want to access the DOM but don’t want to see the DOM we need to add the display: none; attribute here. The second, the <table> element, is where we want to display our icons along with the corresponding unicode character.

The Scss/CSS

First, we want to include our webfont with the CSS3 @font-face rule. This is an example using Scss as preprocessed CSS language.

@font-face {
    font-family: iconfont;
    src: url('iconfont.eot');
    src: url('iconfont.eot?#i') format('embedded-opentype'),
         url('iconfont.woff') format('woff'),
         url('iconfont.ttf') format('truetype'),
         url('iconfont.svg#') format('svg');
    font-weight: normal;
    font-style: normal;
}

We now want to display all the things so we need to add the unicodes that are available through the SVG DOM as generated content.

// CSS Code here
td {
    font-family: iconfont;
}

The JavaScript part

I use jQuery here but if you don’t need to support older browsers you can easily replace the jQuery methods with the native ones.

$(window).load(function () {
    var svgns = 'http://www.w3.org/2000/svg';
    var svgUrl = '../fonts/iconfont.svg';

    $('#svg').load(svgUrl, function (svgUrl) {
        // Insert content of the SVG file in our invisible DOM node
        $('#svg').append(svgUrl);

        // Find all glyph nodes in the SVG file
        var svg = $('svg').find('glyph');
        // Add unicode escaping for CSS
        var unicodePrefix = '\\';
        var iconOutput = '';
        var icons = [];
        var i = 0;

        for (i=0; i < svg.length; i++) {
            var unicode = svg[i].getAttribute('unicode').toString();

            icons.push(unicode);
        }

        for (i=0; i < icons.length; i++) {
            var iconChar = icons[i].charCodeAt();

            iconChar = iconChar.toString(16); // Convert to string format
            iconOutput += '<tr><td class="icon--' + icons[i] + '">' +
                            icons[<i></i>] +
                            '</td><td><code>' +
                            unicodePrefix +
                            iconChar +
                            '</code></td></tr>';
        }

        $('.icons').append(iconOutput);
    });
});

The Result

I’ve created a JSBin demo using the FontAwesome icon font used by Bootrstrap. Note: As I’m relying on an external CDN here, I hope this demo still works when you view it.

JS Bin

Why?

If you’ve ever been reading your timeline viewing a blog post that includes a codepen while on the train you might already know why. All of the code snippet services are heavily relying on their own JavaScripts. If they can’t be loaded or the service is offline as a whole, the whole blog post can be useless as the core of it, the source code, isn’t loaded. That is why we want to avoid fully relying on JavaScript and instead provide a fallback when JavaScript isn’t available.

How?

The good old <noscript> element comes into handy. While many of the sharing codes already include some noscript content, it often only contains a HTML link to the code-snippet itself again. This is not very useful and it would be a much better user experience if a user could still see the whole code and result. The only difference in fact should be that the live code-example might not be available. But all important code is available. All the time.

Format the fallback content in a way that users will not recognize anything went wrong.

Here’s how a possible CodePen implementation could look like:

<p data-height="268" data-theme-id="0" data-slug-hash="djbmp" data-default-tab="result" class='codepen'>See the Pen <a href='http://codepen.io/anselmh/pen/djbmp'>Drop shadow for 2 elems preserving the intersection</a> by Anselm Hannemann (<a href='http://codepen.io/anselmh'>@anselmh</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
<script async src="//codepen.io/assets/embed/ei.js"></script>
<noscript>
    <h3>HTML</h3>
    <pre><code>
    <div class="block">
        <div class="innerblock">
            <p>Content and other markup</p>
        </div>
    </div>
    </code></pre>

    <h3>CSS</h3>
    <pre><code>
    body {
        background: black;
    }

    .block {
        width: 80%;
        margin: 1em auto;
    }
    </code></pre>

    <h3>Result</h3>
    <img src="result.png" alt="Your alt text here">
</noscript>

This, of course, works also with JSBin, and all other services that provide embedded snippets relying on scripts to show them.

Be a good example

When you are including a code snippet you try to teach people something. Therefore you already want to be a good example how to make things on the web for other people. Make the experience for your users even better by regarding no JavaScript users (you know it’s mainly not those who disable it but people on wireless networks)! The users will thank you…

See the Pen Drop shadow for 2 elems preserving the intersection by Anselm Hannemann (@anselmh) on CodePen.

Feel free to use it on your page, fork it or leave a comment on the pen.

As a variant you could also use pseudo-elements to add the box shadows on the left / right side. Also, the code for positioning the coherent boxes is only for demo—not necessarily the best for your use-case.

Variant for a flexible handler

If you don’t know the exact width of the toggle button you can achieve the centering of it in a different way. Please note that this won’t work in older browsers like IE8:

Instead of setting a margin on the element, put a CSS transform on it (and don’t forget to add applying prefixes).

.block_toggle {
  transform: translate(-50%, 0);
}

I hadn’t any clue how to track down media query evaluation of a browser (you can’t do that with DevTools), except forking the core and adding timers to it (which is no option as I don’t know any C++). So the logical step for me was to ask engineers on twitter about it:

Do you know if there’s impact on CSS evaluation performance if CSS has 10 or 100 Media-Queries inlined? +@yoavweiss @addyosmani @paul_irish

— Anselm Hannemann (@helloanselm) January 15, 2014

@helloanselm If there is a measurable performance impact, I'd consider it a bug :)

— Yoav Weiss (@yoavweiss) January 15, 2014

@helloanselm In theory, it sure seems like it. Might be worth trying to measure, tho (If you have the time & will to do so)

— Yoav Weiss (@yoavweiss) January 15, 2014

A look into the source

This is a pretty theoretical but still helpful answer because it led me to the next step: Have a look at the source. In times where everything is on GitHub it’s easy to dig into the source of anything that is open-source. WebKit and Gecko are, so their source code is to be found on Github.

Both engines do serialize and strip out duplicated media-queries so they only need to evaluate each media query once. Also they cache the queries so that they can re-use it later on. You can view source of WebKit or Gecko here.

Of course this doesn’t mean there is no difference but looking at the source there shouldn’t be a performance issue. Also, I guess there is no performance lack when evaluating hundreds of different media queries that is recognizable / measurable.

Conclusion

It doesn’t matter if you use one big or multiple media-queries in your code assuming your values are mostly the same. It shouldn’t matter if your values are different for each(!) of your hundreds of media-queries but could affect performance (found no way to track this down). The only thing I could add here is that using many inline media queries often is that they’re increasing the size of your CSS (unless your gzipping it) and that affects performance as it’s loaded blocking.

So all in all, happy media-querying!

Update / Clarification collected from feedback

It does matter how many different media queries you use on the site when you’re resizing the browser window. This can cause a massive CPU and memory load which even can crash your browser but as this is not a valid performance test (no user constantly resizes its browser, we should always focus on non-rezining events only). Also, these experiences sound really as they are a buggy behavior (which somehow is seen in the comments in source code).

Wow. I am nominated for the netawards 2014 as Young Developer of the Year. This is huge and when I read this first I couldn’t believe it. I’m still totally stoked about the support and only can say “Thank you for your support!”.

Of course I’d be happy if you give me your vote:

Vote for me

Thanks again to anyone who nominated me and to everyone who will vote for me. You’re all awesome. ♥

About two years ago Adobe presented a new technique to the world: CSS Regions. They provide what has been possible in layout applications for decades now. With Regions it’s possible to let text flow into or around vector shaped paths. To present the new technique, Adobe implemented it into a fork of Chromium (which is WebKit/Blink driven). Since then, a webstandard has been written and is currently available as Editor’s Draft. Microsoft implemented Regions into Internet Explorer 11 (-ms-prefixed), Safari implemented them into Safari 7 and iOS7 with -webkit-prefix.

Håkon Wium Lie, one of the founders of CSS, wrote a very opinionated article in which he states that CSS Regions are considered harmful for several reasons. I will list them in short here:

• “Regions use Dummy <div>s”
• “Regions are not responsive”
• “Confusing text flow”
• “Verbosity”
• “Code reuse”

Quite a list, right? The problem is, they’re simply not the full truth. As many opinion pieces or articles stating something is “harmful” it only shows one perspective. In this case, against CSS Regions.

But let’s face the issues and track them down.

First, as I already mentioned, CSS Regions are currently an Editor’s Draft. This means, they are not a standard yet and it also means, they need to be improved to become a standard. This alone implies that the current status will have some issues but it also implies they’re likely being fixed soon.

Additional markup

I am absolutely no fan of unnecessary, presentational code in our markup. This was the first thing I didn’t like about CSS Regions when I saw them first time in London, two years ago. But I know, currently there is no real way to get around that with the current toolset of CSS. Adobe wants (or wanted?) to tackle that apparently—they started writing on CSS Pseudo-Elements Level 4 in 2012. Unfortunately there hasn’t been any progress since then.

For me (personally), CSS Regions is considered ‘hacky’ as long as they need additional presentational markup. But bear in mind, it’s not CSS Regions’ fault but only a dependency on the extension of the Pseudo Elements spec.

Responsiveness

If you look at Adobe’s CSS Regions demos they’re all the same: Great looking layouts that are presented to the users on a big screen. But they never (at least in the four presentations I’ve seen) showed them to work responsively. In my opinion, this has been one of the biggest problems of CSS Regions—Adobe not showing how this works while everybody is talking about Responsive Web Design. They missed an opportunity here but gladly Brian Rinaldi wrote an article how to use Regions in a Responsive Design. You see, this is not impossible.
I still think CSS Regions’ responsiveness is not very good but it’s not impossible to get it work and there’s always room to improve it.

The Confusing Text flow

Well, I won’t write much about this but looking at Håkon’s example images I realized this is completely only his opinion. I find his proposal massively confusing and like the current spec much more. So this is highly debatable.

Verbosity

A good call. Verbosity seems to be the latest thing to kill new webstandards. It was the same for the <picture>-element before finally some more people realized that verbosity often also means simplicity. And, in my opinion, webstandards should be simple to follow and to understand.
Seeing this from a performance view, gzipping the webpage should make this a non-issue very easily. And you should serve your page gzipped anyways.

Code Reuse

CSS Regions style currently isn’t appliable to any new page and text. This is true but is that what we want when we use CSS Regions? I don’t believe so.

Why Blink is dropping it

After some thoughts on where Regions stand today and what they can or cannot do, I now want to explain why Blink engineers decided to drop CSS Regions from their engine.

When you look at the things where Blink should go in 2014, it is mainly speed and performance. The reason why Blink dropped CSS Regions is because they currently perform badly in Blink. I don’t know much more details about the implementation but I know that IE10/IE11 and Safari 7 are super fast browsers and they implemented CSS Regions in there. Therefore I believe it is an issue with Blink alone but that shouldn’t matter.

It is totally reasonable to drop an highly experimental technique which is not a finished webstandard yet because of whatever reason. It might not always be great for people who are working and fighting for that feature but you can’t deny that a fast changing specification can cause massive workload and problems.

I am not suprised that CSS Regions have bad performance. They are a powerful toolset which requires massive calculations and of images and text along vector paths. Now apply this for a responsive design and imagine how this can affect a browser’s performance…

But isn’t it just rational to drop such a feature if it doesn’t work right now and is still experimental? In my opinion it is.

What surprised me was people starting to say “As Blink drops CSS Regions all is lost now and it’s going to die as a standard now”. Regions won’t die just because Blink drops them for the next time. Regions are still important. Blink is only one engine and there are many others that support the development of Regions right now. Keep on improving the webstandards.

If they’re good enough and perform well, I’m sure they will get implemented sooner or later. The best thing you can do is to improve the spec, test cases, file bugs and improve the webstandards and proposals itself. Thanks for caring!

Facts / Tech Data:

• Apple MacBook Pro Mid 2010 (6,2)
• Intel Core i5 2.4GHz
• 15.4 inch display with 1680 x 1050px
• 8 GB RAM
• NVIDIA GeForce GT 330M with 256MB GDDR3 & Intel HD Graphics with 256MB shared SDRAM
• Mini DisplayPort
• NO CD/DVD SuperDrive
• 120GB Kingston Hyper X SSD (use this as OS X disc)
• 320GB HDD (the default Apple one)
• only 51 Battery Cycles!
• Runs Mac OS X 10.9

Price

As this thing is in a very good condition and I only sell it because I don’t need it, I want to have 950 EUR excl. VAT and shipping. This in my opinion is a very fair price and is based on official calculations by several online sellers. I will include a nice bag for it, too. Of course power adapter will also be included.

Pictures

If you want additional photos, please ask.

In January 2013 I had the opportunity to speak at the newcomer conference TakeOff in Lille. It was a super-cold but an amazing time there: The hosts, all the other people and the beer were just lovely!

Next up we all met in Berlin to document the Web at the Web Platform Doc Sprint:

A few weeks later during deepest winter I travelled to Vienna where jQuery Conf Europe took place at the impressive location Palais Liechtenstein.

Just two weeks later the first UX Munich Conference opened its doors where I had the pleasure to listen to some great talks. I also did some conference notes:

In March I decided to get a new digital camera. I wanted to take more photos than before again and therefore wanted to have a digital cam (previously I only had several great old analog cameras). So I bought a Fujifilm X-E1.

Now followed two weeks Bouldering in Fontainebleau, a camping vacation with my friends that simply was so enjoyable that it's hard to describe. After an exhausting 2012 these 10 days off were solid gold for my work motivation (and for my bouldering skills).

Right back from vacation the final preparations for my own conference—the PUBKON—went on. The conference itself, done the second time in 2013, gladfully was a huge success and we had an amazing time with all the attendees and speakers in Berlin.

Because I’m a bit silly, I spontaneously said ‘Yes’ when I was asked by the usual German conference crew if I wanna join on FrontTrends just two days later. Directly from Berlin I took the train to Warsaw which is a super lovely city I definitely want to visit again. The food, beer, and weather was great as was the time I've spend there…

Back at home I finished to build my DIY shelf made out of wine-boxes. Easy, but damn cool!

Summer came to Germany and I started to improve my Slackline skills and had very much fun with the guys from Munich who are much better than I.

In May I went to Düsseldorf to attend to the beyondtellerand conference which is always one of the best events I’ve ever been to.

When we (Jay, Christian, I) got nominated for the netawards at the end of 2012 with our non-profit platform OpenDeviceLab.com we never thought we’ll be part of the ceremony. In fact, we got invited, and took it as a chance to visit London again—a great city by itself.

By luck I met Alex Duloz there, who sports The Pastry Box Project and we had a nice talk during breakfast. He’s a great guy I definitely want to see again soon. I also wrote a piece for TPB later on which is to be found here.

Most weekends I’ve spent at home, I forced myself to go outside. I went hiking, climbing, Mountainbiking or Slacklining in the Mountains to re-fuel my power:

During the week just in the evening I sometimes tried to walk on a Waterline (that is a Slickline rigged over a river or lake) but I wasn’t too successful except that it cooled me down often ;)

In June finally I got my first printed book which I wrote with two other authors.

Back then I decided to move the Reading Lists from my blog to a separate project, now called WDRL. I started the project with just a few readers, but the last months it grew massively and I’m stoked about the success of this project.

When the X-Games came to Munich I had to watch the Mountainbike Slopstyle event and took some photos.

August brought me a new Mountainbike which I completely built up manually from scratch with custom parts and all that cool stuff: With the new bike, a few tours had to be made:

The last week in August and the first week of September I spent in the Provence, France for vacation. It was a really relaxing time enjoying the beauty of the nature. The last day of the trip was my birthday and so we went home driving through the Alps enjoying the beauty of mountains:

Back home for one day, I packed my stuff to get back to Switzerland only one day later. I had the pleasure to speak at the Swiss Publishing Days in Winterthur near Zurich.

Only a few days later, I was on my way to Bologna (by train) to head to From The Front conference which is super lovely each time.

This time I added four more days to the Italy trip so I could explore a bit of Italy. I first went to Manarola, a very beautiful place in Cinque Terre. I enjoyed the last bits of summer by sitting at the coast, visiting the area and trying out Sea-Kayaking. Then, for one day, I went to Florence, which is also a very nice city I enjoyed much during this short stay.

2013 has really been an eye-opener to me. I changed lot of my habits to work, to life and to think. I have written down some parts of these changes, and while they may not work for you, here is the list of articles:

• Working on the Road
• How Sharing is Part of my Job
• The Value and Importance of Content
• Live with less things, donate what you don’t need. I cleared my book shelf and spend them to people who needed them.
• Sport and Outdoor activities are really important to me.
• Take it easy.

In October I went to Nuremberg for the border:none conference which was a small event hosted by Marc Thiele and Joschi Kuphal. It was super cool but also the very first ODL Admin Meetup took place the day after which for me personally was a very important day as we could discuss how Open Device Labs can work, how they should work and how we could help each other with the ODLs.

The day before the conference I went bouldering with Dirk:

In Munich, I spoke at the WebTechCon 2013 about “We’re not There Yet”.

Days later, I gave a slightly modified but similar talk at the super cool MODxPO EU 2013 in Cologne. It was really a pleasure to speak to all the attendees there.

When I came back from Cologne, my colleagues and me moved to a new office space in Munich. The new bureau is much bigger than the old one and so much nicer that I enjoy being there all the time since we moved there.

On November, 20th Hans-Christian and me finally launched the INIT Project which is a Front-End Framework to help you using a solid and good workflow.

Only days later, my first official polyfill—the CSS object-fit Polyfill—went live with the massive help by Christian Schäfer.

In December I again went to Düsseldorf for the Play & Make Conference which gave me much inspiration and had super awesome talks.

2014

Last but not least, some news: Starting in January I will move to Cologne for around six months. There is a new job waiting for me with some cool people and new challenges and I am happily awaiting to live in another city for half a year. If you’re near Cologne, send me a message.

I want to do better

Surely there are things I want to improve in the new year. 2013 was awesome, I managed to improve my work-life balance a lot and cannot complain what I achieved. But without improvement it would be boring so I have the following plan:

• Travel to new places (maybe outside Europe)
• Do different conferences than the usual ones I attended several times now
• Improve time management for my work
• Improve JavaScript skills
• Speak at conferences again
• Work on my project ideas finally
• Do more sport

Wish you all the best and a good start into 2014!
Anselm

img {
    max-width: 100%;
    height: auto;
}

But there is more than that. You may want to set an foreground image to fill its wrapping element, containing its intrinsic aspect-ratio and also want it to be repositioned always to center. Or, if you ever wanted to resize an iframe responsively in its initial aspect-ratio you might got into real trouble. Of course there are fixes for that kind of problem, too, but they all in all one can say:

Media resizing behavior is outta control!

Let's fix that

Yes, we're going to fix this now. There's a webstandard for it, it's the CSS property called object-fit. With that you'll set an media-element's size like you've been able to set for background images via background-size for a long time now. object-fit can have the following values:

img {
    /* Fills image into the parent element so it's fully covered. Contains aspect-ratio. */
    object-fit: cover;

    /* Fills image into the parent element so the img is fully shown. Can create letterboxes. */
    object-fit: contain;

    /* Fills image into the parent element so it's fully covered. Shrinks image, not respecting aspect-ratio. */
    object-fit: fill;
}

But browser support is as following:

| Browser | natively? | |----------|------------| | Internet Explorer | - | | Google Chrome | v31+ | | Firefox | v36+ | | Safari OS X | 7.1+ | | Safari iOS | 8+ | | Opera | v19+ |

Fix the browser support

As the browser support is not that good I wanted to have a interim solution. If you wanna depend on jQuery there also is a polyfill. The problem is, this polyfill isn't that performant as it calculates the image sizing live at runtime.
When I started to write a vanilla JavaScript polyfill I realized the very same problem. While the solution I chose kind of worked, it didn't please me. Fortunately, when I asked Christian Schaefer for a code review, he came up with a much smarter idea.

Christian rewrote the whole code to work with CSS classes that are applied via JavaScript depending on the current 'situation' / 'state' of the image in a container. Additionally we wrap an x-tag around the image element to be able to apply a CSS-only style solution. This way there's no need to constantly calculate sizes of the image to drastically improve the performance of the polyfill.

Well, enough said—check out the object-fit Polyfill on GitHub. It's also available via bower and npm. Simply enter the following into your command line:

npm install object-fit

or

bower install object-fit

And this will get you the polyfill as a component. By the way, there is no need for Modernizr. We have a neat and very small feature-test baked right into the polyfill.

Thanks to Christian for his great support and contributions!

-Anselm

What is INIT?

INIT is based upon HTML5 Boilerplate and adds more structure for SCSS files, JavaScripts, includes build tasks and a whole lot more.

Learn more

You can read more about the project in the official docs.
If you have questions, ask me via E-Mail or Twitter. Happy to hear your feedback!

It grew and outgrew…

Now, four months later, I have over 500 subscribers who receive and enjoy my weekly link lists. This is amazing but I wasn't satisfied with the current workflow and solutions. Until this week, users had only the option to get an email or read online but there had been no RSS feed. Also, I wanted to give people the ability to propose links to WDRL. As I used plain static hand-written HTML before, all this wasn't possible in an easy way. I also needed to write the draft in TinyLetter and then copy/paste everything over to my online archive manually. The project was growing constantly and I needed to give it a proper environment again…

What Changed

This weekend I drastically changed the workflow. I now use Jekyll to build the still static HTML site which now has templates, which now has an RSS feed, and which now has a submission form. The latter is powered by free Wufoo so after 100 entries per month it will be blocked. This is okay for me as 100 external links are quite enough to handle for me.

And finally, the project now lives on its own place: wdrl.info.

Support and a big Thank You

The project is and will be free forever although I am thinking of how to finance all the time I am spending on the project (roughly 8-10hrs per issue). As I don't like ads too much and am fan of keeping everything open, as a first step I enabled GitTip. That means you can donate for WDRL if you want to.

But the best thing is: This project started as a small personal list and grew so much in just a few months that I just want to thank you for all your support and that you enjoy reading the list. You are awesome! ♥

-Anselm

Do you test your Responsive Design in all major Desktop browsers?

• 72% say they test their sites on all major desktop browsers
• 28% don't do it

Conclusion: The reason I asked this question was that I had the feeling more than only a few people don't test their responsive webdesigns on all major desktop browsers. With 28% of users confirming that I strongly think there is the need to improve the testing workflow. Also, I can imagine that users don't sell the importance of testing the design to the client which is even worse.

Do you test your Responsive Design on real mobile devices?

This question is the base for my survey and what I wanted to see as an outcome of the survey is how people define 'I tested my code on mobile devices'. This being said I expected a even less people testing on real devices.

Conclusion: 91% doing real device testing is cool but I believe this number is due to the fact my followers are aware of the need to test on mobile. I don't think this number is very representative but it is to hope the real number is not too far away.

The tricky one: On which real devices do you test on?

On purpose I set this response as textarea so everyone can only enter on which devices he tests and to make sure he can also add less known devices. For me it's harder to do an conclusion but I took the time and here's my conclusion:

Conclusion: Majority of survey responders test on three or four devices which is already a great thing. No wonder, iPhone and iPad are on top of the list, followed by Androids (mostly Nexus or Samsung Galaxy) while Blackberrys or Windows Phones only have 5-10% users. Abstracted by the models most provided I can say only very few test on older devices (not speaking of iPhone4 being an older one) which definitely means there's place for improvement.

Do you have the devices all at work? Would you want to test on more but simply don't have them?

This question exactly approved what I already thought. Most people only test on devices they have at home/work. While this is totally understandable it also means that for example the idea of Open Device Labs and sharing test devices is not very wide spread. Please help spread the word and tell your co-workers. Open Device Labs are a great way to test on devices you don't have at home.

Conclusion: Open Device Labs would solve what users said in the survey: "Do you want to test on more devices?" (82% said yes).

Thanks for listening. Full results here.

To read the sources given in CSS the user agent would have to parse the CSS first which is a big performance bottleneck. This is the reason why browsers don't do it. Now as we know this, we might want to solve that.

It is relatively easy: As CSS is not parsed yet, a browser takes all sources that are written in the HTML source regardless if you prevent the image from being shown to the user by applying display: none; to the html class. In short, write the following in your HTML source:

<div class="preload">
    <img src="img/css-background-image.jpg" alt="">
</div>

And in your CSS you write:

.preload {
    display: none !important;
}

Now the prefetching algorithm of a modern browser is able to fetch the image source and as soon as the CSS is parsed the image is yet just available and can be displayed immediately. Otherwise during fetching the external source while executing the CSS this would shortly block the page and impact the performance of your site.

A few notices on that technique you should be aware of:

• If no CSS is applied to the page for whatever reason the image is shown to the user (which might not be intended).
• You don't need to set an alt="" text on the img elements as this is a non-descriptive layout image which probably isn't inteded to be read out by screenreaders. Be aware we need to set it as empty attribute to prevent some screenreaders from reading the source of the graphic. I know screenreader should not read display: none; but in fact some do and also if no CSS is applied, the empty alt-attribute still works so I found this the better technique.
• This technique also works for image resources that are used in JavaScripts.

That's it, I hope it helps. Thanks for reading!

I received some feedback by Rodney Rehm and want to add some things now:

Google Chrome's subresources

Not a webstandard yet, Google Chrome tackles the prefetching problem within a link element in the head section of your HTML document:

<link rel="subresource" href="img/css-background-image.jpg">

Browser support (as of now): Google Chrome only.

Removing the preload element from DOM

You can of course, and if you already use JavaScript in your page easily clean the DOM up after the subresources have been loaded. This can be done by a small snippet like this with jQuery:

$(document).ready(function() {
    $('.preload').remove();
});

If you're not using jQuery, consider using a DOM Ready snippet and do this manually:

<script src="js/jquery.documentReady.js"></script>
<script>
    $(function(){
        var preloadNode = document.querySelector('.preload');
        if (preloadNode.parentNode) {
            preloadNode.parentNode.removeChild(preloadNode);
        }
    });
</script>

Update 1:

Chrome and Mozilla Firefox support <link rel="prefetch"> to tackle that problem. And recently, IE 11 joined the party providing support for prefetching, too.

Credit notice: I am not sure where I found this technique first but Harry at least uses it so I guess I owe him the credit although I added the alt-attribute for better screenreader compatibility even if the CSS is not loaded.

I almost stopped doing the typical kind of vacation, laying on the beach relaxing. I tend to get bored very quick relaxing. This year I made a lot of small 'vacations' — I just visited other countries and cities for a conference and appended 2-3 more days to explore the site. This is the perfect mix out of work and exploring when I don't do any outdoor sports (which is the other kind of vacation I do).

But as I am a freelancer I also need to do some tasks when I'm aborad. It would work doing nothing for a few times but being at around 15 conferences a year means you need to do some work during that days, too. Working in a hotel is usually pretty boring so I decided to work in a coffee shops or even on a tower. Would you believe I am very productive on such days? I am and I will explain why…

To be honest it is exhausting to travel a lot. You need to plan things, travel, will get irregular sleep and all that stuff. And you also need to care about where to stay, how to finance it, how to get internet and where to charge your devices. Yes, this can be a big problem.

Sleep

I usually pick a good hotel for a one or two days and hostels or an apartment the other days. This means even if one of the locations is badly chosen you have no worry as you know it will be better in one or two days. While this also saves costs it has another advantage: Staying in cheaper hostels you easily get in contact with other people — and I met great people there.

Mobile Data Plans

In some countries it is not very easy to get a data SIM card for your phone but I never failed so far. Italy and Switzerland need your Passport or ID as Germany want to have to give you a card while in Poland you just pay 10 bucks to get 1GB of data. Plans are very different but it is always cheaper than your foreign contract. With a data plan in your pocket you are now set to work wherever you are. This is fun and last week I even wrote this blog post on a tower in Bologna. Pretty cool having a view over the whole city while working and writing, isn't it?

Power

The main problem I always have is battery power. My MacBook Air lasts usually for 3.5hrs now, including one recharge of my iPhone which has a pretty ridiculous last of battery when tethering. This is not very long, so take care to find a coffee shop or restaurant where you can recharge. Otherwise, you're lucky if you have chosen your hostel near the city center so you can simply go home and recharge there. In Italy I clearly prefer sitting in the sun enjoying an Espresso while charging my computer.

Excerpt: Force yourself to just do it

• Buy a conference ticket in another country This can be a good reason to travel to a new country and while you will learn something new at the conference while meeting new but maybe also known people what give you sort of security you can extend this journey by a few days traveling to other cities around.
• Just book it I personally am not a person that decides very quickly. Honestly, I am the person who shifts decisions until it may be too late. But if you just force yourself to book immediately when you have the idea, just do it. It's easy – no one wants to spend money for nothing and now you will have to do that trip.
• Take some friends with you Sometimes it is better to take some friends with you. This can be good friends but I recommend to do those travels with people that work in your industry but you don't know too much. People you met at conferences or even only know from twitter can (but surely aren't for sure) be a good choice. Knowing someone is important and makes you feel more comfortable while traveling in an all new country.

I never experienced major trouble which I couldn't solve easily by myself. Of course bad things happen — on my last trip my charger broke and I needed to search half a day for an Apple Store because I had to finish some work on that day — what did I do? Bought it, walked up to a nice place over Florence and worked with this view in front of me:

This look pretty fantastic, doesn't it? To be honest, my trips aren't that cool all the time. Sometimes it is just visiting a city for two days and it rains and rains. But to make my message short I give you one advice:

Wether you're just changing the location of your work in the same city or traveling to foreign countries – it all counts and all makes a difference. By being at foreign places you'll have new impressions, maybe even a foreign language or unknown culture. This is where our mind comes into place: When you see something new your brain thinks how to connect this to your known world. And that's where ideas develop.

It might be the wrong thing to travel if you need a project to be finished – it is actually hard to just work after a schedule being abroad. But if you need some inspiration or new ideas it might be the best idea to just leave your usual place to work…

This article takes on several steps how to deal with repositories that you aren't developing actively anymore. I encourage you to invest the 5-minutes declaring your repository as 'inactive' so people know this might not be up-to-date anymore.

Updating the Repository's title

Most people just look at a repository's name. Therefore, inactive repositories should reflect this in their title byprefixing them with [DEPRECATED] or [INACTIVE].

Updating the Metadata

The first and easiest approach is to update Metadata. Write a notice to your README.md file directly as first Headline:

[DEPRECATED] Your Repo name

or write inactive instead:

[INACTIVE] Your Repo name

You can then have a follow up paragraph with more details about the state of repository (still usable or not recommended to use anymore).

Adding a console message

Another approach is to give a decent hint to developers using your code in the Web developer console. But be aware that not every developer uses DevTools and Console so this is likely to be overseen. I think it is a good additional way to inform users about the deprecation by adding a message like this to your JavaScript:

console.warn('Important notice: This library is deprecated and not actively developed anymore.');

'Removing' the code from the repository

If your repository is deprecated and the code you provide might be even invalid or non-working you might consider removing the code. Don't do that! Instead, just move the code away from master branch (clean this one) into another branch so people don't see the code by default but still can access it. You might want to tag the last good working release with git-tags.

Update Articles and Blog posts

Don't forget to update your blog posts and articles. They are likely to be found in Search engines and people might want to know instantly that this is deprecated, especially if you provide a zip or tarball download (remove them).

Link to Alternatives

If there is another, still maintained library doing the same thing, add a reference to it on your library so people find an alternative solution for their problem.

You don't need to do all of those things but if you only do one or two of those points you will help many people using your library or finding it through search engines. Thanks for helping keep the web clean and up-to-date!

By the way: If you're near Zurich, Switzerland you should attend the WebPlatformDocSprint. It's fun and helps to improve the web.

Bereits vor einigen Wochen überkam mich das Gefühl, dass ich zu viele Sachen habe, die ich nicht brauche. Unter anderem viele Fachbücher und DVDs, die der ein oder andere von euch vielleicht haben möchte.

Daher verschenke ich nun folgende Sachen:

Ihr könnt die Sachen entweder in München bei mir abholen oder ich schicke sie euch zu (dann würde ich nur um Erstattung der Versandkosten bitten).

Wer etwas haben möchte, schreibt mir bitte einfach eine E-Mail an hello [at] anselm-hannemann.com mit den Sachen, die er haben möchte. Ich versuche die Liste hier so aktuell wie möglich zu halten:

DVDs:

• 3x: HTML und CSS von video2brain
• 3x: Moderne Websites mit Dreamweaver CS5.5, HTML5, CSS3 und jQuery

Bücher

• 1x: Git, dpunkt
• 1x: ePub für InDesigner, dpunkt
• 1x: HTML5 Boilerplate Web Development, Packt Publishing
• 1x: SQL kurz & gut, O`Reilly
• 1x: Schriftdesign, mitp
• 1x: Barrierefreiheit verstehen und umsetzen, dpunkt
• 1x: HTML5 von Peter Kröner 2. Auflage, OpenSourcePress
• 1x Der erfolgreiche Webdesigner, Galileo Design
• 1x ABC3D von Marion Bataille, Carlsen