Is a DIV inside a TD a bad idea?

HtmlHtml TableSemantic MarkupWeb Standards

Html Problem Overview


It seems like I heard/read somewhere that a <div> inside of a <td> was a no-no. Not that it won't work, just something about them not being really compatible based on their display type. Can't find any evidence to back up my hunch, so I may be totally wrong.

Html Solutions


Solution 1 - Html

Using a div instide a td is not worse than any other way of using tables for layout. (Some people never use tables for layout though, and I happen to be one of them.)

If you use a div in a td you will however get in a situation where it might be hard to predict how the elements will be sized. The default for a div is to determine its width from its parent, and the default for a table cell is to determine its size depending on the size of its content.

The rules for how a div should be sized is well defined in the standards, but the rules for how a td should be sized is not as well defined, so different browsers use slightly different algorithms.

Solution 2 - Html

After checking the XHTML DTD I discovered that a <TD>-element is allowed to contain block elements like headings, lists and also <DIV>-elements. Thus, using a <DIV>-element inside a <TD>-element does not violate the XHTML standard. I'm pretty sure that other modern variations of HTML have an equivalent content model for the <TD>-element.

Here are the relevant DTD rules:

<!ELEMENT td %Flow;>
<!-- %Flow; mixes block and inline and is used for list items etc. -->
<!ENTITY %Flow "(#PCDATA | %block; | form | %inline; | %misc;>
<!ENTITY %block "p | %heading; | div | %lists; | %blocktext; | fieldset | table">

Solution 3 - Html

No. Not necessarily.

If you need to place a DIV within a TD, be sure you're using the TD properly. If you don't care about tabular-data, and semantics, then you ultimately won't care about DIVs in TDs. I don't think there's a problem though - if you have to do it, you're fine.

According to the HTML Specification

A <div> can be placed where flow content is expected1, which is the <td> content model2.

Solution 4 - Html

A table-cell can legitimately contain block-level elements so it's not, inherently, a faux-pas. Browser implentation, of course, leaves this a speculative-theoretical position. It may cause layout problems and bugs.

Though as tables were used for layout -and sometimes still are- I imagine that most browsers will render the content properly. Even IE.

Solution 5 - Html

If you want to use position: absolute; on the div with position: relative; on the td you will run into issues. FF, safari, and chrome (mac, not PC though) will not position the div relative to the td (like you would expect) this is also true for divs with display: table-whatever; so if you want to do that you need two divs, one for the container width: 100%; height: 100%; and no border so it fills the td without any visual impact. and then the absolute one.

other than that why not just split the cell?

Solution 6 - Html

I have faced the problem by placing a <div> inside <td>.

I was unable to identify the div using document.getElementById() if i place that inside td. But outside, it was working fine.

Solution 7 - Html

As everyone mentioned, it might not be a good idea for layout purposes. I arrived to this question because I was wondering the same and I only wanted to know if it would be valid code.

Since it's valid, you can use it for other purposes. For example, what I'm going to use it for is to put some fancy "CSSed" divs inside table rows and then use a quick jQuery function to allow the user to sort the information by price, name, etc. This way, the only layout table will give me is the "vertical order", but I'll control width, height, background, etc of the divs by CSS.

Solution 8 - Html

Two ways of dealing with it

  1. put div inside tbody tag
  2. put div inside tr tag

Both approaches are valid, if you see feference: https://stackoverflow.com/a/23440419/2305243

Solution 9 - Html

It breaks semantics, that's all. It works fine, but there may be screen readers or something down the road that won't enjoy processing your HTML if you "break semantics".

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionjcollumView Question on Stackoverflow
Solution 1 - HtmlGuffaView Answer on Stackoverflow
Solution 2 - HtmlMartin LiversageView Answer on Stackoverflow
Solution 3 - HtmlSampsonView Answer on Stackoverflow
Solution 4 - HtmlDavid ThomasView Answer on Stackoverflow
Solution 5 - HtmlzeelView Answer on Stackoverflow
Solution 6 - HtmlHimajaView Answer on Stackoverflow
Solution 7 - HtmlJuan IgnacioView Answer on Stackoverflow
Solution 8 - HtmlAlan DongView Answer on Stackoverflow
Solution 9 - HtmlGregView Answer on Stackoverflow