Posts in the CSS Category

I wasn’t going to do it.  It would take too long, draw too much energy and attention.  Too many other things needed to be done first.  But it tasked me.  It tasked me!

So: here’s a browser timeline built out of a table.  I’ll say it now: this does not work in IE6 and IE7.  I’m not sure it’s possible to do, at least not cleanly, given the markup I used.  I’ll explain what I mean in a bit.

In order to structure this data, a table seemed to make the most sense, although even it wasn’t perfect.  There really wasn’t anything that seemed an exact fit, to be honest.  Definition lists didn’t really fit the bill (is a browser defined by its release dates?).  Plain old (un)ordered lists were a little better, but not enough.  In the end I just kind of ran with the idea that time sat on one axis and browsers sat on the other axis—like a table.

Given that decision, I needed to decide exactly how to group the data.  After a moments’ thought, I decided that I wanted to group the release dates by browser instead of by year.  Given the way tables are structured, that means every row corresponds to a browser, each data cell in the row represents a year, and the contents of each cell are the versions released in that year.

So here’s an example of a table row:

<tr title="Internet Explorer for Windows">
<th scope="row">
   <img src="icons/msie.png" alt="Internet Explorer for Windows" />
</th>
<td class="y1996"><p title="August 1996">3.0</p></td>
<td class="y1997"><p title="October 1997">4.0</p></td>
<td class="y1998"></td>
<td class="y1999"><p title="March 1999">5.0</p></td>
<td class="y2000"><p title="July 2000">5.5</p></td>
<td class="y2001"><p title="August 2001">6.0</p></td>
<td class="y2002"></td>
<td class="y2003"></td>
<td class="y2004"></td>
<td class="y2005"></td>
<td class="y2006"><p title="October 2007">7.0</p></td>
<td class="y2007"></td>
<td class="y2008"></td>
<th class="end"></th>
</tr>

(And yes, that’s drawn straight from the example, with no simplification and very minimal formatting.  I really wanted to pare the markup down as far as I could.)

The other choice was to have each row represent a year, and each cell represent a browser.  The non-graphical Wikipedia timeline has each row represent a month, not a year, but same general idea.  I totally understand why the Wikipedia timeline is top-to-bottom: it’s much, much easier to update and have render within the Wikipedia layout.  A new month is a new row in the table.  Easy peasy.  Fair enough, but I’m not here to do what’s easy.

Then there was the question of how to structure the version numbers within each year.  I resisted using ordered lists because in most cells there would be only one version number, and there’s nothing in the world of semantic markup that rubs me the wrong way more than a one-item list.  So I went with paragraphs.  I don’t particularly like that either, but short of inventing my own elements and writing a new DTD to support them, I couldn’t come up with much better.

One thing I’m still uncertain about is my decision to title the dates while having the actual content be only the version numbers.  Would it be better to put the dates into content and wrap distinct elements around the date and version numbers?  I’m honestly not sure.

Anyway, having settled on that structure, I had to answer the question of what to put on which axis in the layout.  Should I put the axis of time across the top, as I did originally; or down the side, as in the non-graphical Wikipedia timeline?  Put another way, should the timeline layout be horizontal or vertical?

I went with horizontal.  For whatever reason, I have a strong preference toward timelines scrolling left-to-right, not top-to-bottom.  Yes, even though it invokes that dread abomination, the horizontal scrollbar.  As it happened, given my structural decision, the same effect occurs even in an “unstyled” state.  If I’m just looking at the table with no author styles applied, I see the browsers down the left and the time across the top, proceeding from past to future from left to right.  That might seem convenient from a final layout point of view, except for the fact that I ended up completely ripping the table apart and, in effect, reassembling it with positioning.  This wouldn’t have been necessary had browsers allowed table cells to become containing blocks when they’re set to position: relative.  But they didn’t.

Frankly, I don’t have room here to go through all of the techniques I used and decisions I made.  Doing so would probably require a very long article, or else a very small book.  I did want to spotlight a few things:

• In keeping with my desire to minimize the markup, I cut way back on classes.  In fact, the only classes I use indicate which year a cell represents, such as y1999, and end to indicate that a cell is at the end of a row.  (I could have dropped all those classes as well, but chose to keep them for reasons too varied to explain here.)  The paragraphs containing the version numbers, as an example, are completely unclassed, nor do they have IDs.  And yet I was still able to position them appropriately within each year.  How?  Check the markup sample to see if you can figure it out; I’ll give the answer later on.

• I used ems for the sizing of just about everything, so this should be extremely tolerant of changes in text size.  The icons get a bit weird at extreme deltas, but I’m willing to accept that.  Anyway, we all may have full-zooming browsers within a year or three and will leave text-zooming to history.  The nice thing about using ems here, though, is that no matter which flavor of zooming you have to hand, the timeline will accommodate you.

• I came across at least two things that were of “is this a bug?” interest.

  1. Assigning position: relative to table cells failed to make them containing blocks for absolutely-positioned descendant elements, as I mentioned before.  Changing their display to block allowed them to be containing blocks, but completely shattered the table layout—elements have to have a display of table-cell to act like table cells.  That makes sense, but the lack of containment when relatively positioning the table cells did not.  Turns out that’s permissible as per CSS2.1: 9.3.1: “The effect of ‘position:relative’ on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined.”  Oh well.

  2. Where two elements overlap and both have :hover styles, only the “topmost” (the element higher up on the Z index) of the two gets its hover styles, at least in the browsers I tested.  The handling of hover styles has been an area of debate in the CSS community for quite a while—the CSS2.1 specification does a remarkable job of defining hovering without ever explaining how it should or shouldn’t work—but this single-event model seems unnecessarily restrictive after all these years.

• Speaking of bugs, I ran into an apparently insoluble problem with Explorer: its allergies over the combination of display and table markup.  Yes, I know, I built bar graphs out of table markup, and that worked fine (even in IE6).  Not so here.  In fact, I couldn’t even get the table element to generate an element box once I’d positioned most of its descendants and converted them all to display: block.  I mean, no matter what I did, it would not show anything.  No height, no width, no borders, no nothing.  I can’t even figure out what’s happening to the display role of the cells, most of which position but some of which still act like they’re cells.  I think.

  Anyway, I was able to get IE7 to recreate 99% of the layout but couldn’t stop the overlap of the table and the following text (“Sources”, et cetera) without throwing in an extra div after the table and using a CSS hack to set its height in only IE7 so as to force the text below the timeline.  No thank you.  So I took the hacks out.  I admit I’m disappointed this doesn’t work as it should in IE7, but I have to remind myself that the fact that it even got close (and it did) is reason for hope.  And if anyone figures out how to fix the layout problems in IE7 (I tried zooming and relatively positioning the table element; neither worked), please let me know how you did it so I can update the CSS and credit you.

  Were I to change the markup to nested lists or divs or something, I suspect it would all come together just fine in IE7.  Not IE6, though… for reasons I’ll explain momentarily.

  Update: Sam Rayner pointed out that an adjacent-sibling-based rule targeted at IE7 would provide a decent fix for the overlap, so I added it in.  The above commentary still stands, except now we have a way to work around the major oddities.  Thanks, Sam!

• One of the requests for the original timeline was to have an indication of actual dates and browser names.  Yeah, that’s not going to happen with images.  In this version, I was able to use title attributes to add in that kind of information, revealable in tooltips.  It also seemed like an accessibility win, although I’m not sufficiently expert in that field to know whether titles on things like table rows and paragraphs would really help.

• Regardless, that’s the answer to the question I posed earlier: instead of using classes, I selected elements based on the contents of their title attributes.  So, for example, I place all of the August releases within their respective years by declaring #timeline p[title~="August"] {left: 62%;}.  For another example, I dropped IDs from the table rows, and used the title information instead.  This is an extra reason why the layout fails in IE6 and earlier: no support for attribute selectors.  I suspect IE6 would do okay with the layout if I’d used classes (and non-table markup) instead, but the goal here was to flex my creative-code side and push the envelope to its edges.  So to speak.

  This approach did make my CSS a bit longer.  Selecting on attribute values can be a longer-winded process than on class names, which tend to be compacted to the point of being cryptic.  On the other hand, using attribute selection allowed the markup to be a lot simpler, which is a benefit when adding browsers and new release data to the timeline.  Which, I should note, is now a whoooole lot easier than when I was scaling down JPGs generated from PNGs that I’d saved out of Keynote after using it to draw the dots and lines and such.

No doubt you’ll have noticed that the structured timeline looks different than the graphical one.  I believe I could have recreated the original’s look, but I kind of like this one better.  It’s more interactive, certainly, and having those descending lines (between the top of the timeline on the release dots) might clutter things up too much when looking for information to hover.  If you get what I’m saying there.

I’ve also considered that it would be possible to do a dependency timeline like the SVG-based timeline available on Wikipedia.  Doing so would require an entirely different markup structure; there, nested ordered lists make all kinds of sense.  Once that’s in place, the rest shouldn’t be terribly challenging to work out.  Tedious, perhaps, but not challenging.  But don’t expect me to do it any time soon: it would take too long, and draw too much energy and attention from other things that need to be done.

• Structured Timeline was published on Monday, January 21st, 2008.
• It was assigned to the CSS category.
• There have been forty-five replies.

I’ve been pondering reset styles over the past few months, and come to a bit of a shift in my thinking.  Here’s the result of that thinking.

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	font-size: 100%;
	vertical-align: baseline;
	background: transparent;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}

/* remember to define focus styles! */
:focus {
	outline: 0;
}

/* remember to highlight inserts somehow! */
ins {
	text-decoration: none;
}
del {
	text-decoration: line-through;
}

/* tables still need 'cellspacing="0"' in the markup */
table {
	border-collapse: collapse;
	border-spacing: 0;
}

The small changes involve a paring down of the possible quotation around blockquotes and qs.  Before, I was explicitly pushing in empty generated content boxes with content: "", but there was no need.  A simple quotes: none; takes care of suppressing any automatic quotation marks on those elements.

The much bigger change, the shift in thinking, is the removal of the inherit values in the first rule—the ones that wiped out any boldfacing, italicizing, or font variants in browsers other than Explorer.  (You can see them in the “reloaded” post.)  I know, I know, I already defended that practice:

[The inherit] effects, as seen in my development environment, will still serve the purpose of reminding me to build up the styles I actually want, and not use the browsers’ defaults as a crutch. There is the possibility of my forgetting that (for example) IE/Win italicizes em when I don’t want it to, but that’s something I’ll catch during the browser testing phase.

But over time, I’ve come to realize that this is more than just a throwaway development tool.  It really is the beginning of a baseline style sheet.  (Or can be.)  Things like boldfacing and italics are some of the most obvious textual effects readers will see, and to have reset styles that treat them inconsistently across browsers doesn’t make sense.

Of course, browsers might treat elements differently when it comes to boldness and decoration and such.  But unfortunately, without inherit as a viable solution (due to the lack of support in Explorer), we’re stuck accepting browser defaults.  This is one area where defaults are pretty well consistent across the board, so it’s a small risk to be taking.  And this certainly doesn’t preclude anyone from adding to these styles to create their own reset that explicitly handles elements like em and strong.

Which leads me to why I explicitly set ins and del.  In some browsers, inserted text is underlined.  This leads to confusion, because most people expect underlined text to be a link.  I decided to explicitly switch that off and leave a note about it, much as I did with :focus styles.

And why am I not zeroing out deprecated elements, like center?  Because they shouldn’t even be in the markup.  The way to handle deprecated elements is with something like Marco Battilana’s Big Red Angry Text, not silently neutering them.

Comments and suggestions are, as ever, welcomed.  I’m going to shift the end result to its own URL, as I promised I would long ago, so that there will be a permanent home outside of the various postings.  Hopefully that will happen before the week is out.

• Resetting Again was published on Tuesday, January 15th, 2008.
• It was assigned to the CSS category.
• There have been one hundred eighty-eight replies.

On stage at An Event Apart Chicago, I made reference to recent efforts I’ve been making to develop a set of “diagnostic” styles.  I’d hoped to have them ready for presentation in Chicago, but didn’t get it done in time.

Well, they’re still not really done, but as I’ve now torn them apart and rebuilt them three or four times, with no real end to that cycle in sight, it’s time for me to get them off of my hard drive and into the public eye.  It’s a little bit complicated, so rather than post the whole thing in this entry, I’m going to link to a demonstration page.  I first want to say a few things about it, though.

The primary goal here is to have a set of rules that can be applied during the development phase of a new layout.  These rules’ aim is to visually highlight problems in the markup.  For example, here’s one of the rules:

a[href="#"] {background: lime;}
a[href=""] {background: fuchsia;}

That brings some eye-watering attention to any link that has an empty href, or is (most likely) being used as a JavaScript trigger with no fallback.

Where things got tricky was when I wanted to do things like higlight images that didn’t have alt or title attributes.  In a perfect CSS3 world, I could just say img:not(img[alt]) to select non-alted images.  At least, I think that’s what I would say—:not() syntax makes my temples throb.  Since I was developing these with the idea of releasing them to a more general development audience, though, I decided to use regular old non-:not selectors.

So what I ended up doing, in slightly simplified form, was this sort of thing:

img {outline: 5px solid red;}
img[alt][title] {outline-width: 0;}
img[alt] {outline-color: fuchsia;}
img[alt], img[title] {outline-style: double;}
img[alt=""][title], img[alt][title=""] {outline-width: 3px;}
img[alt=""][title=""] {outline-style: dotted;}

The logic works out like so:

1. Set all images to have a big red outline.
2. If an image has both alt and title attributes, set the outline width to zero.
3. If an image has an alt attribute, set the outline color to fuchsia.  This means the outline of any image that doesn’t have an alt attribute will stay red.
4. As long as an image has either an alt or a title attribute, make its outline style double.
5. If an image has an empty alt with any kind of title, or vice versa, make the outline’s width three pixels.
6. If an image’s alt and title attributes are both empty, then make the outline dotted.

Whew.  Maybe I piled a few too many conditions in there, but I wanted to get some finer granularity on the results, which you can see demonstrated (along with several other things, like highlighting table headers without scope attributes and tables without summary attributes) at the diagnostic demonstration page.  On that page, you’ll see a number of examples and the style sheet that drives them all.  If it’s getting in the way of seeing what’s going on, move the mouse over it to mostly clear it away without actually removing it.  Mouse back out to bring it back.  (Maybe I should reverse those states—what do you think?)

Admittedly, much of what these styles do can be replicated with tools like the Web Developer Toolbar.  The advantage I find with writing my own diagnostic styles is that I can tune them to present exactly the way I want them.  Outlining deprecated elements is fine, but what if I’d rather make them lime-green on cyan to really drive the point into my optic nerves?

Anyway, I don’t for an instant think that these constitute a replacement for the WDT.  They’re just another handy tool to have in the toolbox.

A final note: when actually using diagnostic styles, all of the declarations should be marked !important so as to ensure their application.  I left those directives out of the demo page for clarity’s sake.  If you’re going to use diagnostic styles of this sort in your own projects, remember that you’ll need to add them.

I’m putting these out for comment, suggestions, and general community improvement.  Anyone see things we could add or upgrade?  Let us know!

• Diagnostic Styling was published on Friday, September 7th, 2007.
• It was assigned to the CSS and Tools categories.
• There have been seventy-two replies.

I alluded yesterday to “backstage work”.  One of the things going on back there was my work with the folks at WebAssist to create a tool that allows both novice and experienced web developers to create and alter CSS-driven layouts.

The end result is Eric Meyer’s CSS Sculptor (v1.0.0), a Dreamweaver extension that gives the user tons of options and outputs pretty darned clean markup and CSS.  (Even if you’ve no interest at all in Dreamweaver tools, you should still follow that link.  How many chances are you going to have to see me throw the mëtäl hörns?)

Well you might wonder how much code I contributed to this software.  Well, okay, none.  What I did contribute was guidance on the interface and its organization; on what options to present, and how; on ways to handle things like print styles and the print CSS options; and on the CSS and markup that results, including the optional explanatory comments in the CSS.

One of the primary goals with this project was to create a tool that would expose as much CSS as possible to users without overwhelming them, and that would actually teach by dint of showing all the options.  One of the things we heard a lot in the beta test was users saying things like, “Oh, so that’s what that CSS thingy does! I’d always wondered.”  Which was exactly what we’d hoped to hear, along with “Hey, I’ve never heard of this CSS property before!”.  (We heard that one too.)

There are some things I expect will be improved in future releases, like shorthand value minimization—the simplest example of that being a condensation of 0 0 0 0 down to just plain 0.  We discussed including that feature but decided to postpone it for a variety of reasons, not least of which was working out the logic required to figure out when to minimize, which isn’t as simple a problem as you might first think.  There were a few other things we didn’t get in the initial release; such is the way of software.  We’ve got a list of potential features, of course, and are looking forward to hearing what users suggest.

As for what features did make it in, there’s a fairly large list, so it’s probably best to check out the Features page or take the product tour—with video commentary starring, you guessed it, yours truly.  So if you’ve ever wanted to see me greenscreened over screenshots and being intermittently goofy, then at long last your prayers have been answered!  (Or will be, once we get the load problems resolved.)

What makes this whole thing an especially interesting experience for me is that, for the first time in my life, I’m participating in an affiliate program.  Basically, what I earn from sales of CSS Sculptor depends on affiliate fees earned by referral links like this one here (and also earlier in the post).  That might sound like a rip-off, but it has the potential to be quite the opposite.  The affiliate cut is literally an order of magnitude greater than any reasonable per-unit royalty would be.

This compensation scheme (as they say in the UK) is actually an experiment on both sides: WebAssist has never really worked with an outside individual on a product like this, and so they honestly don’t know if the affiliate approach will pay better than a per-unit royalty, or worse.  So we’re going to try it out and see what happens.  Fortunately, I’m in a position that I feel I can afford to experiment like this, allowing both myself and WebAssist to find out what works best in the long run.

Thus, if you’re planning to buy CSS Sculptor or know someone who is, I’d be grateful if you either clicked through one of the links hereabouts or linked to the product using my affiliate URL.  I’ll have a link in the sidebar in the near future as well.  The sidebar’s due for an overhaul anyhow.

So that’s one of the things that’s claimed my time over the last few months, and I’m pretty excited that it’s seeing the light of release.  I’m even more excited about finding out what people think could be better about it so that we can improve what’s already a pretty darned nifty tool.  If I do say so myself.

• CSS Sculptor Released was published on Thursday, August 23rd, 2007.
• It was assigned to the CSS and Projects categories.
• There have been fifty-seven replies.

While kicking around some ideas at the CSS workshop I led in London, I ran into some interesting problems with :empty.  If you’re not up on what that one does, it’s a way of selecting elements that have no children, including text.  To quote the formal definition:

The :empty pseudo-class represents an element that has no children at all. In terms of the DOM, only element nodes and text nodes (including CDATA nodes and entity references) whose data has a non-zero length must be considered as affecting emptiness; comments, PIs, and other nodes must not affect whether an element is considered empty or not.

So kindly consider:

*:empty {
   padding: 0.25em;
   outline: 1px dashed red;
   background: yellow;
}

We (re)discovered something very strange right there in the workshop: given the preceding rule, Firefox applies it to the body element—which is, quite clearly, not empty.  You can check out the fun on my bare *:empty test page.  From there, we realized that if you prepend a body to the selector, yielding body *:empty, the problem vanishes, as you might expect.

As it turns out, this is a known bug in Gecko.  It’s been known for about 18 months, in fact.  So that’s why I was confused by Firefox’s behavior.

The other problem is that :empty in Firefox matches img elements, whether or not they cause an image to successfully load.  You can see this happen on the same test page.  While it’s true that img is an empty element, it’s still bringing in content, so from a common-sense point of view it seems that :empty ought not to match.

In re-reading the description from the specification, though, I can’t justify my common-sense interpretation—an img element has neither element nodes nor text nodes, so far as I’m aware.  The same is true for form inputs, even text inputs that have pre-filled value text; but not for textareas that have pre-filled content text.  But then br elements should also be selected by this rule, and they apparently don’t get matched at all, as the test page shows.  Bwuh?

Well, maybe it’s a bug.  What concerns me here is that the definition of :empty basically requires that things like images and inputs always be selected, which strikes me as kind of useless.  After all, if I wanted to select all images, I’d write img into my selector; ditto input for inputs.

My thinking is that the description should change to state that application of :empty is restricted to non-replaced elements.  Alternatively, it could be redefined to only apply non-replaced elements and to empty replaced elements that don’t either cause something to load or have values associated with them.

Which seems a better solution to you, and why?  Or, if you see a better approach than either of those, what is it?

• Running on :empty was published on Friday, August 17th, 2007.
• It was assigned to the Browsers and CSS categories.
• There have been twenty-three replies.

So while I was off indulging in the extravagance of an extended vacation/family reunion/road trip, seats went on sale for a two-day CSS workshop in London, starring yours truly and run by the fine folks at Carson Workshops, which will run 13-14 August.  The seats are something like half-sold already, so if you want in, don’t wait.  Sorry I didn’t say anything sooner, but, you know.  Family time!

To those who do decide to attend, I make this pledge: I will not wear the blue-shirt-with-tan-slacks combo again.  This I swear.

• London Workshop was published on Thursday, July 19th, 2007.
• It was assigned to the CSS and Speaking categories.
• There have been five replies.

Thanks to everyone who shared their thinking on the ordering of link states.  It looks like a minority of people were in favor of my preferred ordering, which is: Link-Visited-Hover-Focus-Active.

The reasoning is fairly straightforward, and starts with the assumption that a person who uses solely a keyboard to navigate won’t ever encounter a hover effect.  Thus, for such users, the states might as well simply be LVFA.  For them, the placement of the hover styles is irrelevant.

On the flip side, a person using a mouse to navigate will have far more links in hover states than focus states.  Once a link is selected (clicked) by a mouse-wielder, the link enters the active state until the user lets go of the mouse button.  Then it’s both in focus and hovered, at least until the mouse cursor moves away.  (It’s also either visited or unvisited, but that’s not relevant to the question at hand.)

So in this situation, I want to provide a visual cue that the link has in fact been clicked, even though the mouse button is no longer down.  I want this to happen regardless of the hover states of the link.  Therefore, the focus styles need to come after the hover styles.  If not, the focus color will only take effect once the mouse moves away from the link, thus exiting the hover state and removing the hover color.

Yes, this will only take hold in browsers that update the focus state while asking for the requested page.  While that isn’t all browsers, it’s most of them, from what I can tell.  Safari 2.x seems to be the notable exception.  (I didn’t test 1.x, and haven’t installed 3.x yet because I don’t want to lose 2.x.)

So what mnemonics can we use to keep this ordering straight?  I’ve come up with a few.

• LoVe’s Hurts Fade Away
• Luther Vandross Hits Fabulous Arpeggios
• Lord Vader Hates Furry Animals
• Lusty Vampires Hunger For Absinthe
• Lord Voldemort Has Foul Ambitions

What do you have?

• Who Ordered the Link States? was published on Monday, June 11th, 2007.
• It was assigned to the CSS category.
• There have been twenty-nine replies.

Spend any time at all writing above-beginner CSS, and you’re going to come across the “link-visited-hover-active” (LVHA) rule.  This holds that the four link states should always be listed in that order, like so:

a:link {color: blue;}
a:visited {color: purple;}
a:hover {color: red;}
a:active {color: yellow;}

Masters of the dark arts of specificity know why this rule exists and how it does or doesn’t apply, but if you’re still a padawan in these matters (or just rusty), you can get a quick refresher from this old chestnut of mine.

Now, it’s the case that this will become less of an issue over time becuase IE7 supports (and one presumes future versions of IE will continue to support) chained pseudo-classes, like a:link:hover {color: red;}.  Once you start chaining those you transcend a lot of the specificity-ordering concerns that drive the LVHA rule.  However, we’re not there yet.

Which brings me to the point of all this: the fifth possible link state, :focus.  Assuming we’re going to avoid chaining pseudo-classes for a while yet, but that we want to introduce link-focus styles, where should it fit in the ordering?  For the purposes of this discussion, assume the following:

a:focus {color: orange;}

a:link {color: blue;}
a:visited {color: purple;}
a:hover {color: red;}
a:active {color: yellow;}

We need to move the a:focus rule so it has a visible effect.  But where?  Should it come before a:hover, after a:hover, or after a:active?  In other words, which states’ styles should the focus style overwrite?

I’d like to hear your thoughts on the matter, and especially the rationale driving your answer.  Accessibility experts are particularly welcome to weigh in, but it’s anyone’s game here.

(Postscript: I know that many problems can be avoided by picking a different styling effect for the focus style, like a border or outline, or boldfacing or italicizing the text of a focused link.  Still, some people will want to handle everything through color, regardless of the problems this can cause for the colorblind or images-as-links, and I’d like to address that specific situation.  Thanks.)

• Ordering the Link States was published on Monday, June 4th, 2007.
• It was assigned to the CSS category.
• There have been twenty-two replies.