Form_remote_tag

Community ES
21

Ocurre que CSS no permite expresar ese tipo de cosas,

ya sí Tables

muchos browsers modernos ya lo soportan y de hecho incluso IE8 parece
que lo soportará también. Así podrás pintar divs, y usar css para el
posicionamiento en formato tabular sin recurrir a floats ni cosas del
estilo. Y como sólo aplica a la clase del objeto y no al objeto en sí
mismo, no es semántico con lo que no hay problemas filosóficos.

saludos,

–
javier ramírez

…i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
…you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez

22

Sergio Cambra .:: entreCables - Symbol Servicios
wrote:

El Tuesday 28 October 2008 11:46:27 David D. escribió:

</tr>

Igual és porqué tengo el formulario en un controllador que no es “works”
Gracias cracks!
Si quieres usar

para colocar los campos, al menos ponlo dentro de
un y un

–
Sergio Cambra .:: entreCables - Symbol Servicios Informáticos S.L. ::.
Nicolás Guillén 6, locales 2 y 3. 50.018 Zaragoza
T) 902 021 404 F) 976 52 98 07 E) [email protected]

Estan metidos en un

i un , simplemente los había omitido en
mi consulta para escribir menos.

Y NO maqueto con tablas, simplemente las uso “alguna vez” para
formularios con muchos campos (qüestión de mandra!!)

jejeje

23

El 29 de octubre de 2008 7:35, Xavier N. [email protected] escribió:

Simplemente muchas gracias Xavier ! Es precisamente la linea de
pensamiento
que a nosotros los simples mortales nos ayuda en el dia a dia para
cumplir
los multiples compromisos que tenenos.

Un abrazo.
Saludos cordiales.

24

2008/10/29 Xavier N. [email protected]

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

Lo siento mucho si ha sido así, cosas de contestar rápido y estando a
mil
cosas :slight_smile:

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.

Me alegro, no he criticado el libro, que no conozco. Sólo he dicho que
me
sonaba raro eso que decías

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.

En el desarrollo web los axiomas suelen tener poca eficacia. Como dije
en el
primer mail a Sergio, todas las buenas prácticas de marcado llevan el
corolario “a menos que sepas bien lo que estás haciendo”. En el momento
en
el que se comprueba que las dos personas que discuten un punto tienen
claros
los principios, los porqués y los cómos, no tiene mucho sentido discutir
sobre casos teóricos.

an

Mmmm, sí, ahora ya no estoy seguro de qué estamos discutiendo :slight_smile: Los
datos
tabulares se formatean con tablas. Estos datos tabulares pueden ser un
formulario y entonces también se usa una tabla. ¿En qué estábamos en
desacuerdo? :smiley:

Resumiendo, las principales maneras de maquetar un formulario son, a
saber,

a) Con elementos de bloque genérico (div)

b) Con p

c) Como definition lists (dl)

d) Como tablas

Y de ahí, a elegir la que corresponda en cada momento, que es en
definitiva
a lo que se reduce el arte del marcado estructural