I did a brief web search for this bug when it reared its ugly head, but came up empty. So either I just didn't search well enough, it hasn't been documented, or I've discovered a new IE rendering bug. Likely I didn't look hard enough, I'm sure.

IE6 incorrectly treats text-indent for the contents of (at least) the p element when the contents start with child element with a negative text-indent.

Take this code, for example:

<div style="border: 5px solid #aaa; width: 20em; margin: 1em auto">
  <p style="margin: 0; padding: 0">
    <span style="text-indent: -30px">OOO</span>XXX
  </p>
</div>

FireFox 2.0.0.6 correctly renders the code like this:

IE6 renders like this:

IE brand of flare

IE's rendering is incorrect in the following ways:

1. Per the spec, text-indent only applies to block elements, so should be ignored in this case
2. Also per the spec, the visibility of text overflowing the container should correspond to the value of the overflow property (which should default to visible)

Adding insult to injury

Now let's make it a bit more interesting. Floating the span will convert it to a block element automatically, whereby it meets the requirements to apply the text-indent.

<div style="border: 5px solid #aaa; width: 20em; margin: 1em auto">
  <p style="margin: 0; padding: 0; color: #00f">
    <span style="text-indent: -30px;float: left; color: #f00">OOO</span>XXX
  </p>
</div>

Here's how FireFox 2.0.0.6 correctly renders it:

and with text-indent: 30px

And what IE does with it:

and with text-indent: 30px

So let's add to the list:

3. The text-indent assigned to the span was also applied to the p!
4. A side effect of #3 is when using negative indenting, the parent's content can overlap the child's content
5. Another side effect of #3 is that the p content can leave its container.

More to point #5

For clarity, now that we have a proper block element implementing the negative text-indent, you can see what should happen with the p content when the floated span leaves the container.

<div style="border: 5px solid #aaa; width: 20em; margin: 1em auto">
  <p style="margin: 0; padding: 0; color: #00f">
    <span style="text-indent: -9999em;float: left;color: #f00">OOO
  </p>
</div>

Here's how FireFox 2.0.0.6 correctly renders it:

And IE:

I've got nothing

I'm unhappy to report that while similar to the IE doubled-margin bug, this case isn't fixed by applying display: inline.

I have no fix. I don't believe I've ever debugged IE applying a style property to the assignee's parent element, so I'm at a loss. The text-indent shouldn't be reverse-inherited to the containing p. That much is clear. I haven't spent much time "researching" a fix, so I have no suggestion other than to berate IE6 with renewed vigor and change your markup or style in disgruntled defeat.

In preparation of some posts introducing some fun things to do with the line-height CSS declaration, I put together this page detailing some rendering inconsistencies between browsers. Most notably, IE6's version was ...unique.

You're on a website doing something. They've given you the tools to do it, and you're stepping through the workflow (let's call it A). In order to finish it, you need to take a side trip through a separate workflow (B). You follow the link provided on the A page to do B. You complete workflow B and are returned to ...the B workflow. Wrong answer. I recently encountered this scenario and it was maddening. For bonus points, workflow B had no link back to workflow A. I've decided to call this a "lollipop workflow". You're going from point A to point C, and have to cross through point B to get there. Trouble is, all roads from B lead to B.

It's called context

It's up to developers to understand the user experience they're creating. Respect what your users are doing beyond the current page and beyond the current workflow. It's called context, and it can work very much like code blocks. while (the user is doing A) { if (they want to do B) { // They're still doing A while (they're doing B) { // They're doing B within the context of doing A } // They've finished B, but they're still doing A } // That's right. Still doing A! } Savvy?

Every site has nouns and verbs. What I call nouns are the individual pieces of information that fall into your site structure. Verbs are activities that your users engage in.

Nouns

The nouns are the objects, sectional breakdowns, and data that pull most of the weight in structuring the site or page IA. Nouns create context.

• You are here
• This page primarily contains information about an object of type A
• This page also contains some info about objects of type B and C, which are related to A thusly
• This is the information on the type A object you selected
• This is a list of other nouns that we have content about
• etc...

They are the primary drivers of navigation menus, breadcrumbs, and headings. Linked nouns typically take users to information based destination pages. Browsing a site via noun links is an information gathering, exploratory exercise. You're offering information to your users. Following a noun link should generally not alter the mode of a user session. Object meta data and content text blocks support your nouns and may contain noun links as well. In my opinion, verb links in meta data and text blocks should be kept to a minimum. As the designer, you should recognize the nouns on a page and their relationship within your site AI. In the example above, if there is value in offering more information on a specific type B object than displays on the type A page, the noun should be linked to a drill down page focusing on the type B object. I'll repeat myself for emphasis: The noun should be linked. Don't leave the noun as raw text, then add an arbitrary verb link such as read more.... If your typography is clear, it should be obvious that the noun is a link, and that's enough.

Verbs

Verbs keep your users on your site. Some verbs are for your benefit, such as site registration; others for their benefit, such as purchasing something. In general, sites built to directly bring in revenue are built around verbs. If you have a site where your users can engage in unique or profitable activities or workflows, then by all means, invite them to do so. And make a big deal out of it! Verbs give your users a sense of ownership. They engage users to intellectually protect their experience on your site. The user is doing something and you are helping. The better and more transparently you do your job (helping), the more likely they will stay on your site. On any given page, you should be inviting your users to act. The language used in your verbs should be plain and clear. The visual prominence of verbs should reflect their importance to your users (not to you). If a user is engaged in a multi-step workflow, tone down verbs not directly related to their path. If the page is informational, or a functional terminus, then present them with an obvious doorway to somewhere they can act again. Presenting them with contextually useful verbs keeps the user moving forward. If there are textual verbs on page representing actions the user can take, they should be linked. If the user can't take these actions from this page, then you need to reconsider their inclusion in the content. If their presence is informational ("You will be able to do X") then identify in the text or typography that the function is potential, not a starting point for that action. Make the verb into a noun, basically. Linking this noun should target a page or popup with more details about the action. Treat your verbs with respect. Display them prominently and with pride. Being good to them is being good to your users, and being good to your users is good for your bottom line.

Overriding common word definitions or conventional perceptions in your interface is a one way ticket to Sorrowsville. Written language is a series of symbols that describe concepts. Dictionaries exist to document the concepts commonly agreed upon by the general public. I realize that language evolves (though I sometimes lament just how it evolves), but when it comes to user interface design, I find it's best to stick to conventions when it comes to naming features. Example: inbox. The inbox paradigm implies a collection of items (usually of a unified type), populated via submission from external sources. What's in it is usually news to you. If you're writing an application and you have a feature that behaves in these ways, then by all means call it an inbox if that suits you. Actually, unless there are extenuating circumstances or the nomenclature would be somehow confusing to the user, you probably should call the feature an inbox. However, if the feature doesn't satisfy the conventional definition or supports numerous behaviors beyond that of the definition, you should absolutely not call it an inbox. The value of following convention is that you don't need to teach your users how to do things. This saves them time and brain power. You're helping them not have to think.

The Swiss Army Inbox™

Let's suppose that you have an application which misrepresents the inbox convention. New users will encounter your inbox and expect X, but be delivered Y (which may = X + Z). Strike one! You've unnecessarily made new users think. Over time, your users will learn that your inbox can do Y, at which point, the inbox symbol comes to represent Y (within the context of your application). They don't think about the connotations of the word anymore, they perceive it symbolically as a tool, useful to accomplish their goals. If you later realize there is a better name for the feature (which there most likely is), you can't simply rename the current feature without compromising user expectations. Pulling the rug out from under your current user base like that would be strike two. Now what happens if a new revision of your application includes a feature that perfectly fits the inbox convention? Well, you're out of luck, because the word has already become symbolic of a different interaction model. And don't even think about creating a conventional inbox along side your non-conventional inbox, because that breaks your lexicon. I've used the inbox paradigm as an example, but the same policy holds true for all mature conventions. Emerging conventions aren't as volatile, but you do run the risk of choosing a representation that will become dated as the new convention matures. Feature naming is often one of the hardest parts of building an interface. Just be careful when you include conventional terms in your naming options. You might be looking at trouble ahead that you didn't expect.