I am currently building a RSS reader (intro blog article about feediary) and like always it is progressive enhanced. In short this means the main features of the site will all work in older browsers, but there are several enhancements only available for supported browsers. This strategy worked great until I started working on a new feature – Themes. It is a feature only available for paid subscriptions and I wanted to make the feature available to as many different browsers and users as possible.
This got me thinking. I could build this using CSS Custom Properties, browser support is ~88% at the moment (July 2018). Still, ~10% of potential users may not be able to use the feature. I could build a fallback version for them, but this would take quite some time I have to spend on top of building it with Custom Properties. So, in the end I decided to not use Custom Properties for themes. In this article I will explain why I decided against using a new web platform feature in this case and options to list a feature not available in all browsers.
When viewing code you will most likely come around a note along the lines of // Quick fix. Todo: Cleanup later at some point. There are many reasons developers went for a quick fix instead of a proper fix.
A critical bug was detected after a new release which needs to be fixed immediately, and there is no option to revert to an older version. Or a feature needs to be released tomorrow and you found a bug last minute and there is simple no way to postpone the feature and not enough time to do a proper fix.
Let’s see why CSS can fail, why fallbacks are important and how to progressively enhance CSS.
Info: If you are using a certificate from StartCom (for example the free StartSSL certificate) or WoSign you should start switching to another certificate (from Let’s Encrypt or any other trusted one). Otherwise, your site will be marked as insecure and might not be accessible to users in the next stable Version of Chrome (56) and Firefox (51) which will both be released at the beginning of 2017.
As of October 15, 2016 the average web page is about 2.5MB. The size is increasing and increasing. Five years ago it was 830kb and I don’t want to think of how big it will be in five years from now. In the past five years browsers changed a lot, among other things they also got a lot fast. So, on hand hand browsers get faster on the other we build heavier sites; It is a cat-and-mouse game.
It’s pretty crazy when you think about it. Browsers get faster, we have new technologies (responsive images, new image formats, Service Worker, HTTP/2…) and still surfing the web often feels as slow or even slower as five years ago. The main reason is that we build sites that are bloated and not optimized.
There are many reasons why slow and inaccessible web sites are launched day by day: Time, Budget, uninformed developers, false assumptions …
And there is another reason, I think has an impact: Browsers, browsers being tolerant and letting you load a 5MB background image, browsers being tolerant and letting you listen to events on inaccessible elements. You can throw a lot of *bad* things at browsers and they will not complain. Instead, they will do everything they can to clean up the mess.
“You need to be interactive in about 3 seconds, on 3G, on a $200 phone. Then, in less than 1 second on next visit”
He talked about that we are not succeeding on the mobile web at the moment mostly because our sites are too slow. After watching the video I thought a lot about the past, present and future of the web.
Let’s have a look at the last couple of years in web development.
6 years ago, Ethan Marcotte published the article Responsive Web Design. It was a new concept, it was exciting, we all needed to learn how to adapt responsive design for our sites, we all made a lot of mistakes by doing so and are still learning.
Now, in 2016, there is a new term – Progressive Web Apps (PWA) – a “umbrella” term for responsive, connectivity independent, fresh, safe, discoverable, re-engageable, installable, linkable Apps/web sites with app-like interactions. Once again, we all need to learn how to integrate the concept of PWA’s, we need to find out what makes sense for our sites and we need to discuss and exchange a lot – we need to avoid the errors we made at the beginning of responsive web design.
While this headline is not true now (April 2016) it may be a headline of the near future. This morning one of my clients asked for switching to https for their site. I tried to convince many clients, including this one, over the last years to use https for all their sites saying that it will prevent many security and privacy issues, users will have more trust in a https site and so on; They didn’t really care. At least not until Google announced to reward sites with https in search rankings. From that moment they all wanted https and they also didn’t care how much it would cost them anymore. Read more about Google to reward sites with service worker (offline ready) in search rankings
*Every* time a new platform feature gets announced/implemented it doesn’t take long until people moan about not being able to use it because of the poor browser support. Shortly after people will blame browsers for not implementing the feature right away. Accompanied by complaints that the web sucks, browsers are stupid, specifications are **** and other useless statements. If you want a feature to be implemented in a browser – write about it, explain why you need it, prepare use cases, help finding bugs – be helpful and not another troll.
We can’t use feature X because it is not supported in browser Y. “By too many developers”
Some time ago I wrote about why I think every browser should show the alternative text while images are loading. I opened issues for every major browser engine and was looking forward to hear positive replies as I was really sure there couldn’t be a negative aspect about it. Some kindly people replied, said they already tested it and the user experience was not improved, pointed me to edge cases I haven’t thought about and made me rethink. It’s one of the cases where I say to myself “Hey, this should be really easy to implement” without thinking about the whole picture.
Some days ago Šime Vidas tweeted: Why don’t Chrome, Safari reserve space for <img> with height attribute in responsive layouts? As part of the discussion and after some testing in different browsers I found that Firefox is the only browser at the moment who shows the alt attribute while images are loading. I think it would be great if every browser would show the alternative text while images are loading – especially on slow connections this would be very helpful.
Earlier this week – January 11, 2016 – Apple announced the release of Safari 9.1 which will be available soon is available now. It ships with exciting features – picture element, fast-tap, CSS variables – to name a few. I was as surprised, as other web developers to see this happen and it makes me happy. Read more about On the Safari 9.1 release
As of today, January 12, 2016, Microsoft will no longer support older versions (8, 9 and 10) of Internet Explorer. Many people are celebrating the “death” of these browsers and seem to be very relieved that they no longer have to support these outdated browsers. It seems for many it is all or nothing, black or white, no support or support and I am not very happy with this thinking.
As part of the open redesign of this WordPress site I also added a Service Worker – to improve performance and to offer an offline experience. I encountered some problems along the way so I thought it is a good idea to write about my findings. As a starting point I used this basic implementation by Brandon Rozek.