Recently, I got reminded about the Do Not Track (DNT) request header. As a user, you can enable DNT in various browsers and as a website this setting should be respected. In reality very few websites honor DNT as there are no legal or technological requirements to do so and sadly most prefer to collect as much data as possible instead of respecting privacy.
What many of these websites may not realize is that they are already not able to track most of the users which have DNT enabled, as many of them also use Ad blocker or other extensions to block tracking scripts. So, why not honor the DNT and don’t load the analytics script if it is enabled by a user.
In 2017, the average transfer size for websites was 3,4 MB. A big part of it (on average 1.8 MB) are images. Especially on article sites, many of these images may be GIFs. Some of these GIFs are multiple MBs and while looking at GIFs can be really funny, it is less so if you watch them on a slow device or when exceeding your available data by reading only one article. In this article, I will show how to convert GIF to MP4 to save data, how to embed the video responsible, how to react to the Save-Data header, how to enhance it using the IntersectionObserver and how to use MP4 as source for an image in supported browsers.
Over the years I have implemented dozens of login forms and used thousands of them on the web. A login form mostly consists of a user/email field and a password field. It seems really basic, but there are many ways to make a login form unusable and as many ways to enhance it. In this article, I will share an approach of building and enhancing a login form.
Recently, Chromium improved their implementation of navigator.connection by adding three new attributes: effectiveType, downlink and rtt.
Before that, the available attributes were downLinkMax and type. With these two attributes you couldn’t really tell if the connection was fast or slow. The navigator.connection.type may tell us a user is using WiFi, but this doesn’t say anything about the real connection speed, as they may be using a hot spot and the connection is in fact 2G.
With the addition of effectiveType we are finally able to get the real connection type. There are four different types (slow-2g, 2g, 3g and 4g) and they are described this way by the Web Incubator Community Group:
slow-2g: The network is suited for small transfers only such as text-only pages.
2g: The network is suited for transfers of small images.
3g: The network is suited for transfers of large assets such as high resolution images, audio, and SD video.
4g: The network is suited for HD video, real-time video, etc.
Let’s see how we can improve user experience by delivering images based on available connection speed.
As promised in my article introducing iss-observer.com here are the technical details about implementing push notifications. Originally, I wanted to focus on the specific issues I encountered on iss-observer.com but thought it may be more useful to show a minimal version and mention some issues as a side note. It should also be noted that some parts of the front-end are based on this tutorial
Since last year I watched the ISS (International Space Station) fly over various time since reading a tweet about Spot the Station from the NASA. There, you can enter your location and find out when you can see the ISS. You can also set alerts, to get notified via Email/SMS when the ISS flies over your location. Mostly this works fine, but I found that there are also sending notifications if the weather is really bad and you actually can’t see it and also if you can see it only for a very short time period.
Later that year, I learned more about Push Notifications and started building a web app where you can search for your location, get data about ISS sightings combined with weather information and being able to receive push notifications.
So, let’s see how we can improve this using CSS custom properties.
Truncating text and revealing text on the web is very common and I have to deal with these patterns almost on every project I work on. There are many situations where people want to have expandable text. In this article, I will cover the Show More pattern (toggling text on user gesture) and the Read More pattern (Show full content on user gesture).
I had the honour to publish an article for the Performance Calendar 2016 about ways to improve performance by caching and storing. I write about ways to enhance performance for first and returning visits and explain the advantages of different caching and storing options.
The Web Share API is an experiment in Chrome and the origin trial will end in April 2017. Although I try to keep my articles up-to-date, the information here will likely be outdated at some point. For more info please visit developers.google.com
Since Chrome 55 (Beta as of October 2016) you can use the Web Share API as an Origin Trail on Android. In this article, I would like to show, how to enhance your current share button with the Web Share API.
When building a web site, sooner or later, you will probably have to implement a form, be it a login form or a comment form. I have done it many times before, and the last time I had to create a comment form, I thought about how far I can enhance it. After adding one enhancement, another enhancement crossed my mind and after implementing that yet another one.
That’s why I would like to show you how you can enhance a form (in this case consisting of an <input> for the name, a <textarea> for the message and a submit <button>) from the most basic version to an EnhancedEnhanced™ Version with BackgroundSync.
Developers have been able to make a site available for offline usage for some years using Application Cache, but it has some downsides and hasn’t been really popular.
With the raise of Progressive Web Apps, and more and more sites using, and browser implementing Service Workers we will see a lot of sites being “ready for offline” in the upcoming months and years.
Many users don’t know that websites can also work offline like native Apps. If a user doesn’t have an internet connection they assume a website won’t work and that’s why I think it is important to indicate that the site/app will work offline and also which parts are only usable when online.
In Chrome for Android there will be shown an app banner for your site to engage users to add the site to the homescreen. The app banner will only be shown if the site meets certain requirements and if a user visits the site regularly, where regularly (at the moment) means at least two visits with five minutes apart. (Note: The time frame already changed over time and may change again)
The end of the year is around the corner and it’s time to look into the future of Front-end. In this post I will talk about my wishes for 2016 and why I would love to see these three features implemented. Read more about Front-end wishlist for 2016
When browsing the web (especially on a slow connection) it takes some time until images are loaded and the browser is able to calculate the necessary space needed. I often open an URL, start reading and half way down when the images are finally loaded, I lose the current position and have to scroll down and search the position I have been; This is frustrating. Read more about Definining aspect ratio to prevent reflow
I wanted to update the design for this site for years but whenever I started, other projects came in the way. I have at least 10 unfinished designs which will never go live. That’s why I am starting an open redesign now. Read more about Open redesign
I recently worked on a site where the audio element is used to provide extra information. After testing some article pages with many audio elements I noticed that browsers download the audio source without interacting with it. In some cases, this summed up to 10MB of downloaded data. Visiting such a site with a data plan can be very expensive. After visiting MDN and reading more about the audio element I found out about the preload attribute and started testing it. Read more about Audio: The preload attribute
Last week I attended the Meet the TAG Meet-Up, a Q&A Panel with lots of great discussions between W3C TAG members and the audience – I even meet Sir Tim Berners-Lee; A wonderful evening. After the event, I talked to a student and he told me that one part of his studies is to build a “web app”. He decided to build an application for a museum showing interactive elements for exhibits. We started talking about how he plans to structure the project and what web technologies he plans to use when he said:
Browser bugs are annoying, reporting them can be even more frustrating. It can be quite hard to find information about the right place to report browser bugs and I see questions about this pop up on twitter here and there.
A place to find information about bug trackers and status pages of various browsers, articles around browser bugs and other useful resources. It’s still in his early state as you can see, but it will hopefully improve over time. Read more about Introducing bugspencer.com
I attended a meeting this week where we talked about optimising the “web process” for an agency – Among other topics we also had a great discussion about browser support. Read more about Defining browser support
I have been publishing a new issue of Browsers and Bugs every Friday for 24 weeks in a row until my vacation two weeks ago. After the break, I wanted to start collecting links and deciding what’s worth adding to the list again these days, but it doesn’t feel right anymore. Read more about Browsers and Bugs: The last issue
… an add-on.
… adding a fallback for every feature you want to use.
… about thinking in browser versions.
… the answer to the universe life and everything – that’s 42.
Hello and welcome to issue 24 of Browsers and Bugs. As I am in Brighton for Responsive Day Out tomorrow you can enjoy this issue already today. Furthermore, as I am on holiday on an island in Italy starting next week for 10 days there won’t be a new issue the next 2 weeks. Enjoy the summer. Read more about Browsers and Bugs 24/2015
I am currently redesigning my website and therefore also the navigation. There are loads of different navigation pattern and I made many myself in the last years. However, I searched for a different solution again as none of the patterns I know offers the following points I had in mind:
On small screens, all menu items should be easily reachable
Important menu items should always stay in the beginning
Last update: 21.03.2017 – updated browser support for Chrome, added info about punycode in Chrome
tl;dr If you want to use input type=”email”, be aware that international email addresses (containing Umlaut, non-latin characters…) are not supported in every browsers and you may exclude users using such an email address from using your service. Furthermore, the current version (56) of Chrome translates international addresses to punycode, so if a user registers with test@ö.at, the value you will receive will be firstname.lastname@example.org in Chrome but test@ö.at in all other browsers supporting international email addresses. So, think twice and be careful using it!
According to a survey by Peter-Paul Koch input type=”email” is the most used advanced input type. Which makes sense in my opinion as almost every site using a form also has a field for email. So, at a first glance it seems perfect to use it, browsers who support it will validate it, most mobile browsers will add the @ sign to the keyboard and most importantly, if a browser doesn’t support it, it falls back to type=”text”. Read more about Input type email – better don’t use it!
Initially, I wanted to find a way to lazy-load background images, but all my tests confused me completely and I thought I should better move on with my daily tasks. Some days later, however, I was reading an article on medium.com and while the page was loading I recognized that the big background image was not appearing until the page has loaded completely. And there it hits me, is there a way to prioritize the loading of a background image so it will be shown earlier? So, I set up some more test and found out there is indeed a solution for it. Read more about Prioritize loading of background images
Some weeks ago I saw a great example of a login form with a lovely extra. On this login site, once the password field is focused, the owl, sitting on top of the form, hides her eyes, showing that the password can not be seen by others and therefore is private. I had to grin the first time I saw it and I am still impressed by the perfect association with privacy. Read more about Give forms some extra attention
This reminded me about an idea I had some months ago. The idea is to have a classic tweet link (http://www.twitter.com/share) at the bottom of the page and once you select a text, the text gets highlighted and you see a share button above the text. Read more about Share quotes via twitter
For a recent redesign we mananged to reduce the page size to under 500kB for almost every part, expect the sections where we included a dynamic map. The size of an average dynamic map was about 600kbB, thus we had to find different ways to show a map and came across Static Maps, which turned out to be the perfect solution for us.
For most websites I build these days I have to integrate a map, mostly as a bonus for the contact page. Until now I simple used an Iframe loading a Google Map with the desired address centered. This however comes with a cost, even a realativeley small map loads ~600 KB (See this example of a 400×200 map).
Almost every day I get emails like “Hey Michael, on site bla.com something looks odd” or “Hello, can you please fix the site bla.com, it looks strange on my computer”. Well, sometimes they are more detailed “Bug Reports” than the ones mentioned, but nevertheless, without getting more details about the OS, Browser, … I mostly couldn’t help them in the first step.
So I used to respond them, asking what Browser, Browserversion, OS… they are using to reproduce the error they wanted to tell me, but I soon realized that it’s really hard for most people to provide me with all the details and very time consuming for me to ask again and again. Read more about There is a bug
From time to time people ask me on which devices and with which browsers I usually do testing. Simple answer: It depends – There are just too many aspects involved to give a straight answer. Nevertheless, within the last months I defined myself a basic test setup, which works out really well so far. It consists of four parts – Mockups, Design, User Interface and Final Check.
To get a first glimpse how the site should look like I usally start by producing Mockups with HTML and CSS. This part is taking place completely in the desktop browser, I prefer Firefox, because I love the “Responsive Design” feature. I usually test them starting from about 280 – 320px up to ~ 1600px. I try to spend not to much time in details in this step, it’s really just to get a basic idea.
2012, the year where reponsive Images got mainstream and became the rockstar of many dramas just ended some time ago and I am sure you are looking forward to 2013 for the next “responsive Image affair”. I have never planned to attend this show, but just today, while walking through Berlin, I couldn’t think of anything else.
What an attention-grabbing title, isn’t it. Actually it’s how the web works, belief it or not. Just to be clear, I don’t talk about websites looking different on different browsers, OS, screen resolution – whatever, a website looking different is actually a great thing, every website should look diverse on different platforms. Point.
What I mean is, that every single website out there is broken in one or another browser, just because you will never ever be able to test on every single browser still in use. At the latest after looking at this diagram of web browsers it should be clear, even if you only want to test on all browsers released in the past 3 years, 24 hours a day won’t be sufficient.
Over the last weeks I became somehow frustrated with the HTML input type “url”. While going through registration forms, I often got the error message “Please enter a valid url” after filling in www.justmarkup.com.
As a developer, I immediately looked at the source code and was not surprised to find that they used the required attribute in combination with type=”url”.
To be honest I never really liked my old design but at that time I just wanted to push it live, so I can start blogging and show something off. After several month of doing nothing I finally had the time to rebuild everything from scratch. This year I learned a lot about building websites, how to test, optimize and build for different devices. This site is not at all perfect and probably, like in my opinion every other page, will never be, but right now I am totally happy delivering it, as it is. If you have feedback, good or bad, I would be very pleased if you yould either Tweet me or write me an Email.
This post is all about setting up and using tools and extensions, useful for testing your Responsive Design. I work with Ubuntu, so most of the instructions will be for Ubuntu, but I guess everyone else will get the idea.
The current Firefox Nightly comes with a fantastic tool for testing your Mediaqueries. They call it “Responsive Design View”, and you name it, it’s for testing a site on different screen resolutions. With this tool you can easily resize your site both vertically and horizontally or choose one of the redefined screen sizes to test the most common ones. Sooner or later this tool will be build in Firefox Stable, but until then you can download Firefox Nightly, which runs site by site with the stable Version.
Furthermore you can install Firefox Fennec, downloadable on mozilla.org. There you will find handy install instructions, to get it running within minutes. I don’t use Fennec that often anymore, as I use Firefox Nightly now for testing initial mockups, but it’s a great browser for testing “touch”, as there is, for example, no hover event. Read more about Testing your responsive site – using Ubuntu
As soon as the new Ipad was released, many people started thinking about the best way to serve high-resolution images to it.
Apple itself implemented this technique, which has not been thought through, mainly because of the increased total size. When surfing apple.com with your shiny new Ipad you have to download 2.13MB instead of 502.90K, or in other words 4x the size. This may be fine if you are using WIFI or LTE (which is not usable at all in many countries), but not for people surfing on low bandwidth. Read more about Should we really worry that much.
While we, as developers, think about best ways to serve images to different devices and resolutions or about how we can adapt the navigation to various screen sizes, many people get more and more annoyed by the mobile “experience” they have to deal with.
An URI is unique and everywhere the same, isn’t it?
Dear websites, every time you redirect me to your “mobile” site and just cut off the path of my URL, a kitten dies.
Thomas Fuchs puts it in a nutshell, it’s just a pain in the ass if you don’t serve the content the user wants to see. This users will think twice the next time before clicking your link and of course will never ever share your link. So, if you don’t have the requested content available on your mobile site, do yourself a favour and show the user your “normal” site instead. Read more about Take this you mobile wannabe!
As it happens a lot that you get a link from a friend saying “Look at this cute cat” and once you open the picture you actually get to see a “big pink dog”, I went on and tested some of the most visited news sites in Germany to see if it’s possible to share a specific image out of a gallery just by copying the URL from the address field.
We all do our best to test our sites in lots of different browsers, screen resolutions and input/output devices. But to be honest we just can’t test everything.
Unless you have the opportunity and money to sit in front of a 42″ or even bigger screen you are not able to test your design on big screens. Scaling down your browser window is easy, but increasing it over your max. resolution available is just impossible. Read more about What we can’t test
Let’s say you are thinking about a relaunch of your site. One of the first things you may do is checking your Analytics Data to get a feeling what Browser, OS, Screen resolutions, Plugins, … your users actually use.
After finishing your evaluation you may define which browsers you have to support definitely and on the other hand which browsers you may just ignore as they only count for ~ 1% of your visits.
Don’t trust them
At the moment the whole world (ok maybe only we frontend people) speaks about responsive design. If we divide the opinions we come up with three approaches.
1) People who don’t care at all about responsive design and just continue coding like the years before.
2) Frenetic elation – people trying to convince everybody to use it now.
3) People who remark criticism about responsive design.
IE will never be dead
Starring at your statistics with the hope old IE’s won’t appear anymore will not happen in the near future. Of course every frontend developer will have a giant party if the world of browsers would only consist of up to date browsers providing the same experience.
Waking up from the dream we have to realise that there are not only different browsers, but also different screen sizes, people using all sort of input and output devices and so on. Read more about Let’s start with the basics.