¿Funcionamiento incorrecto de border-collapse en Mozilla Firefox?

[Negora]

Hola compañeros/as:

Desde hace mucho tiempo he padecido un problema con los navegadores que emplean el motor Gecko (familia Mozilla) y las tablas que hacen uso del atributo CSS "border-collapse" cuando se establece a "collapse".

Si diseñamos una tabla como ésta:

Código:

     <table>
          <tr>
               <td>xxx</td>
               <td>xxx</td>
               <td>xxx</td>
          </tr>
     </table>

Y aplicamos unos estilos como los siguientes:

Código:

     body { margin: 0px; }
     table { border-collapse: collapse; border-spacing: 0px; }
     td { border: solid 4px #ff0000; width: 100px; }

Observamos que mientras que en Opera, Safari e Internet Explorer la esquina superior izquierda de la tabla se ajusta a la esquina del cuerpo del documento, en Firefox y familia éste toma como esquina de la tabla justamente la mitad del borde.

Antes de informar en Bugzilla (ya que hay muchísimos temas abiertos sobre fallos por causa del atributo "border-collapse"), quería preguntaros vuestra opinión: ¿Os parece este comportamiento el correcto, o bien es el que realizan los otros?

Lo digo porque he oído voces que basándose en lo que literalmente dice el estándar de la W3C, alegan que lo que hace Firefox podría ser correcto. La verdad es que por mucho que los bordes se "fundan" debido al atributo "collapse", creo yo que los externos deberían de comportarse de forma sólida, como lo hacen en Opera y los otros.

Sea como sea, se me ocurrió que para conseguir el mismo efecto sin usar "collapse" bien se puede hacer algo como esto:

Código:

     body { margin: 0px; }
     table { border-spacing: 0px; border: solid 4px #ff0000; }
     table tr + tr td { border-top: solid 4px #ff0000; }
     table td + td { border-left: solid 4px #ff0000; }
     td { width: 100px; }

Con algo así se evitan los dobles bordes y el aspecto es idéntico al que se conseguiría con "collapse" en otros navegadores. Un saludo y gracias.

[Mikmoro]

A mi me parece que el comportamiento es correcto, y me explico:

por un lado, estamos haciendo que colapse el borde de la tabla, con lo que la tabla ya está posicionada en su sitio (límites superior e izquierdo), y por otro, como queremos que el borde aparezca en todas las celdas, les aplicamos el borde a éstas y no a la tabla, por lo que, al tener ya la tabla posicionada al borde superior e izquerdo esta no se puede ver desplazada por el borde de su contenido, que es lo que se necesitaría que ocurriera para que el borde de las celdas quedara perfectamente alineado con el borde de la caja, y me parece un comportamiento normal, de hecho el deseado.

Un ejemplo sería este: ¿qué pasaría si en lugar de como estaba, usamos este código?

body { margin: 0px; }
td {border-collapse: collapse;border: solid 4px #ff0000; width: 100px;}

<table cellspacing="0">
<tr>
<td>xxx</td>
<td>xxx</td>
<td>xxx</td>
</tr>
</table>

que los bordes de las celdas se alinean perfectamente con el borde de la caja en su interior. ¿Por qué?, porque ahora la tabla queda liberada del colapso, y son en realidad los bordes de las celdas los que colapsan y nos permiten aplicar un borde a nuestro gusto, por lo que ya se comportan de forma natural, desplazándose lo necesario sobre su posición para dar cabida a su propio borde.

Como digo me parece el comportamiento adecuado, porque en realidad si yo quisiera hacer esto y viera que una vez fijada la tabla ésta se viera desplazada de su posición por lo que le ocurra a su contenido, me quejaría de que yo quiero que se quede quieta y que no le afecte lo que haga con los bordes de sus celdas.

En realidad a mi entender la tabla es una cosa, y su contenido (las celdas) otra, de manera que prefiero que la tabla no se desplace por actuar sobre sus celdas.

Si al ejemplo anterior le añadimos a la tabla un border="6", veremos que ahora sí la tabla se ve desplazada hacia abajo y la derecha para dejar sitio a su propio borde, pero sólo se desplaza cuando se actua sobre ella, no sobre su conenido.

Esa es mi opinión.

Una vez rescatado el mensaje, EDITO:
efectivamente como pude darme cuenta más tarde, mi ejemplo contiene un error y por tanto el comportamiento del código de ejemplo que pongo no es el mismo al que buscaba Negora, porque en realidad border-collapse no puede ser aplicado a celdas.

[Negora]

Mikmoro: Antes de nada, déjame que te agradezca que hayas respondido a mi mensaje con tanta rapidez ;) .

La verdad es que los comentarios a favor de la implementación de Firefox que yo había oído iban en un sentido distinto al tuyo, así que me ha parecido interesante leer lo que has comentado, ya que es un planteamiento alternativo. Sin embargo creo que difiere del ejemplo expuesto y que su resultado no es el mismo, ¿No?

Según estándar de la W3C, el atributo border-collapse sólo corresponde a elementos con visualización "table" o "inline-table", por lo que en cualquier otro elemento (como la celda que indicas), no se vería afectado por esta propiedad.

De hecho, si te fijas bien, en el ejemplo que expones las celdas presentan doble borde en su parte interna, cuando realmente debería fusionarlos o colapsarlos. Aunque "border-collapse" se especifique en la tabla, realmente su efecto se ha de propagar a ésta misma y a todas las celdas que directamente sean descendientes de ella. Pese a que luego el borde sea una propiedad independiente en la tabla y en las celdas.

Mejor verlo con un ejemplo:



El primer gráfico corresponde a mi primer intento. En Firefox la tabla queda alineada con respecto a la mitad de su borde (no ocurre en otros navegadores). Si te fijas, las celdas se dibujan como se desea, con sus bordes fundidos. Es como si la tabla fuera "comida" por el elemento contenedor.

El segundo gráfico es el plan alternativo que indiqué antes. Esto es lo que se obtiene en otros navegadores con el primer ejemplo y lo que, a priori, debería de verse en Firefox. Todos los bordes son exactamente homogéneos.

El tercero corresponde al tuyo. En efecto, la tabla se alinea correctamente, pero es porque las celdas jamás llegan a fundirse y provocan doble borde.

Por eso, para explicar el comportamiento de Firefox y si es correcto o no, "border-collapse: collapse" debería de ir especificado en la propia tabla. Ya que de otro modo no se está procediendo a fundir los bordes, y sería como asignarle el valor "separate".

Muchas gracias ;) .

[Mikmoro]

Ya me puedes perdonar, porque efectivamente la respuesa la escribí ayer noche tarde, y esta mañana la he releido y la he borrado antes de que tú me contestaras, o mejor dicho mientras tú escribías. Efectivamente el comportamiento no es el mismo, por eso aunque el fundamento de mi respuesta para mi era correcto, realmente no funciona igual.

Siento que ahora sin mi respuesta sea más difícil entender el sentido de tu segundo mensaje.

[Negora]

Mikmoro: Anda, anda, no te tienes que disculpar por nada, si precisamente esto es para que intercambiemos ideas ;) . Cualquier cosa que se te ocurra al respecto, no dudes en ponerla. Y gracias.

[Jamati]

Me anoto para saber como se soluciona esto, ya que en otro post pregunté como se trabaja con el collapse.

[Mikmoro]

Creo que la razón de la forma de actuar de Firefox con respecto al border-collapse (bordes cerrados), la encontramos en la propia especificación de CSS 2 de la W3C:

"Los bordes son centrados con las líneas de la grilla entre las celdas."

Como decía ayer (en el mensaje que eliminé por contener errores), una vez has colocado una tabla ajustada a los límites interiores superior e izquierdo de una caja, la posiciópn de ésta no debería verse afectada por la forma en que actuemos sobre su contenido (las celdas).

En el caso que nos ocupa:

body { margin: 0px; }
table { border-collapse: collapse; border-spacing: 0px; }
td { border: solid 4px #ff0000; width: 100px; }

dado que la tabla es quien debe usar los bordes como cerrados (collapse), ajusta la grilla a los límites de su contenedora como he dicho, y después es a su contenido, sus celdas, a quienes aplicamos un nuevo borde.

Pues bien, según la especificación, el borde debe ser centrado con respecto a la grilla (misma cantidad a cada lado de ésta), de manera que si la grilla está ajustada a los límites, la tabla no debe verse deplazada por cómo actuemos sobre su contenido, y los bordes deben centrarse con respecto a la grilla, es perfectamente lógico que al poner un borde de cierto grosor, éste desborde los límites de la caja que lo contiene.



En mi opinión, la forma de actuar de firefox es correcta.

[webosiris]

Iniciado por Mikmoro

Siento que ahora sin mi respuesta sea más difícil entender el sentido de tu segundo mensaje.

ya restauré tu mensaje Mik

[Mikmoro]

Gracias, ahora tiene más sentido

[Negora]

Pero ese extracto del estándar no explica por qué la alineación con respecto a una caja contenedora superior se realiza a partir de la rejilla y no de los bordes. Lo marcado en negrita únicamente explica que un borde ha de estar centrado con respecto a la rejilla. Solamente eso. A partir de ahí establece la forma para calcular el ancho de la tabla, con respecto a rellenos, márgenes y bordes.

De hecho, la norma comenta después "User agents must find a consistent rule for rounding off in the case of an odd number of discrete units (screen pixels, printer dots).". Eso básicamente implica que si un borde tiene 5 píxeles, el propio navegador ha de indicar cómo se reparte: ¿3 píxeles a la derecha y 2 a la izquierda? ¿O 2 a la izquierda y 3 a la derecha?

"una vez has colocado una tabla ajustada a los límites interiores superior e izquierdo de una caja, la posición de ésta no debería de verse afectada por la forma en que actuemos sobre su contenido (las celdas)."

Pienso que eso quitaría la razón al modo de renderizar de Firefox. Si una vez colocada la tabla ésta no debe de verse afectada por el contenido, aplicándole un borde de 2 píxeles, estos deberían de verse al completo. Y no es así. Se lo apliques a la tabla o a las celdas, éste se ve recortado.

PD: Tras releer mi mensaje parece que lo digo de "mala manera". Espero que no se me entienda mal ;) .

[Mikmoro]

Iniciado por Negora

Pero ese extracto del estándar no explica por qué la alineación con respecto a una caja contenedora superior se realiza a partir de la rejilla y no de los bordes.

para mi este aspecto está claro: porque no es la tabla quien tiene bordes, sino la celdas, de manera que la tabla no se podría ajustar a su contenedora a partir de sus bordes, proque no los tiene, así que sólo le queda una alternativa; ajustarse apartir de la grilla (o rejilla).

Iniciado por Negora

"una vez has colocado una tabla ajustada a los límites interiores superior e izquierdo de una caja, la posición de ésta no debería de verse afectada por la forma en que actuemos sobre su contenido (las celdas)."
Pienso que eso quitaría la razón al modo de renderizar de Firefox. Si una vez colocada la tabla ésta no debe de verse afectada por el contenido, aplicándole un borde de 2 píxeles, estos deberían de verse al completo. Y no es así. Se lo apliques a la tabla o a las celdas, éste se ve recortado.

¿Pero aplicándole un borde a quién? Ese es el punto de inflexión.
Creo que aquí es donde no estamos de acuerdo. A mi entender no deberían verse porque esto implicaría mover la tabla a causa de los bordes de su contenido, que debería verse desplazada hacia abajo y la derecha para que se vieran. Como comenté, si a la tabla le aplicas un borde, efectivamente se ve que es la tabla la que está ajustada a los límites, y por tanto, como los bordes son propios se verán, ya que la tabla no se ve desplazada, sino que sus bordes son parte de ella misma. No así en el caso que nos ocupa, en el que ella no tiene bordes, sino los tiene su contenido (sus celdas).
Digo que este es el punto de inflexión porque dices "aplicándole un borde de 2 píxeles", pero obvias que la tabla no tiene borde, sino sus celdas, que es el argumento que esgrimo desde el inicio.

Iniciado por Negora

PD: Tras releer mi mensaje parece que lo digo de "mala manera". Espero que no se me entienda mal ;) .

No, en absoluto, al menos por mi parte.

[Negora]

Mikmoro: Antes de nada, insisto sobre la frase del estándar que comentabas:

"Borders are centered on the grid lines between the cells."

Esto no especifica que el alineamiento con respecto al elemento contenedor haya de hacerse en base a la rejilla. Solamente dice que si un borde compuesto o fundido tiene 4 píxeles por ejemplo, éste se ha de centrar con respecto a dicha rejilla. El diagrama que indicas de hecho se refiere a eso mismo y tampoco daría respuesta a este caso.

En cuanto al hecho de que una tabla no haya de verse desplazada por el contenido y/o borde de las celdas (como dices, la causa de nuestra divergencia de opiniones), sigo sin coincidir por varias razones...

La primera se refiere al propio concepto de borde en CSS. A diferencia de un contorno (outline), éste siempre ocupa un lugar. Y si el elemento tiene disposición estática, ha de provocar un empuje a los elementos adyacentes. Como en este caso el centro del borde de la celda está ligado a la rejilla, y ésta a su vez es quien da forma a la tabla, dicha celda no puede separarse de la tabla con un empuje (lo que sí sucede con "border-collapse: separate"), por lo que el empuje debería de aplicarse a la tabla en sí. Se podría decir que el borde de la celda "rebosa" de la tabla.

Pero busquemos un fundamento físico basado en lo que dice el estándar. Si lo que hace Firefox es correcto y el elemento que contiene la tabla no usa ninguna propiedad de ocultación (overflow), ¿Por qué esa mitad externa del borde no ocupa espacio? Eso contradice por completo el concepto de borde en CSS.

Y si colocamos una tabla idéntica inmediatamente después de la otra, una vez más se contraviene el estándar, pues la mitad de sus bordes se solapan y esto jamás debería de ser así. Tendría que existir empuje, por mucho que el borde no sea de la tabla sino de las celdas. ¿O no sucede así siempre en cualquier caso?

La otra razón viene dada al poner a prueba el renderizado cuando es la tabla la que disfruta de borde:

Código:

body { margin: 0px; }
table { border-collapse: collapse; border-spacing: 0px; border: solid 4px #ff0000; }
td { width: 100px; }

En este caso la tabla tiene borde, le pertenece, pero la manifestación gráfica es idéntica, ignorando por completo el espacio que la mitad externa del borde debería de estar ocupando.

[Mikmoro]

Bueno, esto tiene difícil resolución, y acabará en una cuestión de opiniones.

Efectivamente el borde siempre ocupa espacio físico, y en cualquier otro caso el borde pasa a formar parte de la caja convirtiéndose en su propio límite (tal como explica el modelo de caja), pero en el caso concreto de la tabla con border-collapse, como se especifica que el borde deberá asignarse centrado a ambos lados de la rejilla, a mi me parece natural que una mitad desborde de su contenedora, ya que en el caso de una caja ella no se ve desplazada sino, si es caso, la parte visible "no bordeada" de ésta, o su parte disponible para contenido, pero no la propia caja.

Y esto en base a lo mismo de antes: nada indica expresamente que debe ser obligatoriamente la rejilla la que se ajuste a los límites de la contenedora, pero, de no ser así, ¿qué sentido tendría la especificación de que el borde sea centrado en base a ella? Si no fuera así, no haría falta en absoluto dicha declaración, porque como siempre la rejilla se vería desplazada una cantidad igual a la mitad de su borde en caso necesario, y teniendo en cuenta que la rejilla en sí no sería una unidad "visible" sino ficticia, en realidad no haría falta decir que la rejilla debe quedar centrada con respecto al borde, ya que esto sería imperceptible.

¿Qué finalidad parece perseguir pues la declaración de que el borde deba quedar centrado con respecto a la rejilla? Por un lado, que en el caso de celdas adyacentes ambas entregarán al borde la misma porción de su propio espacio, y por otro, a mi entender, que la unidad física de ajuste de la tabla sigue siendo la rejilla, que es para la que se declara un ancho específico, y que ésta se verá rodeada y no desplazada por el efecto del borde.

Así como hay una clara diferencia de la interpretación del borde entre IE y el resto de navegadores, de la misma manera la declaración collapse parece decir algo como: "medio borde por dentro, y medio por fuera". Pero... ¿medio por dentro y medio por fuera de qué?: de la rejilla, que es el límite físico real de la tabla, sin el cuál el "medio dentro-medio fuera" carecería de sentido, porque se convertiría en "todo por fuera"

A mi juicio, en caso de que el comportamiento de una tabla bajo esas condiciones hubiera de ser idéntico al de cualquier otro objeto, sobraría la precisión del centrado de la que estamos hablando.

Pero además, aprovechando la diferencia de interpretación de los bordes entre navegadores, creo que estamos obviando algo fundamental: ¿Qué ocurriría si tenemos una contenedora de 500px de ancho y dentro introducimos una tabla como la que tratamos, con 500px de ancho también y un borde de 10px en sus celdas? Pues que en el caso del dibujado de otros navegadores no cumplen con la norma de la especificiación, porque el contenido de la tabla en realidad mediría 480px, y 490px la rejilla, luego el centrado del borde con respecto a la rejilla carece de sentido ya que ésta se ha visto reducida, mientras que en firefox el contenido de la tabla mediría 490px (500 menos las dos mitades de los bordes), y la rejilla mediría 500px.

No podríamos pues estar de acuerdo con el modelo de caja que indica que el tamaño final de una caja será el de su ancho más sus bordes (modelo standard), y sin embargo estar de acuerdo también con que en el caso específico de esa tabla el modelo responda a la interpretación del modelo de caja de Internet Explorer, es decir, que el ancho total de la caja sea el declarado incuyendo sus bordes.

De manera que estoy de acuerdo con firefox, que sigue siempre la misma política en el modelo de caja: el ancho final es igual al ancho declarado más sus bordes, y en el caso de la tabla con border collapse, es igual al ancho declarado más dos medios bordes por ser estos centrados con respecto a la rejilla, que es la que, al igual que las cajas, siempre conserva su tamaño real declarado inicialmente.

[Negora]

Efectivamente el borde siempre ocupa espacio físico, y en cualquier otro caso el borde pasa a formar parte de la caja convirtiéndose en su propio límite (tal como explica el modelo de caja), pero en el caso concreto de la tabla con border-collapse, como se especifica que el borde deberá asignarse centrado a ambos lados de la rejilla, a mi me parece natural que una mitad desborde de su contenedora, ya que en el caso de una caja ella no se ve desplazada sino, si es caso, la parte visible "no bordeada" de ésta, o su parte disponible para contenido, pero no la propia caja.

Pero es que yo no he dicho que vea extraño que el borde rebase la rejilla. Eso en una tabla de bordes fusionados sería imposible de evitar según la especificación CSS. Lo que no es lógico es que la mitad del borde se comporte como algo etéreo y sin "masa" dentro del documento. Eso por definición no sería un borde. Y es lo que hace Firefox.

Y esto en base a lo mismo de antes: nada indica expresamente que debe ser obligatoriamente la rejilla la que se ajuste a los límites de la contenedora, pero, de no ser así, ¿qué sentido tendría la especificación de que el borde sea centrado en base a ella? Si no fuera así, no haría falta en absoluto dicha declaración, porque como siempre la rejilla se vería desplazada una cantidad igual a la mitad de su borde en caso necesario, y teniendo en cuenta que la rejilla en sí no sería una unidad "visible" sino ficticia, en realidad no haría falta decir que la rejilla debe quedar centrada con respecto al borde, ya que esto sería imperceptible.

A mi juicio, en caso de que el comportamiento de una tabla bajo esas condiciones hubiera de ser idéntico al de cualquier otro objeto, sobraría la precisión del centrado de la que estamos hablando.

Pero es que esa precisión que establece la W3C es necesaria siempre, porque en una tabla de bordes fusionados puede existir un conflicto de unidades de medida entre 2 entidades (tabla-celda o celda-celda). De ahí que la rejilla se establezca como "meridiano" del borde. ¿Qué sucede si una celda tiene 5px de borde y la otra 1px? Pues ese texto trata de aclarar eso, exclusivamente. ¿En qué parte se indica que la mitad de ese borde haya de ser despreciada para operaciones de alineado? En ninguna, al menos que yo vea. No son conceptos contradictorios.

Pero además, aprovechando la diferencia de interpretación de los bordes entre navegadores, creo que estamos obviando algo fundamental: ¿Qué ocurriría si tenemos una contenedora de 500px de ancho y dentro introducimos una tabla como la que tratamos, con 500px de ancho también y un borde de 10px en sus celdas? Pues que en el caso del dibujado de otros navegadores no cumplen con la norma de la especificiación, porque el contenido de la tabla en realidad mediría 480px, y 490px la rejilla, luego el centrado del borde con respecto a la rejilla carece de sentido ya que ésta se ha visto reducida, mientras que en firefox el contenido de la tabla mediría 490px (500 menos las dos mitades de los bordes), y la rejilla mediría 500px.

No podríamos pues estar de acuerdo con el modelo de caja que indica que el tamaño final de una caja será el de su ancho más sus bordes (modelo standard), y sin embargo estar de acuerdo también con que en el caso específico de esa tabla el modelo responda a la interpretación del modelo de caja de Internet Explorer, es decir, que el ancho total de la caja sea el declarado incuyendo sus bordes.

Pues por extraño que parezca ése es el estándar en HTML y XHTML: Mientras que el resto de elementos tienen una anchura que excluye su borde, en el caso de la tabla su anchura incluye cualquier borde, ya sea de celda o de la tabla propiamente. Así que la rejilla en un caso como éste debería de medir 490 px.

[Mikmoro]

Según la especificación CSS2:

El diagrama de más abajo muestra cómo interactúan el ancho de la tabla, el ancho de los bordes, el relleno y el ancho de la celda. Su relación está dada por la siguiente ecuación, que se mantiene para cada fila de la tabla:

row-width = (0.5 * border-width0) + padding-left1 + width1 + padding-right1 + border-width1 + padding-left2 +...+ padding-rightn + (0.5 * border-widthn)

Aquí n es el número de celdas en la fila y border-widthi se refiere al borde entre las celdas i é i + 1. Observe que sólo la mitad de los dos bordes exteriores se cuentan en el ancho de la tabla; las otras dos mitades de esos dos bordes quedan en el área de los márgenes.

No sé a ti, pero a mi me parece clarísimo.

[Negora]

Mikmoro: En ese último aspecto he comprobado que, como dices, calculé mal, ya que cuando verifiqué el ejemplo "in situ" me fijé en la norma general y no en la aplicada a bordes fusionados. En efecto, en ese caso concreto Firefox sí que renderiza correctamente.

Sin embargo, sigo sin ver algo en ese párrafo que diga que esas mitades de borde que rebosan de la tabla no han de ocupar espacio, y por tanto, provocar el empuje con respecto a un elemento adyacente. Se limita a especificar hasta donde alcanza el ancho de la tabla y nada más. Si estoy equivocado, ¿Qué frase exacta señala concretamente eso?

Igualmente, esa parte del estándar a la que ahora te has referido indica claramente que la tabla sí puede tener bordes, al igual que otros sub-elementos suyos. Y de hecho el ejemplo gráfico adjunto lo usa.

Dicho eso, considero que aquí entra en juego un concepto más general y no específico de las tablas, sino del modelo de cajas de CSS. ¿Hasta dónde alcanza el "dominio" de un elemento y llega a colisionar con otro?

En ese diagrama explica que un elemento se extiende a lo largo de la suma de su anchura/altura, su relleno (padding), su borde (border) y margen (margin). Todo ello junto conforma ese alcance. Y si se trata de elementos estáticos, dicho alcance supone la zona de colisión entre cajas consecutivas.

En el caso específico de una tabla, como indicabas más arriba, su anchura incluye las mitades de los bordes. Pero, ¿Y las mitades que desbordan? ¿Como borde que es, por qué no va a pertenecer ni siquiera a dicho concepto y por lo tanto sumar en ese cómputo? Hasta donde sé, no hay nada en el estándar de tablas que anule su naturaleza como borde o su propia existencia. Siendo así, debería de ser incorrecto que Firefox lo convierta en una especie de perfil (como si usáramos la propiedad "outline"), algo que el resto de navegadores no hace (aunque yerren en el cálculo de la anchura). Si lo excluye como borde, ni siquiera debería de ser dibujado, porque no entraría en ninguna categoría del estándar, ¿O no?

[Mikmoro]

Iniciado por Negora

Sin embargo, sigo sin ver algo en ese párrafo que diga que esas mitades de borde que rebosan de la tabla no han de ocupar espacio, y por tanto, provocar el empuje con respecto a un elemento adyacente. Se limita a especificar hasta donde alcanza el ancho de la tabla y nada más. Si estoy equivocado, ¿Qué frase exacta señala concretamente eso?

Pues a mi entender exactamente aquí:

"las otras dos mitades de esos dos bordes quedan en el área de los márgenes."

Yo interpreto que quedan en el área de los márgenes, es decir, fuera del área propia de la caja anónima que crea una tabla en la que ser contenida. Y sabes que por ejemplo, un elemento con márgen negativo bien podría solaparse con otro adyacente, por lo tanto, una caja adyacente no sufre un empuje debido a que esa mitad queda en el área de los márgenes entre ellas, que pueden existir o no, lo que a mi juicio hace más lógico que para que no se monten dicho margen debería existir.

Iniciado por Negora

En el caso específico de una tabla, como indicabas más arriba, su anchura incluye las mitades de los bordes. Pero, ¿Y las mitades que desbordan? ¿Como borde que es, por qué no va a pertenecer ni siquiera a dicho concepto y por lo tanto sumar en ese cómputo? Hasta donde sé, no hay nada en el estándar de tablas que anule su naturaleza como borde o su propia existencia.

Creo que aquí es válido el mismo argumento, es decir, si ya declara expresamente que "quedan en el área de los márgenes", indica a mi entender inequívocamente que no forman parte de la caja anónima, porque pertenecen al área de los márgenes, luego están obligatoriamente fuera de esta.

Como vengo diciendo, esta es la interpretación que yo hago.

Por otra parte, si en los bordes cerrados entre celdas adyacentes sólo ha de verse uno de los dos, que roba la mitad del espacio a cada celda al ser centrado, esto sólo se podría conseguir de una manera: suponiendo que tenemos un borde de 10px, que es lo que se verá entre celdas, los bordes dejan de ocupar espacio físico real permitiendo que se solape en su mitad externa con otro objeto (de igual naturaleza o no).

Si esto fuera cierto (lo más probable, para mi), el comportamiento de FF es correcto, ya que si el borde entre celdas ha de ser solapado en su mitad externa para fundirse con el adyacente y formar uno sólo, nada indica que no debiera hacerlo en las celdas que hacen límite exterior con otros objetos de distinta naturaleza, ya que el atributo es inherente al borde cerrado en sí, independientemente de qué otro objeto pueda haber a su lado.

Es por tanto una propiedad excepcional que permite el solapamiento de una mitad del borde y por tanto que ésta no pertenezca físicamente a la caja anónima de la tabla, y que no depende de qué objeto se situa a su lado, sino que es capaz de hacerlo con cualquier objeto.

Si no estás de acuerdo busca una explicación a cómo actúa un borde cerrado para solaparse con el adyacente entre celdas y mostrar únicamente el ancho establecido, y no duplicado como el en caso de los bordes abiertos.

P.D.: no sé tú, pero yo me estoy divirtiendo mucho con este debate.

[Negora]

Mikmoro: No sé si lo de "divirtiendo" lo dices con sorna, pero la verdad es que cuanto menos es entretenido y muy interesante, ¿No? :D . Al menos hace pensar, je je je.

No sé qué frase del estándar se corresponde exactamente con esa que mencionas (lo digo porque en este caso es importante la frase literal, que una palabra lo cambia todo).

Sea como sea, es correcto que los bordes ocupan el área de margen de la celda adyacente e incluso de la tabla (si no jamás se solaparían, lógicamente). El problema es que el estándar no especifica que ese borde deje de ocupar espacio físico, sólo que pasa a ocupar parte del margen del elemento (O al menos no he leído lo contrario). ¿Por qué un desbordamiento del borde no implicaría un margen con anchura igual a la de dicho desbordamiento? Para mí, que pase a formar parte del margen es que además de integrarse en él éste debe de adoptar su nueva dimensión.

Pero hay una sentencia muy interesante que había pasado por alto y arroja mucha luz creo yo:

"Any borders that spill into the margin are taken into account when determining if the table overflows some ancestor (see 'overflow')."

Si el sobrante del borde pasa al margen pero se supone que no ocupa espacio, ¿Por qué el estándar si lo tiene en cuenta para calcular el desbordamiento de un elemento ancestro?

Aquí es evidente que hay un serio problema de ambigüedad y que es prácticamente imposible que nos pongamos de acuerdo tú y yo. Si ni los de los navegadores lo consiguen... XD Habrá que esperar a ver si con la versión final de CSS3 se mojan y concretan mejor esto.

Yo desde luego ya he optado por evitar el uso de "collapsed", aunque requiera escribir más reglas a la hora de diseñar las tablas. Con esa mecánica de arriba me sobra y me basta ;) .

[Mikmoro]

Iniciado por Negora

Mikmoro: No sé si lo de "divirtiendo" lo dices con sorna, pero la verdad es que cuanto menos es entretenido y muy interesante, ¿No? :D . Al menos hace pensar, je je je.

Me has desconcertado. No hay ningún tipo de sorna; me divierto de verdad debatiendo. No encontraría un doble sentido ni rebuscando entre líneas. Lo siento si te ha parecido eso.

Iniciado por Negora

No sé qué frase del estándar se corresponde exactamente con esa que mencionas (lo digo porque en este caso es importante la frase literal, que una palabra lo cambia todo).

Es que yo leo la especificaicón en castellano
http://www.sidar.org/recur/desdi/tra...css/cover.html
(no soy nada bueno con el inglés). Quizá haya alguna duda con la traducción que desconozco.

Iniciado por Negora

El problema es que el estándar no especifica que ese borde deje de ocupar espacio físico, sólo que pasa a ocupar parte del margen del elemento[/B] (O al menos no he leído lo contrario). ¿Por qué un desbordamiento del borde no implicaría un margen con anchura igual a la de dicho desbordamiento? Para mí, que pase a formar parte del margen es que además de integrarse en él éste debe de adoptar su nueva dimensión.

Bueno, como he dicho, ¿cómo explicas que al solaparse entre celdas adyacentes la mitad exterior de ambas no ocupe espacio físico? Creo que ese es el quiz de la cuestión.

Iniciado por Negora

Pero hay una sentencia muy interesante que había pasado por alto y arroja mucha luz creo yo:

"Any borders that spill into the margin are taken into account when determining if the table overflows some ancestor (see 'overflow')."

Lo siento pero como he dicho no domino el inglés, y aunque pueda entender lo que dice, no sería capaz de interpretar si tiene matices específicos.

Iniciado por Negora

Yo desde luego ya he optado por evitar el uso de "collapsed", aunque requiera escribir más reglas a la hora de diseñar las tablas. Con esa mecánica de arriba me sobra y me basta ;) .

A este respecto, personalmente no usaría una tabla a no ser para mostrar datos tabulados, en cuyo caso dudo que estuviera dentro de una caja o que me produjera problemas con los elementos adyacentes: para mi una tabla tendría el suficiente espacio circundante (por pura estética y simetría), como para no darme problemas que un borde de uno o dos pixels la desbodara.

[Negora]

Mikmoro: No, hombre no, que no te lo decía en plan negativo, sino por si lo decías en plan "coña". No por otra cosa. A mí también me encantan este tipo de debates.

Yo del documento del que extraigo todo es del de la última versión, CSS v. 2.1: http://www.w3.org/TR/CSS21/cover.html . Está actualizada hasta 2007. En la versión 2, que es en la que se basa ese documento en Castellano que comentas, no aparecen aspectos como ése del desbordamiento, que considero muy importante, ya que esclarece que con un elemento contenedor sí que se interpreta que ese borde ocupa espacio.

De hecho, si pruebas en Firefox a meter una tabla "collapsed" en una capa DIV de menor tamaño con "overflow" a "auto", verás que el desplazamiento que crea no es hasta la mitad del borde derecho e inferior, sino que incluye las otras mitades que en caso del superior e izquierdo este navegador considera "etéreos" o sin volumen. Eso lo dicta así el estándar 2.1 y es correcto, así que, ¿Por qué interpretar las mitades sobrantes sin volumen?

Bueno, como he dicho, ¿cómo explicas que al solaparse entre celdas adyacentes la mitad exterior de ambas no ocupe espacio físico? Creo que ese es el quiz de la cuestión.

Es que realmente entre celdas o entre elementos internos de una tabla y ésta no existe solapamiento de bordes (pese a que lo hayamos denominado así en casos en los que las celdas tienen el mismo grosor).

El propio estándar especifica que el borde resultante es calculado y dibujado en base a unas normas de prioridad (por grosor, en principio, y luego según estilos). No hay solapamiento, sino reemplazo o sustitución del borde "perdedor" por el del "ganador".

¿Comprobación? Dibujando una tabla de 2 celdas con grosor de borde de 21px y 5 px respectivamente (en Firefox):




El primer ejemplo indica dónde queda la rejilla. El segundo y el tercero indica donde quedaría la rejilla si "ganase" el borde de esa celda. Si te fijas, si esto fuese un solapamiento de bordes, la celda derecha tendría que meterse más hacia la izquierda y parte de esas "xxx" quedaría solapada por ese borde "volante". Y no ocurre eso, sino que la mitad del borde más grande "gana" y ocupa un espacio que empuja a la celda con el borde que "pierde".

El solapamiento se produce, eso sí, entre la tabla y cualquier elemento adyacente, ya que fuera de sus dominios esta norma de cálculo de bordes no existe.

A este respecto, personalmente no usaría una tabla a no ser para mostrar datos tabulados, en cuyo caso dudo que estuviera dentro de una caja o que me produjera problemas con los elementos adyacentes: para mi una tabla tendría el suficiente espacio circundante (por pura estética y simetría), como para no darme problemas que un borde de uno o dos pixels la desbodara.

Hay casos simples en los que se produce este problema: Una tabla de decenas de columnas dentro de una capa con barras de desplazamiento. Se hace así con el fin de poder visualizar todas las columnas sin que afecte a la anchura del documento contenedor. Y ahí mismo los bordes superior e izquierdo quedan "comidos".

[Mikmoro]

Bueno, desgraciadamente no hablo inglés y no he estudiado nada la especificación CSS v. 2.1, y mis opiniones están basadas en una especificación algo más antigua, y que por lo tanto debe estar algo desactualizada, así que he de concluir que debes tener razón y las cosas son así.

Me ha resultado realmente entretenido.

Saludos.

[kseso?]

No lo dejen ahora, sigan, o saquen otra propiedad ambigua y discutible.

¿Quién iba a decir que 2px dieran para tanto?

[Negora]

Mikmoro: ¿Cómo? A ver, que sepas o no Inglés para nada descarta la argumentación que tú puedas presentar. Eso no invalida absolutamente nada de lo que has comentado hasta ahora. Lo que decía es que el estándar CSS v. 2.1 concreta algunos aspectos que la versión 2 no y que, como estándar que es, una traducción no literal podría inducir a error. Por eso te preguntaba a qué párrafo en Inglés correspondía, porque leyendo la especificación no daba con algo así.

De cualquier manera, las diferencias entre las versiones 2 y 2.1 no son tampoco abismales en cuanto a tablas, y esta última se limita a aclarar algo más el asunto de los bordes fusionados, pero sobre el mismo fundamento de prioridades por grosor y estilo. Es decir, que funciona tal cual era en la versión 2, pero matizado.

Ha sido en mi última lectura del estándar que me he fijado en que internamente no existe solapamiento alguno, pese a que en un principio diera por sentado lo que me comentaste de los márgenes solapados (porque tenía sentido, ojo). Aquí nadie nace aprendido y yo ni de broma me conozco el estándar de memoria (ni loco hago eso).

De hecho, creo que ambos hemos ido argumentando según íbamos leyendo extractos del estándar que apoyaran nuestras tesis. ¿O no? Y eso es completamente normal y de sentido común. Y más en un foro, en el que uno puede ir añadiendo conceptos nuevos que antes ni se le habían pasado por la cabeza.

[Mikmoro]

Iniciado por Negora

Yo del documento del que extraigo todo es del de la última versión, CSS v. 2.1: http://www.w3.org/TR/CSS21/cover.html . Está actualizada hasta 2007. En la versión 2, que es en la que se basa ese documento en Castellano que comentas, no aparecen aspectos como ése del desbordamiento, que considero muy importante, ya que esclarece que con un elemento contenedor sí que se interpreta que ese borde ocupa espacio.

Hola, Negora.

Lo siento, no ha sido por cortar el asunto sino que, como comentas ahí mismo, al parecer la especificaicón CSS v. 2.1 hace referencia a cuestiones fundamentales sobre las que estamos debatiendo que no están reflejadas en la que yo manejo por ser más antigua, y como no me manejo con soltura con el inglés, como te dije, es probable que en ese documento queden aclaradas algunas dudas de las que hablamos, y como no lo he leido ni lo podría interpretar con precisión, me parece lo lógico pensar que mi opinión se basa en datos que han quedado obsoletos o al menos has sido ya puntializados, por lo que debo creerte y pensar que debes estar en lo cierto. Nada más.