¿Es un DIV dentro de un TD una mala idea?

Parece que escuché / leí en alguna parte que el <div>interior de un <td>era un no-no. No es que no funcione, solo algo acerca de que no son realmente compatibles según su tipo de pantalla. No puedo encontrar ninguna evidencia que respalde mi presentimiento, por lo que puedo estar totalmente equivocado.

Usar un divinstide a tdno es peor que cualquier otra forma de usar tablas para el diseño. (Sin embargo, algunas personas nunca usan tablas para el diseño, y resulta que soy una de ellas).

Sin embargo, si usa un diven un td, se encontrará en una situación en la que podría ser difícil predecir cómo se dimensionarán los elementos. El valor predeterminado para un div es determinar su ancho a partir de su elemento primario, y el valor predeterminado para una celda de tabla es determinar su tamaño dependiendo del tamaño de su contenido.

Las reglas sobre cómo se divdebería dimensionar un a están bien definidas en los estándares, pero las reglas sobre cómo se tddebería dimensionar un a no están tan bien definidas, por lo que diferentes navegadores utilizan algoritmos ligeramente diferentes.

Después de comprobar XHTML DTD descubrí que un elemento <TD> puede contener elementos de bloque como encabezados, listas y también elementos <DIV>. Por lo tanto, el uso de un elemento <DIV> dentro de un elemento <TD> no viola el estándar XHTML. Estoy bastante seguro de que otras variaciones modernas de HTML tienen un modelo de contenido equivalente para el elemento <TD>.

Estas son las reglas relevantes de DTD:

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

No. No necesariamente.

Si necesita colocar un DIV dentro de un TD, asegúrese de estar usando el TD correctamente. Si no le interesan los datos tabulares y la semántica, en última instancia, no le interesarán los DIV en TD. Sin embargo, no creo que haya un problema: si tiene que hacerlo, está bien.

De acuerdo con la especificación HTML

Se <div>puede colocar A donde se espera el contenido de flujo ¹ , que es el <td>modelo de contenido ² .

Una celda de tabla puede contener legítimamente elementos de nivel de bloque, por lo que no es, inherentemente, un paso en falso. La implementación del navegador, por supuesto, deja esto en una posición especulativa-teórica. Puede causar problemas de diseño y errores.

Aunque como las tablas se usaron para el diseño, y a veces todavía lo son, imagino que la mayoría de los navegadores mostrarán el contenido correctamente. Incluso IE.

Si quieres usar position: absolute; en el div con position: relative;el td te encontrarás con problemas. FF, safari y chrome (mac, no PC) no posicionarán el div en relación con el td (como era de esperar), esto también es cierto para los divs, por display: table-whatever;lo que si desea hacerlo necesita dos divs, uno para el contenedor width: 100%; height: 100%;y sin borde, por lo que llena el td sin ningún impacto visual. y luego el absoluto.

aparte de eso, ¿por qué no simplemente dividir la celda?

Me he enfrentado al problema colocando un <div>interior <td>.

No pude identificar el div usando document.getElementById()si lo coloco dentro de td. Pero afuera, estaba funcionando bien.

Como todos mencionaron, podría no ser una buena idea para propósitos de diseño. Llegué a esta pregunta porque me preguntaba lo mismo y solo quería saber si sería un código válido.

Como es válido, puede usarlo para otros fines. Por ejemplo, para lo que lo voy a usar es para poner algunos divs "CSSed" sofisticados dentro de las filas de la tabla y luego usar una función jQuery rápida para permitir al usuario ordenar la información por precio, nombre, etc. De esta manera, el la única tabla de diseño que me dará es el "orden vertical", pero controlaré el ancho, la altura, el fondo, etc. de los divs por CSS.

Dos formas de lidiar con eso

1. poner divdentro de la tbodyetiqueta
2. poner divdentro de la tretiqueta

Ambos enfoques son válidos, si ve feferencia: https://stackoverflow.com/a/23440419/2305243

Rompe la semántica , eso es todo. Funciona bien, pero puede haber lectores de pantalla o algo en el futuro que no disfrutará de procesar su HTML si "rompe la semántica".