Pero siempre puedes hacerlo correctamente enviando todos los valores cuando
este el js desactivado y meterle una capa de js (usando ajax, ademas creo
que este caso concreto te viene muy bien realizar peticiones asincrónicas).
Yo en mi humilde opinión no creo que haya que prescindir del js, solo
Como indican, creo que, al fin y al cabo, lo mejor es hacerlo
funcionar sin js, pero sí
agregarle funcionalidades no intrusivas con js
De paso dale una miradita a jQuery donde puedes capturar el evento
submit y así filtrar y enviar sólo lo que necesitas reduciendo el
tráfico en la red, haciendo
2009/5/19 Miguel Beltran R. yourpa...@gmail.com
El 18 de mayo de 2009 5:07, Tei oscar.vi...@gmail.com escribió:
...
Claro que esto es mas apropiado para la lista de correo
www-h...@w3.org y no la nuestra.
lo he consultado en esta lista, www-html, y de momento lo que me han dicho
es
lo he consultado en esta lista, www-html, y de momento lo que me han
dicho es que se puede utilizar un unico form y diferenciar que linea
se esta enviando por el valor del submit input type=submit
name=borrar_30 value=Borrar email /input type=submit
name=reply_30 value=Eliminar email /
El 19 de mayo de 2009 8:19, Tei oscar.vi...@gmail.com escribió:
2009/5/19 Miguel Beltran R. yourpa...@gmail.com
El 18 de mayo de 2009 5:07, Tei oscar.vi...@gmail.com escribió:
...
Claro que esto es mas apropiado para la lista de correo
www-h...@w3.org y no la nuestra.
lo
El 19 de mayo de 2009 9:22, Félix Horro Pita fho...@corunet.com escribió:
lo he consultado en esta lista, www-html, y de momento lo que me han
dicho es que se puede utilizar un unico form y diferenciar que linea
se esta enviando por el valor del submit input type=submit
name=borrar_30
No estamos hablando de layout sino de datos tabulares, donde en cada una
de las filas hay datos relacionados y que se deben tratar como un
formulario.
Yo creo que tener un formulario por fila tiene todo el sentido, aunque
no lo soporte la versión actual de HTML.
Incluso me atrevería a
Fe de erratas:
me perdonen vd la ortografía.
2009/5/18 Tei oscar.vi...@gmail.com:
Puestos a extender el estandar, y puesto que el problema es real, y
HTML se queda corto. ( vamos a suponer que es cierto que datos
tabulares + formularios por cada linea es una necesidad real, que lo
es ) ...yo
Puestos a estender el estandar, y puesto que el problema es real, y
HTML se queda corto. ( vamos a suponer que es cierto que datos
tabulares + formularios por cada linea es una necesidad real, que lo
es ) ...yo preferiría que los input pudieran vivir fuera del form,
asi:
input type=text
Pues también está bien... Alguien sabe si se está trabajando en este
tipo de cosas para especificaciones futuras?
Tei escribió:
Puestos a estender el estandar, y puesto que el problema es real, y
HTML se queda corto. ( vamos a suponer que es cierto que datos
tabulares + formularios por cada
El 18 de mayo de 2009 5:07, Tei oscar.vi...@gmail.com escribió:
Puestos a estender el estandar, y puesto que el problema es real, y
HTML se queda corto. ( vamos a suponer que es cierto que datos
tabulares + formularios por cada linea es una necesidad real, que lo
es ) ...yo preferiría que los
Se debe usar aquel que sea válido gramaticalmente.
2009/5/15 Miguel Beltran R. yourpa...@gmail.com
Hola lista, tengo una duda para el correcto uso de form's cuando se
presentan los datos usando tablas.
FORMA 1
table
thead
trTITULOS/tr
/thead
tbody
form
trtdinput .../td.../tr
Hola Miguel,
a no ser que tengas un formulario distinto para cada fila, lo lógico es que
el /form sea el contenedor de /table, ya que lo que deduzco de tu escueto
mail es que la tabla la usas como elemento estructural para organizar los
campos.
Saludos,
Martí.
--
2009/5/15 Miguel Beltran R.
Si es solo para organizar los elementos, una tabla no es lo correcto,
y no es necesaria tampoco.
Lo elementos de form son suficientes y los correctos (form, fieldset,
label, input).
Puedes checar algo sencillo como http://morsmotors.publiweb.com.ve/contactos
On May 14, 2009, at 8:44 PM,
El 15 de mayo de 2009 2:09, mmundo mmu...@gmail.com escribió:
Hola Miguel,
a no ser que tengas un formulario distinto para cada fila, lo lógico es que
el /form sea el contenedor de /table, ya que lo que deduzco de tu escueto
mail es que la tabla la usas como elemento estructural para
El 15 de mayo de 2009 9:39, Ramon Lapenta ram...@gmail.com escribió:
Si es solo para organizar los elementos, una tabla no es lo correcto,
y no es necesaria tampoco.
Lo elementos de form son suficientes y los correctos (form, fieldset,
label, input).
Puedes checar algo sencillo como
2009/5/15 Miguel Beltran R. yourpa...@gmail.com:
...
table
thead
trTITULOS/tr
/thead
tbody
tr
formtdinput .../td.../form
/tr
/tbody
/table
con independencia de lo que diga el estandar o como esten construidos
los user agent. Esto es feo. form crea nuevo bloque, como div, asi
con independencia de lo que diga el estandar o como esten construidos
los user agent. Esto es feo. form crea nuevo bloque, como div, asi
que no es inocuo al layout. Si solo fuera informativo, como
noscript style... pero no es el caso. Meterlo entre table y
tr por tanto parece que
me parece una consulta interesantísima. he dedicado un rato a buscar
posibles soluciones y podría decir con bastante seguridad que no la hay.
Un tr tiene que estar directamente dentro de un table, un tbody o
un thead/tfoot. A su vez, sólo puede contener th o td. Por
tanto, no se puede
Alguna de mis reflexiones espontáneas:
- Si nos ajustamos a la visión actual basada en los estándares, deberíamos
partir de un tableless layout, osea, separar los elementos forms, de los
elementos de tabla. Son dos conceptos que actualmente no tiene sentido
fusionar. Las tablas tienen su mundo
Lo que yo he hecho, ya que habitualmente debo trabajar con
aplicaciones con grillas, es crear sólo un formulario con campos
hidden y en cada TD pongo un a que apunte a un javascript que llene
los hidden y envie el formulario.
Algo así.
function pagar(idPago, monto){
El 15 de mayo de 2009 10:29, David Pardo da...@corunet.com escribió:
me parece una consulta interesantísima. he dedicado un rato a buscar
posibles soluciones y podría decir con bastante seguridad que no la hay.
Por lo que he visto asi parece, ya revise y FF cuando detecta este tipo de
codigo
El 15 de mayo de 2009 15:36, Chr5 chr5ma...@gmail.com escribió:
Alguna de mis reflexiones espontáneas:
- Si nos ajustamos a la visión actual basada en los estándares,
deberíamos
partir de un tableless layout, osea, separar los elementos forms, de los
elementos de tabla. Son dos conceptos
El 15 de mayo de 2009 16:47, Phaseolus phaseol...@yahoo.es escribió:
Lo que yo he hecho, ya que habitualmente debo trabajar con
aplicaciones con grillas, es crear sólo un formulario con campos
hidden y en cada TD pongo un a que apunte a un javascript que llene
los hidden y envie el
Hola lista, tengo una duda para el correcto uso de form's cuando se
presentan los datos usando tablas.
FORMA 1
table
thead
trTITULOS/tr
/thead
tbody
form
trtdinput .../td.../tr
/form
/tbody
/table
FORMA 3
table
thead
trTITULOS/tr
/thead
tbody
tr
formtdinput
25 matches
Mail list logo
