Many new web platform features require a connection via https nowadays. So if you want to use and test Service Worker, you need a domain which runs on https and has a valid SSL certificate. If you have a public domain (like .com or .party), your hosting company most likely offers SSL certificates (often free now thanks to Let’s Encrypt), which are also easy to install in most cases. But, if you develop, you don’t use a public domain. You can either use http://localhost or you can use a local domain (e.g. justmarkup.localhost). If you use localhost you can still test Service Worker, as browsers have whitelisted this, but if you use http://justmarkup.localhost it won’t work.
You should use .localhost, .test, .example or .invalid for your local domain as they are save to use. Others like .dev used to work fine until some time ago and this may happen to others too, so you should stick to the Reserved Top Level DNS Names.
Often localhost is fine for developing, but if you need a subdomain or if your CMS requires you to use a top-level domain‚ you need to set up a valid SSL certificate for this domain. In this article, I will explain how to set up a local domain, how to set up Node.js and a https server, how to configure an OpenSSL certificate and how to ensure browsers consider it as a valid cerfificate.
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 they 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.
Last week, Scott Jehl asked: Have your a11y assumptions/practices evolved w RWD?, which reminded me to re-evaluate my current practise of handling states on resize. My current approach is importing CSS breakpoints into JavaScript and handle the JavaScript based on the values from the :before pseudo elements defined in CSS. This way I don’t need to define the width/height where the elements should change in CSS and JavaScript, but only in CSS. While this is a great solution, it is also a hack and I think custom properties are better here.
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.
Note: Some of the information in this article is outdated, for latest info see this article on developers.google.com
Last week I wrote about discoverability of progressive web apps and as part of this I also thought about current ways a site gets promoted as an app by browsers.
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)
I haven’t heard about the contain property until some weeks ago when I asked about use cases for container queries on twitter and David Baron mentioned it in a response saying that contain: strict; can avoid many of the theoretical problems of container queries. Since then I read the specification and everything I found about it trying to understand it; Here is what I learned. Read more about CSS containment
Container queries – formerly known as element queries – are one of the features I really want to see implemented in 2016. That’s why I would like to show some use cases for container queries. Read more about Use cases for container queries
CSS custom properties have been around for a while now and are currently supported in three browser engines (as of February 2016). When I first heard about CSS variables I was skeptical as I thought they will offer the same functionality as variables in pre-/post-processors. Some month later I stumbled across the spec and was pretty excited to find out that they are not really variables, but rather properties which are dynamic and scoped to the DOM. To show this in action I build a simple theme switcher demo. Read more about Theme switcher using CSS custom properties
Last month a client reported an issue with their website, saying that the navigation isn’t working on his new iPhone 6s Plus. After getting all browser details, I started to reproduce the error, but neither on my iPad with an identical iOS and Safari version nor on any emulator on browserstack.com the error occurred. So, I arranged a meeting with the client and debugged directly on his smartphone. After some testing I noticed an JavaScript exception QUOTA_EXCEEDED_ERR:DOM Exception 22. I checked the code and found the error was caused by using localStorage.setItem();. While we checked if localStorage is available 'localStorage' in window we didn’t check for setItem();properly and therefore our complete JavaScript failed.
This made me rethink my strategy of hiding elements when JavaScript is available. Typically I change the className of <html> from .no-js to .js in the <head> with JavaScript to avoid the FOUC. The problem with this method is if an error occurs, like described before, this will fail and probalby make parts of the site unusable.
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
This morning I asked on twitter for help with using transform: scale(); The first problem was that I wanted to animate the box the same way with scale(); as with changing the width/height of the element. The problem here was I wrongly set transform-origin: 0 0; only on :hover but not for the inital state; Thanks to Sven Wolfermann for the hint. Read more about Scale an element without changing the size of its child elements
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
The web consists of content, content consists of words and words can be long, very long. Everyone involved with the web will sooner or later have to deal with long words.
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.
… about making it work without JavaScript.
… 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
It’s friday and thus a new round of Browsers and Bugs is ready for you. Hello and welcome to issue 22. Happy bug reporting. Read more about Browsers and Bugs 22/2015
As I use Piwik to analyze and monitor the traffic on my site I thought about a way to combine both to monitor the load time of my site. After some testing, I came up with the following solution. Read more about Monitor load time performance with Piwik
While writing JavaScript you will most likely use either console (console.log, console.error…), debugger; or even alert() (I hope you don’t anymore) at some point to debug your code. Showing these messages on your development server is not a problem as only »you« will see them, but if they show up on your production server everybody will see them. Read more about Remove console and debugger statements for production with gulp/grunt
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:
It should work well without JavaScript.
On small screens, all menu items should be easily reachable
Important menu items should always stay in the beginning
Cutting the mustard is a term coined by the BBC team (post) to group browsers into »modern« browsers and »old« browsers. This is not done by sniffing the User Agent but by using Browser Feature Detection. Here is the JavaScript that decides whether the browser is modern or old. Read more about Cut the mustard revisited
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 test@xn--nda.at 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
The download attribute indicates the browser that a link should trigger the “Save as…” dialog instead of opening the file directly in the browser. Read more about The download attribute
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
Some days ago Christian Heilmann (@codepo8) wrote “Great publishing works with the medium, not against it”, where he argues against posting images with quotes on twitter. I totally agree with him, images with text included are a bad way to spread the word.
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).
That’s why I searched for a way to show the address in a visual way without loading unnecessary data and stumbled across Static Maps. Showing the example from above as a static map, we save ~550 KB, which is fantastic for news for performance. Read more about Maphancement – progressive enhanced Google Map
In this article I am going to show you the current status of the Notification API, explain different browser implementations and show off how to use the API.
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.
Mockups
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.
Webdesign
This site uses a really elementary layout and no fancy JavaScript, it’s simple and clean. If you build such a site nowadays and don’t build it responsive, you may better look for another job, seriously. Don’t get me wrong, I know that it is really hard work to get a sophisticated site using a complex layouts and tons of JavaScript responsive, but for simple sites it has to be the standard way, no the only way. And as a side note, if an user zooms your site and the design breaks, your site is not responsive, or in other words, avoid fixed units, please try to avoid it. Read more about Clean up – random thoughts
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.
Browsers
Firefox
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
Lots of fantastic people already put their hands on building a responsive navigation, and they came up with sweet ideas, like this Tutorial on .net by Aaron Gustafson.
And there is also a neat overview about “all” responsive navigation patterns by Brad Frost where he points out the cons and pros in a detailed way.
However most of these patterns are not really applicably when dealing with “large” navigations or multi-level navigations and thus I tried to develop one which also doesn’t need JavaScript.
If you are wondering, the navigation structure is the one used on a german newspaper, as I wanted to test it with a real world example.
Before finally diving into my example, I have to admit that I am still searching for a “perfect” solution, as each of the following has some drawbacks, you may see as a deal breaker in your project.
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.
Screen resolution
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
Let me explain why checking statistics is a good addition but not the ideal solution for your new project. First of all you can’t really trust your statistics, as the tracking may fail in some cases, you can’t really ensure tracking on all devices and you don’t get all data from users without JavaScript (unless you use server-side tracking).
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.
The simplest form of showing an animated Loading… has been around since the early days of Internet Explorer. The marquee element and his counterpart the even worse blink element has never been part of the w3c specifications because of their terrible usability and accessibility. Read more about Loading… and how css can help
