I don’t mind drop-down menus. They give designers and information architects options for using screen space wisely. But I think many sites do themselves a disfavour by using them in an inconsistent manner.
The popular travel site Carnival Cruise Lines is a perfect example of what I’m talking about. I love the design of their site. For a travel website, it’s very good; it’s clean, and professionally designed. But I have one small problem with their drop-down menus.
Maybe there’s a technical term that I’m not aware of for this type of centered, line-splitting heading. Whatever it’s called, I’ve used it in the new design of the footer on this site, where I’ve divided the footer into sections with headers that overlay a horizontal line.
I wanted to try to do this as efficiently as possible, and without images. I came up with three solutions with pure CSS and one that uses jQuery.
If you haven’t yet used CSS3 transitions extensively, here’s something you may not have picked up on.
As I’ve outlined before, transitions can be triggered in a number of ways, and even via JavaScript. The reason for this is because the actual transition is not dependent on any particular event. Although it is the event that triggers the transition, the transition itself is completely separate from the event (as it should be).
Because of this, you’ll notice a slightly quirky behaviour if you place the transition on the part of your CSS that triggers the event.
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: