A veces me he encontrado con cosas que funcionan en unos browsers sà y
en otros no. En muchos casos el culpable era por anidamiento mal hecho
de tablas, y en el caso de Ajax, por intentar actualizar partes de una
tabla que no se pueden.
No estoy seguro si es legal poner un form como lo tienes tú, alegremente
con sólo dos TDs dentro, de hecho jurarÃa que no. Entre un y un
creo que no puedes tener nada.
Prueba a dejar tu form fuera de la tabla, a ver si es por eso.
Si quieres usar para colocar los campos, al menos ponlo dentro de un
y un
O mucho mejor, olvidémonos de las tablas para maquetar, que ya estamos en
2008 y canta un poco
Hombre Manu, se me ocurren algunas razones legítimas para querer meter
un formulario en una tabla que no implican usar las tablas para
maquetar… está bien poder saber cómo se hace.
Creo que “no usar tablas para maquetar” no es “no usar tablas”, sino
no usarlas “para maquetar” (te presento a mi amigo Pero Grullo =;-) ).
Las tablas tienen su uso, que es representar series de datos
tabuladas. ¿No se puede querer hacer alguno de esos datos editables?
¿O (este es un caso supertípico que tiende a aparecer antes o
despuésen casi cualquier proyecto) añadir a cada fila un ckeckbox y un
botoncito de “borrar seleccionados” al pie?
Hablo desde un importante desconocimiento de las técnicas de
maquetación, pero a priori a mí no me parecen “prácticas tabú” por
mucho que requieran mezclar formulario y tabla. ¿Lo son?
Mmmmm, me has hecho una finta con el cuerpo No es lo mismo maquetar
un
form con tabla que hacer que una tabla sea editable (“formicizar la
tabla”)
Lo primero no, lo segundo sÃ, como tú dices. A estas horas de la
madrugada
he estado poco sutil para hacer la distinción y lo he cerrado con un
brochazo un poco gordo.
Lo que si que es cierto es que a veces usar forms y tablas da pà ginas
“no w3c compliant”, y si la validez del documento html es prioritario,
no hay más “klanders” que usar otros elementos: divs, ul-li’s, etc…
Para que la página valide hay que poner los tags en su sitio claro.
Una cosa es la validación (corrección formal) y otra las buenas
prácticas
estructurales. Una página maquetada con tablas puede validar
perfectisisimamente, pero incumple una buena práctica estructural
fundamental: no se maqueta con tablas.
Y no conozco ese libro, pero ya para empezar no me suena nada bien eso
de
“se acaba antes con …” Tambien se “acaba antes …” sin tests, o
metiendo
todo en el controlador o haciendo Model.find en las vistas o duplicando
código php en ruby … En definitiva, que me parece muy mal consejo y me
hace mirar con mucha cautela el libro (por no hablar de que el uso de
XHTML
en el tÃtulo ya da mala pinta)
Pero nos estamos yendo de cabeza al off-topic y tendremos que dejarlo
aquÃ
La prueba del algodón es simple: coged un screen reader (FireVox http://firevox.clcworld.net/ debe ser el más sencillo de conseguir),
cerrad los ojos o quitaros las gafas :P, y dejad que lea la página. Si
os hartais de “start table”, “start row”, “start cell”, es que vuestro
diseño no se debÃa haber realizado con tablas, en otro caso, supongo
que está bien.
Para que la página valide hay que poner los tags en su sitio claro.
Una cosa es la validación (corrección formal) y otra las buenas prácticas
estructurales.
Si, si claro.
Una página maquetada con tablas puede validar
perfectisisimamente, pero incumple una buena práctica estructural
fundamental: no se maqueta con tablas.
Y no conozco ese libro, pero ya para empezar no me suena nada bien eso de
“se acaba antes con …” Tambien se “acaba antes …” sin tests, o metiendo
todo en el controlador o haciendo Model.find en las vistas o duplicando
código php en ruby …
Ahi te has pasao generalizando mi comentario :-).
La serie “Head First” de O’Reilly es en mi opinion extaordinaria.
Naturalmente tiene autores competentes a los que les asumo que no
dicen gilipolleces gratuitas. Esa excepcion se encuentra en el
capitulo de forms con un titulo “To Table or Not to Table?” en un
libro que por lo demas enseña uso de HTML + CSS canonico y formalmente
impecable.
Ante el axioma “aqui no se maqueta en tablas ni una coma” hay que
observar que gente que esta en el tema admite esa excepcion en
concreto dada cuenta de que uno maqueta forms tabulares en HTML + CSS
y le sale tal castaña de codigo que no puede sino preguntarse si
merece la pena.
Y hay gente con criterio que cree que no siempre merece la pena (y
admite que es polemico).
Asi que yo soy de la opinion de que puedes tener un site de puta madre
super limpio y super CSS por todas las esquinas. Pero un listado de
clientes se formatea con una tabla (eso es un buen uso de las tablas,
como decia Sergio), y un form tabular lo formateo con una tabla porque
me parece una excepcion razonable a la regla general acerca de como se
hacen layouts modernamente.
El problema real de verdad en todo esto no es separacion
maquetacion/contenido. El problema de verdad que subyace es que CSS
por diseño es maquetacion de elementos que siguen un flujo.
Por tanto, por como es CSS hacer cosas con layout tabular en CSS es
una castaña y vas en contra de como esta pensado. Si CSS permitiera
decir “quiero una pagina con un header y una parte principal de 3
columnas con estos anchos relativos” sin tener que ir con floats ni
clears ni ecuaciones diferenciales que hay que resolver para algunas
cosas verias que todo el mundo usaria esas directivas “tabulares” sin
mas problema y sin ningun conflicto interno.
Ocurre que CSS no permite expresar ese tipo de cosas, y por eso
entiendo que haya gente que ante un problema muy concreto como es el
de los forms decida que ya le supera el umbral.
Yo tengo entendido que esa parte de la spec en cuanto a HTML solo
aplica a tablas. No significa que puedas montar elementos maquetados
con un “lenguaje tabular”. De ahi que para HTML especifique que:
table-row-group (In HTML: TBODY)
por ejemplo.
Vamos, que no sirve para decir que los DIVs hijos de #signup-form
tiene un display “table-row”. Segun entiendo es un estilo ilegal en
HTML pero el navegador debe saber parsearlo y hacer como si no
estuviera ahi:
“User agents may ignore these ‘display’ property values for HTML
documents, since authors should not alter an element’s expected
behavior.”
Pero tambien es verdad que he visto lo de IE8… Desde luego que si
algun dia se pudieran maquetar partes de la pagina de esa manera
ademas de lo que ya se puede hacer seria genial.
No es lo mismo maquetar