Over the years I’ve noticed a few things that have been used to cover over issues with a website. I’ve done a few of these myself due to design requests, time restraints, client feedback/requests, and just not knowing any better. I’m not saying anyone who does these doesn’t know what they’re doing - we can’t always know the reasons, so it’s better to assume good intent.
In the days of Flash, you’d have a pretty sweet loading screen. These days loading screens are usually reserved for games or large interactive experiences that require all assets to be loaded in order to give the right experience.
When I see this for websites it sets off some alarm bells. It might be based on waiting for images or fonts to load. I’ve seen other times where it’s determined by a
setTimeout that hopes everything will be ready by the time it fires the callback. It might solve the issue of layout jumping around as images load in, or preventing invisible text and changing fonts.
I remember doing this with Typekit. I could hook into
wf-loading and wait for
Usually we can show a website straight away. The text content is usually immediately available, so why not hand it over? Instead we make the user wait for something they might not care about.
Background Image Misuse
There’s something I’ve noticed that has carried over from the Internet Explorer support days. The
background-size rule has useful properties like
contain. It lets us set a background image and be confident that it will
cover the entire container, or fit itself to avoid cropping at any size.
While this is incredibly useful, it’s not so great for it to be used instead of a regular image tag. For one, if you want to make the image as responsive as possible you’re limited to media queries to swap them out. This isn’t great when tied into a CMS. Secondly, you’re essentially rendering an empty div with no context for screen readers in case the image pertains to the content.
These days we can use the object-fit
property. With this we can use the image tag along with the
srcset attribute, or inside a
Sometimes “responsive” only relates to the screen-width. Everything collapses into a single column and that’s the end of it. I remember working in an agency many years ago and I tried to convince the managers to try a mobile-first approach with an upcoming smaller project to see how it went. After hearing the sales pitch they said “Ok, brilliant! Can we develop the desktop version at the same time?” With that, we went desktop-first as the client only ever saw desktop designs.
I’m saying this because a responsive website isn’t truly responsive for reasons listed above, and many others. The end-user might not notice anything if they’re on a decent phone with a fast connection. This is especially true of showing the work to clients - if we’re getting feedback off them then it’s usually the restrictions of their hardware that we optimise for, and for the most part they have decent specs. We also fall into the trap of making a website for them, rather than their users.
I was originally going to do this about cut-corners, but I want to think the people doing this are operating within constraints, and doing the best they can. “Cloaks” seem like necessary evils we sometimes do to get something over the line. They’ll always exist in one form or another, but thankfully the gaps in the web platform are getting smaller, and eventually, such problems will be universally solved.