266

In modern web development I'm coming across this pattern ever more often. It looks like this:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

And in CSS there is something like:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

* (Class name are illustrative only; in real life those are normal class names reflecting what the element is about)

I even recently tried doing this myself because... you know, everyone's doing it.

But I still don't get it. Why are we doing this? If you need a table, then just make a blasted <table> and be done with it. Yes, even if it's for layout. That's what tables are for - laying out stuff in tabular fashion.

The best explanation that I have is that by now everyone has heard the mantra of "don't use tables for layout", so they follow it blindly. But they still need a table for layout (because nothing else has the expanding capabilities of a table), so they make a <div> (because it's not a table!) and then add CSS that makes it a table anyway.

For all the world this looks to me like putting arbitrary unnecessary obstacles in your way and then doing extra work to circumvent them.

The original argument for moving away from tables for layout was that it's hard to modify a tabular layout afterwards. But modifying a "faux-table" layout is just as hard, and for the same reasons. In fact, in practice modifying a layout is always hard, and it's almost never enough to just change the CSS, if you want to do something more serious than minor tweaks. You will need to understand and change HTML structure for serious design changes. And tables don't make the job any harder or easier than divs.

In fact, the only way I see that tables could make a layout difficult to modify, is if you abused them and created an ungodly mess. You can do that with divs too.

So... in an attempt to change this from a rant into a coherent question: what am I missing? What are the actual benefits of using a "faux-table" over a real one?

About the duplicate link: This isn't a suggestion to use another tag or something. This is a question about using a <table> vs display:table.

  • 6
    @JuhaUntinen: that... sounds unlikely. Source? – Paul D. Waite Apr 1 '15 at 13:35
  • 5
    @PaulD.Waite - It's actually still true today, I think. Read the other answers. Unless the table has table-layout:fixed, it will need to load entirely before it can be displayed. With modern broadband this effect is simply less noticeable. – Vilx- Apr 1 '15 at 15:48
  • 4
    @JuhaUntinen: That's not entirely accurate. The table rendering engine was slower when you used percentages for column widths as the entire table had to be downloaded before the browser could start figuring out how big to make everything. This was over complicated by nested tables. However, there were then (and still exist) ways to make table rendering FAR FAR faster. Just very few devs bother to learn their craft well enough and instead jump on bandwagons. – NotMe Apr 1 '15 at 15:58
  • 4
    Back in the even older days we used to mimic divs with tables so there. – Wyatt Barnett Apr 1 '15 at 17:57
  • 4
    Somebody read they weren't supposed to use tables for layout and took it to mean they weren't supposed to use tables at all. I detest this trend. – Casey Apr 4 '15 at 18:45
116

This is a common pattern for making responsive tables. Tabular data is tricky to display on mobiles since the page will either be zoomed in to read text, meaning tables go off the side of the page and the user has to scroll backwards and forwards to read the table, or the page will be zoomed out, usually meaning that the table is too small to be able to read.

Responsive tables change layout on smaller screens - sometimes some columns are hidden or columns are amalgamated, e.g. name and email address might be separate on large screens, but collapse down into one cell on small screens so the information is readable without having to scroll.

<div>s are used to create the tables instead of <table> tags for a couple of reasons. If <table> tags are used then you need to override the browser default styles and layout before adding your own code, so in this case <div> tags save on a lot of boilerplate CSS. Additionally, older versions of IE don't allow you to override default table styles, so using <div>s also smooths cross-browser development.

There's a pretty good overview of responsive tables on CSS-Tricks.

Edit: I should point out that I'm not advocating this pattern - it falls into the divitis trap and isn't semantic - but this is why you'll find tables made from divs.

  • 6
    I'm accepting this answer because it seems that nothing else useful is coming in anymore. There are higher-voted answers but they basically say "because semantics" (and the only reason for semantics that they can provide is screen readers, which doesn't convince me). @HorusKol's answer mentioned responsiveness before yours, but yours is more to the point. If a better answer appears in the future, I will change that to be the accepted one. – Vilx- Apr 3 '15 at 23:10
  • 5
    This is ridiculous and lazy. Anything you're doing with <div> “tables” could probably be done with regular ones, so there's literally no reason (apart from old IE versions and laziness) to use non-semantic elements for building tables. That said, actual tabular data seems rare on the internet so maybe this is a non-issue. – You Apr 4 '15 at 9:17
  • 1
    @Vilx: The question you posed is "Why are people making tables with divs", which is what you are getting answers to. For example you might not care about screen readers, but that doesn't change that accessibility is a real concern for many, and (together with search engines) the major reason many people choose semantic HTML. – JacquesB Apr 4 '15 at 19:07
  • 13
    For all intents and purposes, this is plain wrong. If your data is tabular, it goes in a table. Claiming that tables behave especially evil on a mobile device is BS. You can just as easily change the display properties of table elements to be non-table values as you can make non-table elements have table values. – cimmanon Apr 4 '15 at 19:08
  • 8
    I believe this answer is slightly misleading. Responsive tables is good design, but it is independent of the question if you should use <table> or <div> - you can use either to the same visual effect. Indeed, this is core in the idea of separation of structure and presentation. It is true that older versions of IE didn't allow overriding the style of table, but older versions of IE didn't support display:table either, so you couldn't use responsive tables either way. – JacquesB Apr 4 '15 at 19:39
154

The question is if the data is semantically a table (i.e. a set of data or units of information logically organized in two dimensions) or you just use the grid for visual layout, e.g. because you want a sidebar to expand or something like that.

If your information is semantically a table, you use a <table>-tag. If you just want a grid for layout purposes, you use some other appropriate html elements and use display:table in the style sheet.

When is data semantically a table? When the data is logically organized along two axes. If it makes sense with headers for the rows or columns, then you might have a semantic table. An example of something which is not semantically a table is presenting a text in columns like in a newspaper. This is not semantically a table, since you would still read it linearly, and no meaning would be lost if the presentation was removed.


OK, why not use <table> for everything rather than only for something that is semantically a table? Visually it is obviously the same (since the table element just have display:element in the default style sheet).

The difference is that the semantic information can help alternative user agents. For example a screen reader might allow you to navigate in two dimensions in the table, and read the headers for a cell for both axes if you forget where you are. This would just be confusing if the table was not semantically a table but just used for visual layout.

The <table> versus display:table discussion is just a case of the more general principle of using semantic markup. See for example: Why would one bother marking up properly and semantically? or Why is semantic markup given more weight for search engines?

In some places you might actually be legally required to use semantic markup for accessibility reasons, and in any case there is no reason to purposefully make your page less accessible.

Even if you don't care for disabled users, having presentation separate from content gives you benefits. E.g. your three column layout could be presented in a single columns on a mobile using an alternative stylesheet.

  • 14
    @Vilx- why use <em> and <strong> rather than <b> and <i>? Because <b> and <i> are not about the semantics of the tag. <table> has semantic meaning. Using it for something that isn't a table makes it harder to understand the semantic meaning of the document. – user40980 Mar 30 '15 at 18:54
  • 22
    @Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. Putting <i> around best would be wrong because that means something different than the <i> around the book title. For more, see Why are the <b> and <i> tags deprecated? and What's the difference between <b> and <strong>, <i> and <em>? – user40980 Mar 30 '15 at 19:18
  • 19
    If you don't care what your content means, I strongly suggest you stop using any elements except for forms and divs. Just add classes to apply styling and behavior. – Rich Remer Mar 30 '15 at 22:45
  • 9
    @Vilx-: When you say you care about the experience of your users you seem to only mean a subset of your users. The main reason for using markup correctly in the way you are describing is for accessibility, which directly relates to the user experience of disabled users. These are the people that benefit from you doing thing the right way and ignoring these conventions means likely making their web experience harder. – rooby Mar 30 '15 at 22:55
  • 31
    @Vilx-, yes, a screen reader does treat a <table> very differently from a <div>. <div>s are mostly ignored and read sequentially. Inside a <table> it has to provides different navigation keystrokes/commands ("Jump to cell to the right", "Read column and row title", and so on), and voices different location information (when the reading stream enters a table it goes something like "Table 3, row 1 column 1, Lorem Ipsum dolor...") – Euro Micelli Mar 31 '15 at 0:12
102

Actually, I would say that the use of class names like "table" in your example demonstrates how people don't actually understand what they're doing when trying for semantic markup. They get marks for trying to show that the content is not tabular data, but they lose marks for bad class names.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

All that this developer has done is replicate the original <table> markup with CSS class names. This means as soon as this layout is not a table, the class names are at odds.

What this developer should have done is consider what information is in the table - is it a thumbnail gallery? Well, then:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Now I can create some adaptive CSS:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Why divs and not tables

A table contains tabular data - presentation of a table is inextricably linked to the structure of a table. Tabular data will always need to be in tabular form no matter where you put that content or on what screen/device you want it to display.

A thumbnail gallery (or many other things, like a registration form, a menu, and more) is not tabular data. It may be presented like a table in some design layouts, but in other cases, like narrow phone screens, you want it using more traditional block layouts. Or perhaps you want to display thumbnails in a sidebar instead of in the main content area.

Your choice is now to output different markup for the wide screen content (tables) and sidebar or narrow screen content (divs) - which means your server side scripts will have to be aware of where the content is going if you're building this programmatically - or you have your server side script output the same markup (because it shouldn't care where you're putting this) and use different CSS rules for the different situations.

So, then you have a choice of always outputting tables, and then overriding the natural table display rules with block (which really should grind some gears in any developers head), or going with well labelled divs which allow more flexible approaches to styling.

And best practices for several years now has been to avoid tables when not needing to present tabular data.

  • The class names were actually just an example. In real life they mostly are properly descriptive. Anyways, in your example, why do you use <div> instead of <table>? What benefits does it offer? – Vilx- Mar 30 '15 at 23:02
  • 1
    Hmm... well, in your case you actually do two different representations of the same HTML via media queries. OK, that's a good use-case. But if this wasn't the case, and you'd know beforehand that this thumbnail gallery will be only displayed in one place and only in tabular format - would you use a <table> then or still display:table? Because, well, in a way it is tabular data. Except that the "data" is pictures, but still. – Vilx- Mar 30 '15 at 23:22
  • 15
    well, no, it isn't tabular data. you are presenting it in a grid that resembles a table. Tabular data is statistics and comparative information - think like a spreadsheet. Would you say that thumbnail view in Windows file explorer is tabular data? And, is this always going to be presented like a table? What if you want a different view style in 6 or 12 months? Why put in restrictions that have long-term effects for the sake of being obstinate in the face of widely accepted practice? – HorusKol Mar 30 '15 at 23:26
  • 12
    Except that it isn't tabular data, at all. There's no reason other than an arbitrary layout decision that this content resembles a table. It's not structured data in columns and rows, it's a list of content, laid out in a grid. -- edit: What HorusKol said. – Eric King Mar 30 '15 at 23:27
  • 3
    Well, OK, that was stretching it a bit. :) Well, you've given me something to think about! Thank you for that! I'm still not 100% convinced, but at least it's something to go on with. :) – Vilx- Mar 30 '15 at 23:43
11

In the olden days, the table rendering engine "appeared" slower when you used percentages for column widths. The engine essentially had to download the entire data set before it would then begin figuring out how big everything was to draw it on the screen.

The DIV engine was different. As the browser encountered a DIV it would go ahead and place it and start filling the content inline. Of course, div's might jump around as the data finished loading. Hence why I have appeared in quotes above. The time frame for completion of both was the same, however tables weren't drawn until the end which meant the user wasn't sure if it was loading or not for a second or two.

This became worse as tables were nested.

There were then (and still exist) ways to make table rendering FAR FAR faster. Basically by giving it a hint that column sizes aren't changing, then the browser starts rendering tabular data immediately. Ultimately this means that tables can actually display in the correct position faster than divs giving them the appearance of being better.

But that's not the whole story. The rest of it is that most devs simply don't bother to learn their craft well enough to know this. Instead they jump on various bandwagons and go with whatever code they can copy/paste from. Even today I find that very very few web developers know the difference from one doctype to the next - and that is the number one reason why various sites have all sorts of workarounds to cover various browsers.

So, +1 to you for asking the question.

  • Offtopic about the DOCTYPE: I thought that, although there was a theoretical difference (and validators did take it seriously), in practice browsers didn't really differentiate between them. OK, maybe there were some minor changes between HTML/XHTML flavors, but the version and DTD information at least was not used. Which is why HTML5 dropped the whole thing anyway and went with just <!DOCTYPE html> and which is why it happens to work even in old browsers like IE6. Have I missed something? – Vilx- Apr 1 '15 at 16:15
  • 2
    @Vilx: A doctype puts a browser into a certain mode. Among other things, it defines the box model in use. For a number of doctypes the browsers didn't line up because the box model used was different. This is why so many developers complained that the browsers showed pages differently and rather than fix the doctype, used massive css reset sheets. However, there have been a few doctypes in which all the browsers used the same box model - but those were never the default, you had to know them. – NotMe Apr 2 '15 at 19:52
  • @vilx: html 5 didn't drop the whole thing. Rather, a new doctype was added. Point is, that very first line that appears at the top of the html document is critical and if you don't understand what it does and how the various browsers react to it then you'll spend far too much time figuring out why your layout is "broken" in a particular browser. – NotMe Apr 2 '15 at 19:57
  • Wait, so there are different doctypes that make the same document render differently? Which ones? Mind you I'm talking about different doctypes, not doctype vs lack of doctype (aka quirksmode). – Vilx- Apr 3 '15 at 8:43
  • @Vilx: It is a bit more complicated, since some doctypes trigger quirks mode (same as no doctype) and some other doctypes (including the html5 doctype) trigger standards mode, and there is even some doctypes that trigger a third "almost-standard" mode in some browsers. – JacquesB Apr 4 '15 at 19:46
5

There are already tons of great answers here. But I wanted to add that table elements have rendering limitations that don't exist for div elements. Try and make a table that does virtual scrolling (like: SlickGrid, DataTables, and others) and you'll be sorely disappointed. It just doesn't work. Most (All?) modern Javascript grids use divs because the css allows for much more flexible rendering.

There are other limitations as well. My general rule is that if I'm going to see the whole table on a single screen, and I don't want any/much custom rendering for it I use a table element, otherwise I go with divs because I can control the results much, much more easily.

4

If I can get a little "meta" here, this brings two problems to my mind:

One: Someone proposes a rule for some good reason, and people completely miss the point by following the technical letter of the rule while ignoring the spirit. They find some way to accomplish all the bad things that the rule was trying to prevent, while still technically following the rule as worded.

Two: Someone sees a problem and proposes a rule to prevent it. Others see the value of this rule. Then they insist on blind devotion to this rule without regard to the original problem it was supposed to solve and/or regardless of what other problems it creates. I've had many conversations where someone says, "You must do X because that's the rule", and then I ask, "But why should we do X?", and they look at me with bafflement and exasperation and say, "But I just told you! Because it's the rule!" I reply, "But it seems to cause more problems than it solves. I think we'd be better off to do Y." And then the person says, "No, look, I'll show you. See, it's right here in this book. X is the rule."

In this case, we have a problem: The table tag does two things: One, it controls the layout of a document. Two, it conveys the idea that the enclosed data is made up of rows and columns of numbers or other data.

So many people proposed the solution: Don't use table tags to control layout of things that aren't logically "tables". Use CSS.

But there's a problem with this solution. The table tag and its subtags do many very useful layout functions that are not easy to achieve using CSS, and when they can be achieved, the code necessary to do it is often cumbersome -- difficult to read and difficult to maintain. Why should we do things in a clumsy, difficult way when there is a clean, easy way?

Personally, I think we would have been better off to just declare, "The fact that something is inside a table tag does not necessarily mean that it represents rows and columns of numbers." This would not have been an outrageous pronouncement. I have never heard someone say that the "p" tag can only be used for things that are really paragraphs of grammatically-correct, logically-constructed English sentences. I've never heard someone say that it is wrong to use a "ul" tag for a list that does, in fact, come in a logical order, just because you wanted bullets and not sequence numbers. Etc.

  • 7
    wrt to the last paragraph - you have read the HTML5 specification for those elements, haven't you? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/html/wg/drafts/html/master/semantics.html#the-ol-element - particularly, if order does matter, then use the ol element (since this is the structural part) - you can still present it as a bullet list using CSS – HorusKol Mar 31 '15 at 22:47
  • 5
    and if you look at the other two answers here, you will see that neither say simply "because it's the rule" - they both lay out very clear justifications for the rule and use cases – HorusKol Mar 31 '15 at 22:48
  • 1
    Hmm, seems to me that I said something like: "Someone sees a problem and proposes a rule to prevent it. Others see the value of this rule. Then they insist on blind devotion to this rule without regard to the original problem it was supposed to solve and/or regardless of what other problems it creates." I don't deny that there is reasonable thinking behind the rule. I just don't agree with the conclusion. Surely I can say, "You have a good point there, but nevertheless I disagree." And surely you do not deny that there are people who don't understand the pros and cons and say ... – Jay Apr 1 '15 at 13:35
  • 1
    ... "because it's the rule". I have had a number of conversations with such people over the years, on this particular issue and on many others. People who refuse to even discuss the pros and cons of a rule, because it's the rule, end of discussion. – Jay Apr 1 '15 at 13:37
  • There has emerged this unfortunate notion that HTML design has its roots in some abstract form of engineering rather than art. As such, in that vein, some have decided that there must be absolute rules analogous to physics, and gravity that must be obeyed, or someone who breaks such rules is departed from the "purer faith." Reality is that no browser nor design metaphor is infallible. Tread cautiously around those who insist the contrary. – David W Apr 4 '15 at 17:52
3

HTML and CSS have evolved a degree of flexibility that means that even conceptually "block" elements like <div> (HTML's oldest and most general form of block content) don't need to be displayed as blocks:

div { display: inline; }

As you note, <div> can be repurposed to emulate <table> and its fellow travelers. Actually, most tags can. Given their special roles, I doubt you could usefully remap macro tags like <html>, <head>, <body>, and <script>, but "common" tags like <div>, <p>, <b>, <em>, <span>, and <pre>? Up for grabs. Make the inline tags blocks, the blocks inline, the pre-formatted tags flow, the stationary ones float. Go crazy, if you like!

It's possible. You may want to spin a yarn about how we should all use "semantic markup" blah blah blah, or believe with the Pythonistas that "There should be one--and preferably only one--obvious way to do it." Yet Tim Toady is a clever and curious guy. Given a free hand, he'll explore them all. That includes using the available flexibility to make substitutions. Some are wise, some will be proven otherwise. But trial, error, and experience is the only way to find that out. So the sufficient conditions for substitution are present.

I don't think it's overstepping to say that substitution is also necessary. At minimum, it's extremely convenient. For a long time, HTML didn't have <menu>, <section>, or <aside> elements. Yet web pages and apps everywhere have menus, sections, and sidebars. How? Because HTML list elements (<ul>, <ol>, and <li>) were easily repurposed and some usages re-classified as menu containers and parts. <div> could stand in for <article>, <section>, <aside>, <figure>, and <summary>. HTML5 has caught up with, and added bespoke elements for, some previously-unaddressed use cases. It's a great update and correction to accommodate common, real-world use.

Even so, there remain a lot of common idioms that don't have bespoke tags or semantic models. Things like pages, footnotes, pull-quotes, comment streams, associated avatars, "likes," subheads, and subtitles that I and many others use every day. What are we to do? What we can. Repurpose "close but inexact" elements with classes and ids to stand in and support our work for the next five or ten or however many years until HTML6 or HTML7 catches up. HTML/CSS's "yes, it's an X, in theory, but we're going to tag it and work with it as a Y" ability is incredibly convenient. Indispensable, really. It makes Web content flex, and not be brittle.

Going even further, "semantic markup" has irreducible limitations. That's true of any kind of rigorous structure you can imagine for content.

Standard formats cannot encompass the entire wealth of human need, desire, and variety. They will always will be "behind the curve" of what people are doing now. How they are innovating. Heck, HTML5 is still behind the curve on footnotes, subheads, and other printing innovations of the 17th century. It lacks features essential to many information workers and content creators. So we improvise.

Even more unchanging is that information doesn't abide by one set of rules. Sure, it starts as a table. But maybe you just want the summary--say the title for each row, as a list. Maybe it takes up too much space, and you'd like it as a space-saving inline list. Maybe you have records you just want the title of, then if you click, you see the underlying details. Or you want items in a complex list or table to be grouped and categorized. Oh, now you want it transposed and categorized a different way. Or the values plotted as a bar chart. These are things done every day in apps, spreadsheets, and data visualization. They are part and parcel of our information landscape, and what we want and need to do on the web. Humans constantly reorganize the form and presentation of our data. It isn't just one thing, or one format/layout, or one concept. It's fungible, with semantics depending on the circumstance and on choices users make interactively. Yes, mark text as "emphasized" (<em>), but that's just a convention. I've worked on documents with at least a half-dozen different kinds of "emphasis." We need to be able to customize and remap that for different uses, different interpretations. One kind of HTML emphasis? Excruciatingly reductionistic. Limiting. Brittle. The same is true for <table>, <p>, etc.

It's great to have tags/elements that help organize the entire community's thinking about "what goes where." That helps establish conventions and idioms, and makes us collectively more efficient. But the ability to remap things, to redesignate and repurpose those structures? That's part and parcel of the Web's inclusiveness and its success.

  • 4
    how does this go anywhere close to answering the question? – HorusKol Mar 31 '15 at 22:51
  • 2
    IMO, it discusses the underlying question of why designers, developers, and content workers choose to use generic elements (<div> and <span>) in place of specific, purpose-built elements (e.g. <table>). It's a little more meta than just those tags, but it speaks directly to the patterns and principles of use. – Jonathan Eunice Mar 31 '15 at 23:07
  • @HorusKol In fact, of the all the answers here, this one is most consistent with, and supportive of, your answer. I would say they mesh well. – Jonathan Eunice Mar 31 '15 at 23:20
  • 1
    I don't know if I would go so far as to contrast div (as generic) with table (as purpose-built). They are both purpose-built, for two different (yet perhaps partially overlapping) purposes. This, I believe, is the heart of the question. – Eric King Mar 31 '15 at 23:37
  • @EricKing It's fair to say that div has a purpose. But div and span don't have the very specific intended purpose that table, thead, td etc do. No one will freak out if you use misc div elements for sidebars, pull quotes, section groupings, etc.--pretty much anywhere in the document, too. Try doing that with a unenclosed thead, td, or li. Instead of "purpose-built," maybe "purpose-specific" or "with a specific intended role." – Jonathan Eunice Mar 31 '15 at 23:51
0

Use cases matter. There is a big difference between layout/presentation in a content page and in an application. In content, semantics matter a great deal for SEO-awareness and usability. In these cases, using tables to present tabular data is in general the right thing to do. As others have noted, search engines will penalize you and you may even run afoul of usability laws if you are required by statute to conform to govt usability guidelines.

In a web application, developers may opt to create entirely separate views for SEO and usability purposes. Responsive design has led people to build views that can handle desktop and mobile layouts, and divs are better than tables in those use cases.

Take ecommerce sites, for example. Viewing a list of products in a browse or search result shows, in general, a list of products in tabular format, but those views may well be generated using divs (which provide more generic and flexible layout and styling options) rather than tables. Amazon and eBay are good examples of this approach. Inspect a search result on either site and you will see a deeply nested set of divs.

protected by gnat Apr 1 '15 at 7:29

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.