I got ambitious this past weekend and slapped together a new design for this site. Nothing too drastic, just a basic re-skinning with some layout tweaks.
I’m not going to write a book here to describe it, but I did incorporate some interesting new things that I will probably write about in future articles.
You might remember about a year or so ago, there was some discussion about the potential privacy issues caused by the CSS :visited pseudo-class. In a nutshell, it was discovered that this pseudo-class along with some scripting, could be used by websites to “sniff” your web browsing history.
You can read more about the problem and subsequent solution here and here.
It seems now that most of the latest versions of all browsers have taken measures to combat this issue. Fortunately, you can still style text links using the :visited pseudo-class. This is a good thing, and I hope we always have that ability. Visited links are a staple of the web, and they should remain.
Earlier this month, Chris Coyier posted an article discussing a way to deal with the empty elements that are often needed when doing CSS3 animation.
Chris’s solution is interesting. He basically suggests (and I’m paraphrasing here) that we can give the empty elements semantic value by adding some text in each one to describe what each animated element does, or what mood it conveys. Then, the text in those empty elements can be moved off the page with CSS.
Some people got in a tizzy over the potential SEO penalties that could arise (which I kindly pointed out is probably not an issue) while others seemed to have a problem with Chris’s use of the word “semantic”.
With any programming language, the learning journey is seemingly an endless one. Because I don’t have a computer sciences background, I feel I’ll always struggle to keep my JavaScript abilities up to par.
Over the last year or so I’ve stumbled across a number of useful resources that I think are worth mentioning here. Many of these are not for the faint of heart. Some pretty heavy stuff often geared towards advanced JavaScript developers and front-end engineers.
If you’ve ever flown in an airplane and watched the pre-flight safety instruction video, you’ve probably noticed something about the instructions for putting on the oxygen masks.
The video will emphasize the importance of putting on your own oxygen mask first before helping others (like small children). Although this might seem somewhat counterproductive at first glance, this advice underlies an important principle that lies at the heart of this article: You can’t help others if you don’t first help yourself.
As members of a growing, thriving, and super-collaborative community, we have grown accustomed to selflessly sacrificing our time and efforts to create new and exciting projects that assist, educate, and inspire our fellow web designers and developers. And the amazing part of this is that many in the community do these things for what is apparently little to no immediate personal gain. But this all might come at a steep price.
You’ve probably used CSS’s border property often, and in almost all cases you’ve probably set the border-style value to “solid”, which looks exactly the same in every browser.
We all know there are other values for border-style, but it’s likely you’ve never used any of them. You may have used a value of “dashed” or “dotted”, but probably not too often.
I thought it would be interesting to screen capture how all the different browsers display all the different values for border-style. In addition to the screen shots, I’ve provided some observations and I’ve summarized how the different values are supposed to look (according to the specification).
Currently, there are still a number of CSS3 properties that will not work unless you include all the various vendor prefixes. And that number is growing now that IE10 has added support for a bunch of new properties and features.
Let’s look at a simple example of some CSS3 keyframe animation code that includes other prefixed CSS3 properties, and consider a problem that might arise when trying to future-proof the animation code.
As of this writing, the full code required to cover all current browser support, plus future support for the standard syntax, would look something like this:
Okay, admittedly, this is a pretty crazy and virtually useless tip. But it’s just one of those things that illustrates the flexibility of our craft and how sometimes solutions to problems can be found from some really outside-the-box thinking.
Back when I worked for a Toronto web design agency, we often had to update sites that were written in straight HTML, with no server-side programming at all. So every year, clients that owned such sites would ask us to update all the pages to display the current copyright year. That was pretty lame. Not exactly the kind of work we wanted to be doing.
So we wanted to create a way that the current year would be printed on each page automatically. But we didn’t want to include a JavaScript library, we didn’t want to use Ajax, and we wanted the year to come from the server, not the client.
Last week Paul Irish coined a new term: TAFEE, which stands for Tiered, Adaptive, Front-end Experiences. The concept is nothing new.
It’s basically the prettier cousin of the concept of progressive enhancement, with a little bit of Andy Clarke thrown in for good measure. I won’t explain TAFEE here; you can read Paul’s post to understand the concept better, and to understand the reasons behind this approach.
The purpose of this post is to address a few of the comments on that article that were posted in response to the TV analogy that Paul used — which he borrowed from this slideshow by Nicholas Zakas.
Here’s a summary of the basic premise of this debate, and then my thoughts.
At the beginning of this month I wrote a post accompanied by five demo pages that showed that CSS3 transitions could be triggered with a number of different events/states in CSS.
That alone should help you see how these types of simple animations work. But let’s take this a bit further.
CSS pseudo-classes and media queries (which I used in that other post to trigger the transitions) represent certain states for certain elements. These states occur after specific events on the page. So naturally, CSS3 transitions can also be fired using any JavaScript event. Let’s try a simple click event that toggles a class name.
