It’s more or less common practice these days to use real HTML lists when what you’re marking up makes logical sense as a list. If you don’t want it to look like a standard ordered or unordered list, that’s easy to fix with a bit of CSS. The underlying semantics will still be there for people using browsers without CSS support or screen readers.
But will it? The short answer is no, not always.
Posted in Accessibility, CSS.
Copyright © Roger Johansson
 |
You’re developing a new website and have decided to use some CSS3 and HTML5, now that many of the new specifications are gaining widespread support. As you’re coding the theme and thinking of how much easier these new technologies are making your job, you decide to stop for a while and test in other browsers, feeling a bit guilty for getting carried away and having forgotten to do so for a while. “Please work,� you whisper to your computer, while firing up all of the browsers you have installed. Browser A, check. You smile, feeling a bit relieved. Browser B, check. Your smile widens, and you start to feel better already. Browser C, “FFFFUUUUUUUUUUU…!�
Sound familiar? You might be surprised to hear that this is not necessarily your fault. With the competition in the browser market these days and the fast pace at which the new specifications are developing, browser makers are implementing new stuff in a hurry, sometimes without properly testing it. CSS3 and HTML5 are much more complex than their predecessors. The number of possible combinations of new features is huge, which leads to the most common cause of bugs: two (or more) things that weren’t tested together. As a result, developers these days stumble upon browser bugs much more frequently than they used to.
If you don’t, perhaps no one else will. Maybe the bug you’ve discovered is so rare that no one else will stumble on it. Or maybe they will, but they won’t know how to report it. They might think that it’s their fault, just as you originally did. Besides, if you’ve used these new technologies in a way that triggers the bug now, you will likely do so again in the future as well, so you would directly benefit from the bug getting fixed. And in the process, you’d be helping thousands of other developers avoid the frustration you’ve faced.
You might think that reporting the bug would be pointless, because it would take ages to fix, and would take even longer for users to upgrade to the fixed version. However, for all browsers except Internet Explorer (IE), this is not true anymore. Users of Firefox, Opera, Safari and Chrome upgrade really quickly these days, because the software pushes them to do so or (in the case of Chrome) doesn’t even give them a choice. Also, some bugs get fixed quite quickly, especially the ones that come with a decent report. Keep reading, and your own bug reports will likely fall in this latter category.
The first step is to reduce the problem to its bare minimum. If it turns out to be a browser bug, you will need to include this “reduction� in your bug report. Also, this will help you figure out a potential workaround until the browser vendor fixes it. Even if it’s not actually a browser bug, doing this will help you realize what you did wrong and fix it. Lastly, it’s a valuable aid in debugging in general.
Here is the process I follow to create reductions:
<style> or <script> element in the HTML document. This will make the reduction even simpler because it will be contained in only one file.<body> instead and see whether the bug reproduces. If it is, then remove all of the <body>’s descendants.<title> to something relevant to the bug. Check the whole thing carefully for details that you wouldn’t want other people to see, because you usually can’t edit it after attaching it to your bug report. (I learned this the hard way.)Now that you have your reduction, examine the code. Is it actually correct? Browser makers can’t be held accountable for the way their products handle invalid code — except for HTML5 markup, which has strictly defined error-handling. Validating the code might help, but take its output with a grain of salt. (Note that CSS vendor prefixes are valid, even if the CSS validator disagrees.)
If you have some time and want to be extra nice, here are some other things you can do to make an even better reduction:
border-radius: 50% correctly, then test whether the same thing happens with other percentage-based values. Or if a CSS gradient from black to transparent does not display correctly, see whether the same thing happens when you use a transition from background-color: transparent to background-color: black; if it does, then that would mean the problem stems from general interpolation and is not limited to CSS gradients. Even if you find that it’s not more general than the case you originally stumbled on, do mention your experiments in the bug description, so that the developers don’t have to repeat them.Sometimes the nature of the problem is quite obvious, so creating a simple test case from scratch is quicker. I’ve found JSFiddle to be an invaluable aid in this. However, bear in mind that browser vendors usually prefer that you upload your own simple HTML files rather than provide JSFiddle links. If you do decide to use JSFiddle, then uncheck the “Normalized CSS� setting, remove any JavaScript libraries (unless your bug needs them to be reproduced), and append /show to the URL, so that it leads only to your test case, without the rest of the JSFiddle UI.
If you don’t have the time to make a reduction, reporting the bug is still a good idea. A bad bug report is better than none at all, and the same goes for reductions. In this case, the browser developers will have to create the reduction themselves. The difference is that they’re burdened with doing this for many more bugs than you can imagine. You only have to do it for one: yours.
There are many reasons why you might not need to report the problem as a bug after all:
Let’s tackle these one by one.
In most cases, when you isolate the problem to a simple reduction, it’s fairly obvious whether it’s a browser bug or not. However, there are some caveats to this.
A while ago, I realized that even though outline-color: invert was in the CSS specification, it didn’t work in all browsers that support outlines. In particular, it didn’t work in Webkit browsers or Firefox. Those browsers didn’t drop the declaration, but just treated it as though it was currentColor. So, I went ahead, created a reduction, and filed bug reports with both browsers. After a while, I was informed that a footnote in the specification actually permits user agents to do this, so it wasn’t actually a bug. The moral of the story is to check the specification carefully — not just the table that is included in every CSS property, but the whole thing. Knowing these details will make you a better developer anyway.
On another occasion, I was reading the “CSS3 Backgrounds and Borders� module and found that it allowed percentages to be used for border-width, unlike CSS 2.1. I tested it, and it didn’t work in any browser. So, I filed bug reports in some of them, only to be informed that this was dropped in the “dev� version (i.e. the not-yet-published version) of the specification. The moral of this story is that, for specs still under development, don’t check the published specifications to determine whether your issue is actually a bug. Instead, look at dev.w3.org, where the most up-to-date versions of the specs reside.
Of course, in many cases, a bug is not really a bug or a lack of understanding of the spec, but just one of those stupid mistakes that we all do (aka brain farts). I remember once how distraught I was over my JavaScript not working at all in Safari, even though it gave no errors. After a while of struggling to make a reduction, I realized that I had previously disabled JavaScript in that browser to test how a website worked without it and had forgotten to enable it.
Likewise, a few days ago, my SVGs weren’t displaying as backgrounds in Firefox, even though they displayed when I opened them in new tabs. I then realized that I had two background images in the same declaration, the other one being a CSS gradient, and I had forgotten to add the -moz- version.
The one I’m most embarrassed about is when I actually reported a bug to Opera about pointer-events not working in <select> menus and was then informed that Opera hadn’t implemented pointer-events in HTML elements at all. D’oh!
In some rare cases, the bug is indeed a bug but not a browser bug. Specifications have their fair share of bugs, too. If the spec defines something other than what happens or if it defines something that conflicts with the rest of the spec, then it most likely has a bug. Such bugs should be reported in the relevant mailing list (www-style for CSS) or the W3C bug tracker. Even if this is the case, many of the guidelines mentioned below still apply.
If you haven’t already installed the nightlies of browsers, you should. These are the latest (potentially unstable) versions of browsers. Download them from these links:
Obviously, if your bug is not reproducible in the latest nightly of the browser, then you don’t have to report it. Just wait until the build propagates to a stable release. In other words, all you need is patience, young Padawan.
If after checking the specifications and the latest nightly, you’re still confident that it is a bug, then you need to search whether it has already been reported. Your best bet is to use the search engine of the relevant bug tracker. Don’t forget to search all statuses, because the default on some bug-tracking systems is to search only confirmed and open bugs (excluding unconfirmed and fixed or otherwise closed ones).
Be vague in your search, especially if the bug affects a feature that’s not very popular. For example, for this Webkit bug, a search for “multiple file� would show the bug, whereas a search for “input file multiple dom property� would not; I was inexperienced when I filed it and didn’t know the exact terminology at the time. If the bug tracker is public, sometimes searching on Google also helps (adding site:url-of-bug-tracker after your keywords).
If your issue has indeed been reported, some bug trackers allow voting. Mozilla’s Bugzilla gives every user a limited number of votes (the limit is in the thousands), which the user can use on any bug they wish. Also, Chrome’s bug tracker features a star in the top-left corner, which you can click to indicate that you consider the bug important. I’m not yet sure whether the developers take this into account, but voting certainly doesn’t hurt.
Every browser has its own bug-tracking system (BTS).
Safari and Chrome share the same engine (Webkit), so bugs that can be reproduced in both should be reported in Webkit’s BTS. Chrome has its own BTS as well, intended for bugs that are reproducible only in it. Also, if you’re dealing with a JavaScript bug in Chrome, report it to the V8 bug tracker.
You will need to create a free account to file bugs with any of these bug trackers (except Opera’s Wizard). But it’s a one-time thing, and it’s useful because it allows you to easily track bugs that you’ve reported.
All of the browsers’ bug trackers are public, with one exception: Opera’s. You can report Opera bugs through the public form I linked to above, but to access the BTS and to discuss your bug and monitor its progress, you will need to become an Opera volunteer (or an employee!) and sign an NDA. Volunteering is by invitation only, but if you submit a lot of good bug reports, there’s a good chance you’ll be invited.
The most important part of a good bug report (and the one most commonly done wrong) is the reduction. Hopefully, you’ve done that already, so the hardest part is over with. The rest probably won’t take you more than five minutes.
A good summary is the second-most important part of a bug report. Don’t be afraid to be verbose, if it actually adds something (don’t just babble). To take one from an actual report,
Background image disappears when
body{display:table}is used (common CSS hack for correct centering + scrolling in Firefox)
… is better than “Background image disappears when body{display:table} is used,� which in turn is better than “Disappearing background image.� Of course, all three are better than “CSS broke. Please fix!!!!11�
Sometimes you may want to add keywords to the beginning of the summary to make the report more findable. For example, if your bug is about CSS3 gradients, you could prepend the summary with “[css3-images].� To get an idea of the exact tags used in a module, look at other bug reports. It will usually be the same as the id of the specification, which is located at the end of its URL path. For example, for the CSS3 module “Backgrounds and Borders,� the URL is http://www.w3.org/TR/css3-background/, and the spec’s id is css3-background. Also, these summary “tags� can be OS-specific. For example, if your bug is reproducible only in Mac OS X, then prepend your summary with “[Mac].� If the bug is about something that used to work fine in previous versions, then prepend your summary with “[Regression],� or add “regression� as a keyword if the BTS has such a feature.
The category to which your bug belongs is usually quite obvious, provided you take a few seconds to check them all. For CSS bugs, these are the most common candidates:
John Resig suggests some ways to categorize JavaScript bugs.
Never, ever report multiple bugs in the same report. Handling these is very hard for browser developers. Think about it: what status should they assign to a report if they fix one bug, but the other turns out to be a duplicate? Or only one of the two turns out to be a bug? You get the idea.
I can understand that you might be frustrated from having had to deal with that bug, but being rude won’t help. Stay polite, and keep thoughts like “I can’t believe you can’t even get this right, you morons!� to yourself.
While developing twee+, a handy little app for posting long tweets (and my entry in the 10K Apart contest), I found out that even though it worked in mobile Safari for reading, it crashed when you tried to make an edit. I had no idea what might have been causing this, so I made a copy and started reducing. After commenting out parts of the JavaScript, I found that if I removed the onresize event handler, the problem stopped occurring. And then it made total sense: I adjust the rows of the textarea when the user resizes the window. However, in Mobile Safari, this triggered a resize event, resulting in a dreaded infinite loop. So I removed the resize event handler for mobile. It’s not like the user can resize the window there anyway.
A big part of my upcoming CSS3 workshop in Amsterdam is hands-on challenges. Attendees will download my slide deck (which is essentially an HTML + CSS + JavaScript app) and try to solve some 5- or 10-minute challenges on everything taught. A challenge slide would look like this:
I prepared a lot of the slides in Chrome. When I opened them in Firefox, I was greeted with this ugly sizing of the textarea:
In this case, I didn’t follow the reduction process laid out above, because I had a hunch that the bug was related to the way I sized the textarea. So, I fired up JSFiddle and made this simple example, in which the bug could still be reproduced. I then tested it in Opera and observed that it behaved like Firefox, so it was probably Webkit that was buggy. I tested it in the Webkit nightlies and saw that it hadn’t yet been fixed.
Before going any further, I tried to see whether the bug was more generic. Does it happen only with textareas or with all replaced elements? I went ahead and tested <img> and <input> and found that it happens only with form fields. I did another test to see whether it also happened with top/bottom rather than left/right. It did not. I also tested on Windows, and it’s reproducible there as well.
The specification confirmed that it was indeed a bug: “The used value of ‘width’ and ‘height’ is determined as for inline replaced elements.� After a bit of searching on Google, I found this blog post, which describes the bug but does not mention an official bug report. So, I searched Webkit’s bug tracker for “textarea absolute,� “textarea positioned� and “input positioned� and couldn’t find anything relevant. It was bug-reporting time!
I went ahead and created this bug report. Let’s hope it goes well.
At some point, usually after a few days or weeks, someone will modify your bug’s status. If it turns out to be a “duplicate,� don’t feel bad: it happens to the best of us, even employees of the browser vendors themselves. If the status gets “confirmed� (usually with the status “new�), this is a good indication that it is indeed a bug and that you did the right thing by reporting it. Last but not least, if the new status is “assigned,� it means someone is actively working on the issue (or plans to do so soon), so it has a high chance of getting fixed soon.
When your bug gets a status of “resolved,� check the “resolution� field. If it says “wontfix,� it means that they’re not planning to rectify the issue, for reasons usually stated in detail in an accompanying comment. The reason is usually either that it’s not a bug (in which case, the most appropriate resolution status is “invalid�) or that they just don’t want to work on it for the time being. If the latter, you could argue your case and explain why the bug is important, but don’t get your hopes up. Last but not least, if it’s “fixed,� you can congratulate yourself on doing your part to make the Web a better place.
Thanks a lot to David Storey, Divya Manian, Paul Irish, Elika Etemad and Oli Studholme for their helpful tips and reviews.
Front Cover: Image source
(al)
© Lea Verou for Smashing Magazine, 2011.
|
|
I think a lot of us CSS authors are doing it wrong. We are selfish by nature; we get into our little bubbles, writing CSS (as amazing as it may be) with only ourselves in mind. How many times have you inherited a CSS file that’s made you say “WTF� at least a dozen times?
(Image: Toca Boca)
HTML has a standard format and syntax that everyone understands. For years, programmers have widely agreed on standards for their respective languages. CSS doesn’t seem to be there yet: everyone has their own favorite format, their own preference between single-line and multi-line, their own ideas on organization, and so on.
Recently, I have begun to think that CSS authors could take a leaf from the programmers’ book. We need to write CSS that others can understand and use with ease. Programmers have been writing sharable code since day one, and it’s high time that CSS be written with as much organization and openness.
In writing inuit.css and working on a huge front-end framework at my job, it has become more apparent to me that writing code that can be easily picked up by others is extremely important. I wouldn’t say that I’ve nailed everything yet, but I’ll share with you some things that I think are vital when writing code, specifically CSS, that will be used by others.
First, the reasoning: my number one tip for developers is to always code like you’re working on a team, even if you’re not. You may be the only developer on your project right now, but it might not stay that way:
One thing I’ve learned from building a massive front-end framework at work and from producing inuit.css is that comments are vital. Comments, comments, comments. Write one line of code, then write about it.
It might seem like overkill at first, but write about everything you do. The code might look simple to you, but there’s bound to be someone out there who has no idea what it does. Write it down. I had already gotten into this habit when I realized that this was the same technique that a good friend and incredibly talented developer, Nick Payne, told me about. That technique is called “rubber-duck debugging�:
… an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line by line, to the duck.
Write comments like you’re talking to a rubber duck!
Good comments take care of 99% of what you hand over and — more importantly —  take care of your documentation. Your code should be the documentation.
Comments are also an excellent way to show off. Ever wanted to tell someone how awesome a bit of your code is but never found the chance? This is that chance! Explain how clever it is, and just wait for people to read it.
Egos aside, though, comments do force you to write nicer code. I’ve found that writing extensive comments has made me a better developer. I write cleaner code, because writing comments reminds me that I’m intending for others to read the code.
This issue really divides developers: single-line versus multi-line CSS. I’ve always written multi-line CSS. I love it and despise single-line notation. But others think the opposite — and they’re no more right or wrong than I am. Taste is taste, and consistency is what matters.
Having said that, when working on a team, I firmly believe that multi-line CSS is the way to go. Multi-line ensures that each CSS declaration is accounted for. One line represents one piece of functionality (and can often be attributed to one person).
As a result, each line will show up individually on a diff between two versions. If you change, say, only one hex value in a color declaration, then that is all that needs to be flagged. A diff on a single-line document would flag an entire rule set as having been changed, even when it hasn’t.
Take the following example:
Above, we just changed a color value in a rule set, but because it was a single-line CSS file, the entire rule set appears to have changed. This is very misleading, and also not very readable or obvious. At first glance, it appears that a whole rule set has been altered. But look closely and you’ll see that only #333 has been changed to #666. We can make this distinction far more obvious by using multi-line CSS, like so:
Having said all this, I am by no means a version-control expert. I’ve only just started using GitHub for inuit.css, so I’m very new to it all. Instead, I’ll leave you with Jason Cale’s excellent article on the subject.
Furthermore, single-line CSS makes commenting harder. Either you end up with one comment per rule set (which means your comments might be less specific than had they been done per line), or you get a messy single line of comment, then code, then comment again, as shown here:
With multi-line CSS, you have a much neater comment structure:
Likewise, the order in which people write their CSS properties is very personal.
Many people opt for alphabetized CSS, but this is counter-intuitive. I commented briefly on the subject on GitHub; my reasoning is that ordering something by a meaningless metric makes no sense; the initial letter of a declaration has no bearing on the declaration itself. Ordering CSS alphabetically makes as much sense as ordering CDs by how bright their covers are.
A more sensible approach is to order by type and relevance. That is, group your color declarations together, your box-model declarations together, your font declarations together and so on. Moreover, order each grouping according to its relevance to the selector. If you are styling an h1, then put font-related declarations first, followed by the others. For example:
#header {
/* Box model */
width: 100%;
padding: 20px 0;
/* Color */
color: #fff;
background: #333;
}
h1 {
/* Font */
font-size: 2em;
font-weight: bold;
/* Color */
color: #c00;
background: #fff;
/* Box model */
padding: 10px;
margin-bottom: 1em;
}
Ordering CSS files is always tricky, and there is no right or wrong way. A good idea, though, is to section the code into defined groups, with headings, as well as a table of contents at the top of the file. Something like this:
/*------------------------------------*\
CONTENTS
\*------------------------------------*/
/*
MAIN
TYPE
IMAGES
TABLES
MISC
RESPONSIVE
*/
/*------------------------------------*\
$MAIN
\*------------------------------------*/
html {
styles
}
body {
styles
}
/*------------------------------------*\
$TYPE
\*------------------------------------*/
And so on.
This way, you can easily read the contents and jump straight to a particular section by performing a quick search (Command/Control + F). Prepending each heading with a dollar sign makes it unique, so that a search will yield only headings.
All CSS files should have a section for sharing, where you tether selectors to a single declaration, rather than write the same declaration over and over.
So, instead of writing this…
/*------------------------------------*\
$TYPE
\*------------------------------------*/
h1 {
font-size: 2em;
color: #c00;
}
h2 {
font-size: 1.5em;
color: #c00;
}
a {
color: #c00;
font-weight: bold;
}
#tagline {
font-style: italic;
color: #c00;
}
… you would write this:
/*------------------------------------*\
$TYPE
\*------------------------------------*/
h1 {
font-size: 2em;
}
h2 {
font-size: 1.5em;
}
a {
font-weight: bold;
}
#tagline {
font-style: italic;
}
/*------------------------------------*\
$SHARED
\*------------------------------------*/
h1, h2, a, #tagline {
color:#c00;
}
This way, if the brand color of #c00 ever changes, a developer would only ever need to change that value once. This is essentially using variables in CSS.
A lot of people separate their sections into multiple files, and then use the @import rule to put them all back together in one meta file. For example:
@import url(main.css) @import url(type.css) @import url(images.css) @import url(tables.css) @import url(misc.css) @import url(responsive.css)
This is fine, and it does keep everything in sections, but it does lead to a lot more HTTP requests than is necessary; and minimizing requests is one of the most important rules for a high-performance website.
Compare this…
… to this:
If you section and comment your CSS well enough, using a table of contents and so forth, then you avoid the need to split up your CSS files, thus keeping those requests down.
If you really want to break up your CSS into multiple style sheets, you can do that — just combine them into one at build time. This way, your developers can work across multiple files, but your users will download one concatenated file.
Programmers have been doing this for ages, and doing it well. Their job is to write code that is as readable as it is functional. We front-end developers could learn a lot from how programmers deal with code.
The code of my good friend (and absolutely awesome chap) Dan Bentley really struck a chord with me. It’s beautiful. I don’t understand what it does most of the time, but it’s so clean and lovely to look at. So much white space, so neat and tidy, all commented and properly looked after. His PHP, Ruby, Python or whatever-he-decides-to-use-that-day always looks so nice. It made me want to write my CSS the same way.
White space is your friend. You can remove it before you go live if you like, but the gains in cleanliness and readability are worth the few extra bytes (which you could always cut back down on by Gzip’ing your files anyway).
Make the code readable and maintainable first and foremost, then worry about file size later. Happy developers are worth more than a few kilobytes in saved weight.
So far, we’ve talked about people maintaining your code, but what about actually using it?
You can do a number of things to make the life of whoever inherits your code much easier — and to make you look like a saint. I can’t think of many generic examples, but I have a few specific ones, mainly from inuit.css.
Inuit.css has a class named .centered, which is spelt in US English. CSS is written in US English anyway, so we’re used to this; but as an English developer, I always end up typing UK English at least once in a project. Here is the way I have accounted for this:
.centred, .centered {
[style]
}
Both classes do the same thing, but the next developer doesn’t have to remember to be American!
If your selectors include words that have US and UK spelling variants, include both.
Also in inuit.css, I devised a method to not need class="end" for the last column in a row of grids. Most frameworks require this class, or something similar, to omit the margin-right on the last item in a list and thus prevent the grid system from breaking.
Remembering to add this class isn’t a big deal, but it’s still one more thing to remember. So, I worked out a way to remove it.
In another major inuit.css update, I removed a .grid class that used to be required for every single grid element. This was a purely functional class that developers had to add to any <div> that they wanted to behave like a grid column. For example:
<div class="grid grid-4">
…
</div>
This .grid class, in conjunction with the .grid-4 class, basically says, “I want this <div> to be a grid item and to span four columns.� This isn’t a huge burden on developers, but again, it’s one more thing that could be removed to make their lives easier.
The solution was to use a regex CSS attribute selector: [class^="grid-"]{}. This says, “Select any element whose class begins with .grid-,� and it allows the developer’s mark-up to now read as follows:
<div class="grid-4">
…
</div>
CSS attribute selectors may be less efficient than, say, classes, but not to the point that you’d ever notice it (unless you were working on a website with massive traffic, like Google). The benefits of making the mark-up leaner and the developer’s life easier far outweigh the performance costs.
Do the hard work once and reap the benefits later. Plus, get brownie points from whoever picks up your project from you.
An example of being pre-emptive in inuit.css is the grid system. The grids are meant to be used in a series of sibling columns that are all contained in one parent, with a class of .grids. This is their intended use. But what if someone wants a standalone grid? That’s not their intended use, but let’s account for it should it happen.
Note: inuit.css has changed since this was written, but the following is true as of version 2.5.
Another and perhaps better example is the 12-column grid system in inuit.css. By default, the framework uses a 16-column grid, with classes .grid-1 through .grid-16 for each size of column.
A problem arises, though, when you attempt to switch from the 16-column system to the 12-column system. The .grid-15 class, for example, doesn’t exist in a 12-column layout; and even if it did, it would be too big.
What I did here was to make .grid-13 through .grid-16 use the exact same properties as .grid-12. So, if you switch from a 16-column layout to a 12-column one, your .grid-13 through .grid-16 would’t break it — they would all just become .grid-12s.
This means that developers can switch between them, and inuit.css will take care of everything else.
Pre-empt the developer’s next problem, and solve it for them.
There you have it: a few humble suggestions on how CSS authors can write code that is perfect for other developers to inherit, understand, maintain, extend and enjoy.
If you have any other tips, do please add them in the comments.
(al)
© Harry Roberts for Smashing Magazine, 2011.
|
|
Navigation is such an important part of your website. It’s how your visitors navigate to the main areas of your site and makes it easy for them to find your good content.
CSS is of course the perfect language for designing beautiful navigation menus. It can be applied to any type of website and is very flexible. Don’t be alarmed if your own CSS skills are fairly limited as there are a lot of great tutorials out there that walk you through how to add clean and professional looking CSS menus to your website. You can either copy and paste the code into your own design or modify the menu to suit your needs.
Today we would like to show you 100 of these tutorials; 75 horizontal CSS menu tutorials and 25 vertical CSS menu tutorials.
2. Elegant Drop Menu with CSS Only
3. Bulletproof CSS Sliding Doors
4. Tabbed Navigation Using CSS
5. Create an Advanced CSS3 Menu – Version 2
6. Create a Slick Menu using CSS3
7. How to Make a Smooth Animated Menu with jQuery
8. How to Make a CSS Sprite Powered Menu
10. Designing the Digg Header: How To & Download
11. Dynamic Page / Replacing Content
12. Create a Fun Animated Navigation Menu With Pure CSS
15. Creating a glassy non div navigation bar
16. CSS Sliding Door using only 1 image
17. CSS UL LI – Horizontal CSS Menu
18. How to Build a Kick-Butt CSS3 Mega Drop-Down Menu
19. A Different Top Navigation
20. Create a Cool Animated Navigation with CSS and jQuery
21. Navigation Bar
22. CSS: drop down menu tutorial
23. RocketBar – A jQuery And CSS3 Persistent Navigation Menu
24. A Great CSS Horizontal Drop-Down Menu
25. Overlay Effect Menu with jQuery
26. Grungy Random Rotation Menu with jQuery and CSS3
27. Rocking and Rolling Rounded Menu with jQuery
28. Slide Down Box Menu with jQuery and CSS3
31. How To Create A Simple Drop Down Menu With CSS3
32. Pastel color menu with dynamic submenu using CSS
33. Creating an Animated CSS3 Horizontal Menu
34. Tutorial to create a Beautiful, simple, horizontal CSS menu
35. CSS Sprites2 – It’s JavaScript Time
37. How to Code an Overlapping Tabbed Main Menu
39. Pure CSS Menu With Infinite Sub Menus Tutorial
41. CSS Sprite Navigation Tutorial
42. Create your own drop down menu with nested submenus using CSS and a little JavaScript
43. CSS Drop Down Menu Tutorial
44. Nicer Navigation with CSS Transitions
47. How to Create a CSS3 Tabbed Navigation
48. Create an apple style menu and improve it via jQuery
49. Create a multilevel Dropdown menu with CSS and improve it via jQuery
50. Sweet tabbed navigation using CSS3
51. Create an Advanced CSS Menu Using the Hover and Position Properties
52. Sexy Drop Down Menu w/ jQuery & CSS
53. How to Create a Horizontal Dropdown Menu with HTML, CSS and jQuery
54. CSS Express Drop-Down Menus
55. Professional Dark CSS Menu
56. Creating a Simple yet Stylish CSS Jquery Menu
58. Animated Menus Using jQuery
59. Make a Mega Drop-Down Menu with jQuery
60. Animated Navigation with CSS & jQuery
61. Horizontal Subnav with CSS
62. Mega Drop Down Menus w/ CSS & jQuery
63. CSS dropdown menu without javascripting or hacks
64. CSS Drop Down Navigation Tutorial
67. Horizontal CSS Menu With Icons
68. Creating a Multi-Level Dropdown Menu using CSS and jQuery
69. Create The Fanciest Dropdown Menu You Ever Saw
70. Create A Speaking Block Navigation Menu Using Pure CSS
73. Making a CSS3 Animated Menu
74. How To Create A Clean CSS3 Navigation Bar
75. How to Create a Modern Ribbon Banner Navigation Bar with Pure HTML/CSS3
77. CSS graphic menu with rollovers
78. Vertical CSS Menu With a ‘Behavior’ File
79. Super Fantastic CSS Navigation Image Rollovers
80. Vertical Menu with Hover Effect using CSS
81. How To Create A ‘Mootools Homepage’ Inspired Navigation Effect Using jQuery
83. Create a Social Media Sharing Menu Using CSS and jQuery
84. CSS3 Minimalistic Navigation Menu
85. Beautiful Slide Out Navigation: A CSS and jQuery Tutorial
86. Awesome Cufonized Fly-out Menu with jQuery and CSS3
87. Two CSS vertical menu with show/hide effects
88. Animated Drop Down Menu with jQuery
89. Clean and Attractive jQuery Vertical Menu Tutorial
91. CSS menus
94. Reinventing a Drop Down with CSS and jQuery
95. Drop-Down Menus, Horizontal Style
96. CSS Vertical Navigation with Teaser
97. jQuery style menu with CSS3
98. Green Vertical Navigation Menu
99. CSS: Sexy Vertical Popup Menu with CSS
We hope you have enjoyed this list of CSS navigation menus and found something useful for your site (We made a point of including a mix of different menu styles: basic menus, flashy menus, menus which use jquery, menus that use pure CSS etc). If you know of any other great CSS menu tutorials, please feel free to share them in the comment area. :)
So the other day I was trying to get text input fields to have the same height across browsers. I figured I could use the line-height property for this, but no such luck. Well, it does work in WebKit browsers, but not in Firefox.
When looking closer at why I discovered that Firefox specifies line-height for form controls in its user agent stylesheet using the !important keyword. Since you can’t override that, a workaround is necessary.
Copyright © Roger Johansson
