Why are people making tables with divs?

  • 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>

    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.

    Comments are not for extended discussion; this conversation has been moved to chat.

    Back in the day (**cough** Int... **cough** Expl... **cough**), tables were *ridiculously* slow to render vs. pure CSS tables. You would literally wait for many seconds to see anything at all on-screen with actual `` being used. With CSS, there was no such problem.

    @JuhaUntinen: that... sounds unlikely. Source?

    @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.

    @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.

    @Vilx-: what answers in particular are you talking about? I can’t see one that mentions a difference in layout performance in IE between using actual tables, and `display:table`. (Regarding the entire table needing to be loaded before it can be displayed, I don’t see how IE would be slower than any other browser at doing that.)

    This question makes me sad to think about all of the human productivity that has been wasted on this issue in the past 15-20 years.

    Back in the even older days we used to mimic divs with tables so there.

    @WyattBarnett: and also the glorious `frame` :) those were some innocent days...

    There are a couple other reasons you should avoid tables for non-table content: (1) your HTML should have the highest semantic value possible and (2) tables add a lot of extra markup for cases where the data can be formatted sufficiently without a table.

    @Sildoreth - the extra markup is minimal and IMHO actually clarifies what is going on. As for the highest semantic value - why?

    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.

    "Back in the day" is especially not true when talking about the tables. Netscape 7.0 is still the fastest table renderer, period. Netscape will render a large table in a split second, while the current FF, Opera or IE will be hung for a long time. I call this phenomenon "software obesity epidemic".

    @ajeh - But how **correctly** will it do it? It's not hard to render a table fast if you start ignoring some of the constraints the developer placed on it.

    @Vilx- Can you test and see?

    @ajeh - Maybe, but I'm a bit lazy to check such an antiquated browser. :) Also, I'm not even sure what standards I should try and hold it to. If you're comparing to the contemporary FF/IE/Chrome, then it's obviously not going to support a LOT of the features that these browsers have, so it wouldn't be a fair comparison. In fact, I'm not even sure it's possible to fairly compare them. Even though the test might not include the newer features, the modern browsers will have code to support them and that might slow them down. Yet it's good that they have these features, even with the slowdown.

    You are totally missing the point. Netscape 7 is ways faster than modern FF on the same bare table with many rows. Keeping in mind that modern FF uses hardware acceleration that Netscape is not even aware of.

    @ajeh - You're missing the point too. Sure, it's faster, I've no doubt about that. But it's because it's a lot simpler and doesn't support all the same stuff that FF does.

    @ajeh - Wait, what are we debating about again? :D

    Surprised to see that no one answered with a simple: It could be tabular data but it's quite hard if not impossible to fix the table header and make the rows scrollable, whereas ith divs this is not so difficult.

  • 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.

    Yes, responsiveness is one reason.

    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.

    This is ridiculous and lazy. Anything you're doing with `

    ` “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.

    @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.

    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.

    I believe this answer is slightly misleading. Responsive tables is good design, but it is independent of the question if you should use or

    - 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.
  • 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.

    OK, but **why** not use a `` for layout? It has properties that nothing else has. If you're trying to make a good responsive/fluid layout, a `

    ` (or `display: table`) is often your only choice. So why must you jump through hoops and use `display:table` when a simple `
    ` will do and be much more legible on top of it?

    @Vilx- why use `` and `` rather than `` and ``? Because `` and `` are not about the semantics of the tag. `` has *semantic* meaning. Using it for something that *isn't* a table makes it harder to understand the semantic meaning of the document.

    @MichaelT - another thing I've never understood. I just use `` and ``. But nobody cares about that. As for semantics - the only case that I'm aware of where semantics matter are search engine spiders. However things like ``, `` and `` are quite unlikely to confuse those.

    @Vilx- `The book Peoplesoft is the best book on the subject.` Putting `` around best would be wrong because that means something different than the `` around the book title. For more, see Why are the `` and `` tags deprecated? and What's the difference between `` and ``, `` and ``?

    @MichaelT - I still don't get it. Why would I care what my content _means_? I care only about 2 things: the experience of my users (which includes visual, aural and search engine experience), and the experience of my fellow developers. Now, granted, I've never made a website which was usable by screen readers, so I don't know if using tables over divs has any negative difference there (and if it can be overcome by the proper aria roles or something). However I'm pretty sure that using divs over tables has neutral to negative consequences on all other points.

    @MichaelT - It's an especially evil thing do to your fellow developers who now need to do the mental math and bookkeeping to keep track of which element is a row, which is a cell, and where "invisible" elements are automatically inserted as per CSS rules. At least a `` lets you spell it all out.

    @Vilx- of course, that means you've never done `

    ` and other joys of nested tables for formatting. Because the mental math of which table you are in isn't hard either. That said, I really try to avoid using all of that and would much rather use something like bootstrap.

    @MichaelT - Yes, I have, but (a) - such cases are pretty rare (remember - I'm not advocating using tables for EVERYTHING. I'm arguing against `display: table`); and (b) - it would look just as bad if you replaced all the table/tr/td with div.

    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.

    @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.

    @user10042 - More or less true, yes. I use elements according to their functionality, not their semantics. Mind you, "produces a certain effect for screen readers" or "gives a certain hint to search engines" is also a piece of functionality in my book, rather than some abstract "semantics". However we digress. The question was about the specific `` vs `display:table` and not semantics in general.

    @rooby - So, does using a `` for layout present some aural drawbacks compared to using a bunch of `

    ` which give the same visual effect? Assume that all the aria stuff has been applied properly.

    Those "abstract semantics" are exactly what helps search engines, screen readers, and even graphical browsers...

    Well a screen reader reads a table as tabular data so it doesn't make sense when the table is not full of tabular data. I would assume that a large proportion of screen reader users would be able to still understand what's on the page but why make it harder for them if you don't have to. Also, a lot of businesses and government agencies now have specific accessibility requirements so if you're making a site for someone else you might be forced to make it WCAG2 AA compliant or something.

    @Vilx-, yes, a screen reader does treat a very differently from a

    s are mostly ignored and read sequentially. Inside a
    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...*")

    @rooby: Is there any nice way to format a side-by-side translation in a manner that will permit either side to be read or copied in top-down order, but will can also add blank space on either side as needed to keep a correspondence between things on the left and right side that word-wrap differently?

    @supercat: Possibly but I don't have the details of the top of my head. It is really outside the scope of this question. However it seems like you might be able to legitimately use a table for that kind of thing depending on your specific requirements.

    What I see, frequently, is people not using tables even for tabular data. I don't understand it.

  • 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>

    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 class="thumbnail">
          <img src="" />
          <p>Some text</p>
        <div class="thumbnail">
          <img src="" />
          <p>Some text</p>
        <div class="thumbnail">
          <img src="" />
          <p>Some text</p>

    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 > 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 `

    ` instead of ``? What benefits does it offer?

    Have updated my answer

    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 `` then or still `display:table`? Because, well, in a way it _is_ tabular data. Except that the "data" is pictures, but still.

    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?

    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.

    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. :)

    Tables used for layout can be decorated with the attribute role="presentation" to inform semantic interpreters that they are not data tables.

  • 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 `` and which is why it happens to work even in old browsers like IE6. Have I missed something?

    @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.

    @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.

    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: 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.

    @Vilx: It's trivial for you to test various doctypes. Rather than depend on us, just put together a few examples and see how they are rendered in various browsers. It's priceless education.

    @NotMe - True, but the differences will probably be noticeable only in some esoteric edge cases. I don't even know what to look for.

    @Vilx: no. The differences will be noticeable with a couple simple divs that have borders, padding, margins and a bit of text within them. The primary thing is how the box model works. The majority of the time people try to compensate for lousy doctype selection by using css reset sheets that attempt to set margins and padding to zero.

  • 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.

    wrt to the last paragraph - you have read the HTML5 specification for those elements, haven't you? http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-p-element http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element http://www.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

    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

    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 ...

    ... "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.

    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.

    @DavidW Exacty. And I'd add: the design of HTML, CSS, and JavaScript came about through a series of fits and starts and divergent goals and changes of mind. Just look at the number of deprecated tag attributes in HTML 5! If the thing had been cleanly designed from the beginning, maybe some of these issues would just never have come up. As is, we have to work with what we have. (PS I don't say this to demean the people who invented these tools. There had to be some real geniuses in there. That's just how life is. Nobody knew where it was going when is started.)

  • 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.

  • 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.

    how does this go anywhere close to answering the question?

    IMO, it discusses the underlying question of why designers, developers, and content workers choose to use generic elements (`

    ` and ``) in place of specific, purpose-built elements (e.g. ``). It's a little more meta than just those tags, but it speaks directly to the patterns and principles of use.

    @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.

    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.

    @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."

  • 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.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM