This week I did some research to try to build a hamburger menu that opens a slide-out navigation panel, a common design pattern nowadays. But I wanted to ensure the whole thing was keyboard-friendly and as accessible as possible.
I’m not 100% sure what I’ve come up with is the most accessible solution, but I did consult a number of decent sources on building accessible navigation menus like these. I also did some rudimentary testing using the free NVDA screen reader, to ensure there are no major problems.
One thing that’s common in development blog posts and documentation is the use of HTML’s <code> tags to mark up code snippets inline and in large blocks (the latter of which is usually done along with <pre> tags).
One of the problems that occurs with styling of <code> tags, however, is when they’re used inline inside of links (or <a> elements).
Most good developers by now accept the fact that pixel-perfect cross-browser CSS is not only unnecessary, but also totally impossible.
Of course, when we speak of the challenge of “cross-browser” CSS, we’re really saying “How can I make this work in Internet Explorer versions 6-8?” — because those are really the most problematic browsers.
Although I’ve written before about cross-browser CSS, and I still stand by just about every word in that article, I thought I’d reiterate my feelings on this subject by providing what I feel is the best workflow for getting your CSS to be as efficient, hack-free, and maintainable as possible while providing as similar an experience in all supported browsers.
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.
It would seem that with the introduction of HTML5’s semantic elements, styling those new elements should be an easier task. But as I’ve started to use HTML5 more, I’ve realized that it takes quite a bit of forethought to create maintainable CSS that targets the new semantic elements in a future-proof way.
In some cases, it could be fairly straightforward, but in others it’s a little disheartening because targeting the new elements actually creates more verbose markup.
Let’s consider a few examples. If you had a page that used the <header> element to hold the logo, nav, etc, and the <footer> element to hold the website’s footer, then your CSS would look something like this:
This article was first published on June 1, 2010 and has been updated to include a few extra features and an improved code base.
I’m a huge baseball fan, so earlier this year, just for a fun side project, I recreated the MLB.com Flash content switcher using jQuery and CSS3.
My goal with this project was to try to recreate the switcher without any extraneous images or other non-essential elements that tend to make stuff less maintainable.
My version uses CSS3’s border-radius, RGBA colors, opacity, and a small use of a gradient, and still looks acceptable in non-supportive browsers (although the jQuery is not as smooth in IE6 & IE7). Be sure to look at the real version on MLB.com for comparison; there are a few small differences, but mine is basically the same.
The improvements that have been added to HTML5 and how markup is evolving are great for the future of the web.
But I can’t help but feel frustrated that while we’ve come so far in certain areas, that we’re still a long way from being where we really want to be. One of those problematic areas is HTML5 video.
Why it’s taken so long to have a universal way to embed video natively in the browser without the need for a third-party plugin is beyond me. But it’s very difficult to get excited about something that is realistically not very practical or real-world ready.
I’m going to discuss here why I think HTML5 video is a great concept in principle, but a complete disaster in most practical usage.
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.
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 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.