There will soon be a HTML native method to retrieve a device appropriate
<img>. It too will repeat the very same environment tests that both our CSS and JS have performed in order to modify their behaviour to the client’s capabilities. And in the case of HTML it will repeat these environment tests for every single
<picture>on the page.
This is incredibly inefficient, and has the potential to make hand-authoring web documents implausible. Not to mention the problem that’s really to blame: Our technologies need to sense the environment in unison and adapt to a design, not to a device.
Made with HTML/CSS (no images, no JS) this is a simple interactive experiment with responsive design techniques. Using simple layout wireframes, this illustrates how a series of pages could work across these different devices, by simulating how the layout of each page would change responsively, to suit the context.
I’m not saying
-beta-is perfect. I am, however, saying, that we need something new. Unfortunately opponents of the
-beta-solution refuse to acknowledge that the situation has changed, and continue to beat the dead horse of getting web developers to solve what’s essentially a W3C problem.
It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers. We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.
I’m afraid to say we’ve lost a few battles. As of today: “responsive design” beats “progressive enhancement”, “multi-device frameworks” beats “basic core support”, “screen-readers” beats “text-based browsers”. How did that happen?
Have you ever heard the phrase “Content is King”? Being a Web developer, and therefore having a job that’s often linked to content creation, it’s likely you have. It’s a fairly overused but true statement about what draws visitors to a site.
From a Web developer’s perspective, however, some may argue that speed is king. More and more, I’m starting to favour that stance. In recent years many experienced front-end engineers have offered their suggestions on how we can improve the user experience by means of some performance best practices.
In this post, I’ll deal with this often overlooked area by introducing you to the concept of object oriented CSS and how it can help improve both the performance and maintainability of your Web pages.
Print style sheets are useful and sometimes even necessary. Some readers might want to store your information locally as a well-formatted PDF to refer to the information later on, when they don’t have an Internet connection. However, print styles are often forgotten in the age of responsive Web design. The good news is that a print style sheet is actually very easy to craft: you can follow a couple of simple CSS techniques to create a good experience for readers and show them that you’ve gone the extra mile to deliver just a slightly better user experience.
The following is a range of CSS tests of the most common browsers’ support for selectors and pseudo selectors. The tests includes basic stuff from the good old days of CSS1 and funky stuff from the future (CSS3).
Pseudo class selectors CSS selectors with a colon preceding them. You are probably very familiar with a few of them. They are immensely useful in a variety of situations. Some of them are CSS3, some CSS2… it depends on each particular one. Outside of IE, they have great browser support. In IE land, even IE8, support is pretty barren. However, the IE9 preview has full support of them. The link-related ones work but not much else. Let’s take a brief look at each one of them. Don’t worry, there isn’t that many.