Unfortunately inner elements can break rounded borders as Richard Rutter described when using <img> elements inside an element with border-radius. He also provided a useful solution which is webkit only, unfortunately.

Inner elements with background colors can also break border-radius. But there is a way around that too: apply border-radius to the offending inner elements too.

The problem

Here’s an example (view in Firefox 2+ or Safari/Chrome) where border-radius gets broken:

(If you are reading this in an RSS feed reader, you might need to go to the page to see the example properly)

A div containing a blockquote and a paragraph to mention the source of the quote:

Notice the bottom corners aren’t right: the background of the source paragraph breaks through the rounded corners.

The rounded corners are achieved using something like this:

.blockquote-with-source {
  border:1px solid #e8eac8;
  border-radius:10px;
  -moz-border-radius:10px;
  -webkit-border-radius:10px;
}

(The above code is of course slightly more than necessary due to both mozilla and webkit implementing them via their rendering prefixes.)

The ideal solution

overflow:hidden on inner elements should do the trick, but doesn’t work in Safari, Chrome or Firefox (although will work for the webkit-based ones for images as Richard Rutter points out in the above link).

Workaround for non-image elements with backgrounds

There are a few ways to work around this:

Apply border-radius to the inner element breaking the rounded corners

If you are using background color (or background image) on the inner HTML element, you can apply border-radius to them too:

In the case of the above example, we just need rounded corners on the bottom left and bottom right of the source paragraph:

.source {
    border-radius-bottomleft:10px;
    border-radius-bottomright:10px;
    -moz-border-radius-bottomleft:10px;
    -moz-border-radius-bottomright:10px;
    -webkit-border-bottom-left-radius:10px;
    -webkit-border-bottom-right-radius:10px;
}

The final styled quote would then look like this:

(If you inspect the above with Firebug or equivalent, you’ll notice I used slightly different CSS classes so it just fits with the current theme on this blog, but the principle is the same.)

Drawback to the above workaround

The main one I can think of is that you have to maintain the border radius value in more than one place — CSS variables would be nice here

Thick enough borders hide the problem

If your design allows it, thick borders on the element using border-radius may do the trick.

In the example below, I use a thick border on the left side of the containing div, with border radius only on the bottom right of the source paragraph:

The thickness of the border is the same as the size of the radius, though you don’t have to do that.

Drawback to the above workaround

When using one thick border as above, it doesn’t render as nicely in webkit as it does in gecko. Don’t know if that is vagueness in the spec, or what…

However, if all four borders are given the same width, then it seems ok.

Workaround for image elements

As Richard Rutter commented, putting an image as a CSS background image would do the trick, but that isn’t always ideal or possible (e.g. an image that is important as part of the content is better marked up as <img>).

Are there other, perhaps better, ways to deal with this?

Still, I have been using display:table on a much larger site for about 6 months now, so I thought I might as well post this as it is, and perhaps follow up with more examples later.

Also, about 3 weeks after I started this draft, Rachel Andrew and Kevin Yank wrote a book on CSS display:table for layout, as well as a useful summary article! I do recommend looking at that article for finer details.

No need for css float for layout in modern browsers

For a few years now, web developers doing CSS-based layouts have used floats or absolute positioning for layout web sites to avoid using non-semantic HTML <table>s.

While doable, extra hoops often have to be jumped through (mostly for IE) and some seemingly simple things can be harder than necessary (like equal height columns).

However, for a simpler solution, CSS-based display:table, display:table-row, display:table-cell etc are all usable today across Firefox 2+, Safari 3+, Opera 9+ and IE8.

Example:

Consider the following HTML:

<body>
	<div id="header">
		<!-- header -->
	</div>

	<div id="content-body-wrapper">
		<div id="content-body">
			<div id="primary-nav">
				<!-- some navigation column here -->
			</div>
			<div id="secondary-nav">
				<!-- some additional column here -->
			</div>
			<div id="content">
				<!-- main content here -->
			</div>
		</div>
	</div>

	<div id="footer">
		<!-- footer -->
	</div>
</body>

And the CSS to style it to get equal height columns:

#content-body-wrapper {
    display:table;
    border-collapse:collapse;
}

#content-body {
    display:table-row;
}

#primary-nav, #secondary-nav, #content {
    display:table-cell;
}

#primary-nav, #secondary-nav {
    width:20%;
}

#content {
    width:60%;
}

And that’s it!

The above is just the layout bit of the CSS. Here are some screenshots (click for full size) with content and very basic styling just to see the equal height column effect:

The first is with Firefox 3 and the second with IE8.

You can actually omit extra divs, even the one that gets display:table and the browser is required to create an anonymous table for you.

Isn’t using table for layout wrong?

This is not the same as using the structural html table elements for layout purposes — that indeed is an inappropriate use for tables.

This is using CSS to give table-like display, which is fine as it leaves the HTML (and document structure) in tact.

What about IE 7 and 6?

IE7 and 6 of course remain problems, but you can use conditional comments and give them older techniques that attempt to achieve this.

Some limitations or issues

Some limitations of css display:table I have come across, however, include these:

• Lack of colspan/rowspan equivalents
• Like HTML tables, a CSS cell can expand in width based on content (as well as height).

On the last one I noticed this when using things like <pre> even with overflow:auto with the thought that just like inside floated columns with widths assigned this would result in those <pre> blocks getting horizontal scrolls if they became too wide.

Instead, as with HTML tables, they push out the cell they are in. The only workaround I knew to this was to give a px or em width to such elements. (It also applies to large images in a cell.)

That being said, display:table seems a lot cleaner!

CSS3 has an advanced layout module in the works but there are not any browser implementations of it (that I am aware of), so in the interim this could be a useful approach.

More info

• W3C specifications on CSS display:table
• Rachel Andrew: Everything you know about CSS is wrong

Translations

Update: May 2010. Translated into Belorussian, by PC.de

Why bother?

Visual designs often require hiding text in such a way that screen readers will still read the text and thus provide extra context for the screen reader user.

For example, a visual design may make the main navigation section of the page obvious and so a heading to announce it may be unnecessary or undesirable.

However, from the perspective of good document structure/semantics and accessibility, it would be good to have the heading in there.

Screen reader users, for example, often scan a page through having a list of headings being read out to them.

The problem of display:none in CSS?

display:none in CSS would seem ideal (plus some additional rules in an aural stylesheet, perhaps).

Unfortunately, screen readers are inconsistent in the way they handle display:none.

In addition, most do not yet support the aural stylesheet sufficiently.

Positioning text off the screen is more reliable

For years, I have been using an “off-top” technique whereby content can be moved off the top of the screen, in such a way that it will still be read out by screen readers. Here is an example:

.css-label {
    height:1px;
    left:0px;
    overflow:hidden;
    position:absolute;
    top:-500em;
    width:1px;
}

A simple example of using the above may be to provide a header to a section such as the navigation:

<h2 class="css-label">Navigation</h2>

Some use use an “off-left” approach instead, though it seems to cause the odd problems with earlier versions of Opera and Safari (any one using those anymore?)

That being said, a comment left on Gez Lemon’s post about display:none issues answers my question of whether off-top is better or not than off-left saying there may be some issues with off-top. I’ll need to look into that further, but either of those are certainly better than using display:none.

More information

For further reading, see the following:

• Hiding Content from View, AbilityNet, November 2007
• Screen Readers and display: none, Gez Lemon, Juicy Studio, 12 October, 2007

Will search engines see this as keyword stuffing?

A comment left on Gez Lemon’s post asked what would be the impact on search engine listing?

Comments are closed on that post, so I will try to answer it here, as it is something I have been wondering for a long time.

The concern from an SEO point of view is that search engines may think you are tricking them even though this is a legitimate techniques for a legitimate purpose. However, some people could use these techniques for keyword stuffing, thus putting this useful technique in jeopardy and making it harder to provide sufficient context to assistive technologies.

Search engines would likely have a hard time detecting this in an automated manner

But for search engines to detect this they would at least need to parse all the CSS. Then, they would have to looking for all the different permutation of these rules and be 100% sure this is being done for keyword stuffing and not for some other legitimate reason.

Sounds tricky (and easy to circumvent — e.g. by using JavaScript to set these styles, as it is only being hidden from visual user agents).

Or, search engines would need to implement an entire DOM and calculate where on a screen all the text would go. Some major web browsers struggle to do this properly, so search engines aren’t likely to do it too well either, I would think.

But they may use manual checks for better results; that would be good for legitimate use of this technique

However, while automation and throwing lots of servers at a problem may seem problematic (for now!), these things require human, subjective, interpretation. So why not have people check sites manually?

Google, for example, does have a little army of people to manually verify sites are not using unfair tricks. So I guess if they are concerned about this particular technique, they might be able to get software to go a certain distance and then flag up suspicious cases to be manually checked. Legitimate sites should then be okay.

More information

But don’t take this as advice! Search engines often change the way they work! So check out this article from SEOMoz, a prominent SEO web site: A Comprehensive Guide to Hidden Text & Search Engines (10 July, 2007).