While reading an article on CBC’s website, I noticed they have added what seem to be newly-designed mega drop-down menus that work in an interesting kind of way.
These looked like a cool and simple thing to reproduce, so I gave it a shot and came up with something that I think works pretty nicely.
It wasn’t as simple as I thought, and I don’t think my code is the greatest, so I’m open to suggestions. I think this could form the basis for a jQuery plugin but I’ve never created a jQuery plugin so holding I’m off on that for now.
I think this is a pretty basic point, but I often see people throwing terms around in inappropriate ways (which I’ve also been guilty of), so I thought I would clear this up.
As fallible humans we tend to lean towards making excuses, blaming others, or trying to justify our mistakes or shortcomings. This is why you’ll often read comments from people discussing CSS and web standards, and they’ll say “I don’t use Internet Explorer; I use a standards-compliant browser”. Well, no you don’t. Nobody does.
Over the years I’ve continued to refine my understanding of front-end development terms, especially CSS terms and definitions.
I’m constantly reminded that as developers we should be consistent in the use of our terms. This post will attempt to list all common CSS terms, and what they represent in CSS code. Much of this is pretty easy stuff for most experienced developers, but some is not used as often colloquially or in writing, so a refresher could help clear up some inconsistencies.
The main reason CSS attribute selectors have been avoided up to this point is their complete lack of support in IE6. But since IE6’s market share is continuing to slowly but steadily decline, it’s becoming safer to use them.
I’m not going to go through the basics of CSS attribute selectors and their syntax. There are some pretty good resources explaining them, which I’ll link to at the bottom of this post. So if you don’t have at least some grasp of what this CSS feature is all about, please check those out first.
This article will go a little further and focus on some interesting facts and bugs surrounding attribute selectors that you may not have known.
Yesterday I was looking at the services offered by Squarespace, a “fully hosted, completely managed environment for creating and maintaining your website.” Don’t worry, I’m not going to go off on a rant about how bad this kind of thing is for web developers.
I recognize that not everyone can afford to pay thousands of dollars to hire a designer and/or programmer to create a website for them. Squarespace offers quite a flexible service for website noobs and at a pretty reasonable monthly rate.
But I couldn’t help but laugh when I read the following paragraph on a page describing their services as offering total creative control:
After I created a couple of handy charts that give details on CSS3 property and selector support in the upcoming IE9, I thought to myself: “This is interesting to read, but isn’t very practical.”
I also know that many visits to my site occur via Google searches for stuff like “cross-browser CSS” and similar phrases. So I decided to put together a comprehensive list of CSS properties that are supported in all browsers.
The list is divided into two sections: (1) Properties that are supported by all in-use browsers, with no bugs; and (2) properties that are supported by all in-use browsers, with some bugs in certain browsers.
I don’t mean to pick on anyone in particular here, because a lot of people I highly respect use some of these terms.
But generally, in the web design/dev blogging niche we tend to fall into the trap of following trends even in our use of words (especially in headlines and book titles). This even occurs on the better sites, not only on the “list-based” ones.
Here are some terms that I think have been overused and that we could probably eventually do without:
I love that boilerplate, and I wish I could say I understand everything in it. Paul’s a front-end genius and all developers should pay close attention to what he’s been doing lately.
But I have to say that I strongly disagree with Paul’s inclusion of that conditional comments tip in the Boilerplate, because it does not encourage cross-browser, maintainable CSS, but instead encourages CSS developers to consider Internet Explorer development as an afterthought.
Before I explain my specific reasons for wanting that technique removed from the Boilerplate, I’ll first discuss what exactly I’m talking about.
I know this has probably been discussed before, but I’m not sure if it’s been covered in a single post, and I’m curious to hear what people have to say.
What do you think is the best way to group or organize your CSS properities? The way I see it, there are basically three ways to do it, each of which I briefly describe below.
(Be sure to comment if you have a preference for any particular property ordering method, and your reasons for it.)