#61 pero si directamente no funcionase Facebook te afecta más porque no podrías hacer nada, sí o no? No te extiendas más que esos dos monosílablos.
#61 si me hablas por chat y no tengo JS me llega, hablar por chat es como enviar privados en facebook asi que no digas tonterías.
#63 el feedback es igualito, hablar por chat que por mensajería privada es igual de rápido.
Y POR SUPUESTO, no sabrás que te ha llegado el mensaje hasta que pulses f5.
#64 repito... y tu solución a que no funcione una parte de la web porque obviamente no puede funcionar sin JS (al ser dinámico) es que no funcione nada, ni siquiera lo estático?
¿O es mejor mi versión en la que todo lo que puede funcionar sin JS funciona, y ADEMÁS si tienes JS funciona la parte dinámica JS? Antes de que vuelvas a decir alguna tontería: AMBAS opciones a la vez, no dinámico O estático sino dinámico Y estático.
#64 no he dicho que sea el mismo feedback, he dicho que funciona y que siguen llegando los mensajes. No mientas 
#66 sí pero ya pierde todo su cumplido, que es comunicación rápida. Así que técnicamente podría decirse que no funciona.
#65 no, pero si desde el primer momento en el que empiezas a desarrollar una web compleja (no esa mierda corporativa que has puesto antes que está maquetao con tablas) te pones a capar funcionalidades o diseños modernos (sliders, efectos molones...) porque un % muy pequeño de usuarios pueda tener javascript desactivado... apaga y vámonos.
Nunca podrás desarrollar una web como esa de Air Jordan, y bueno, no hay que fliparse tanto con el diseño, esa promo es extraordinaria. Webs más normalitas, que necesiten sliders y otras funcionalidades.
Amigos?
Me pido ^^ !!!!
#67 pero por qué insistes en que hay que capar? Que no hay que capar.
¿Por qué se te ha metido en la cabeza que hay que capar? ¿Por qué se te ha metido en la cabeza que el que tiene JS pierde funcionalidad?
¿Por qué?
#71 porque si tienes que mostrar un slider con 5 promos, el que tenga JS verá todas y podrá beneficiarse, tú obtendrás ganancias. El que no tenga JS no.
Así? Quién es ahora el genio de los negocios?
#72 lo sigue siendo kaod, porque el que no tiene JS puede seguir comprando, mientras el que tiene JS ve las ofertas también.
Tu solución es que directamente quien no tenga JS no pueda comprar
#73 #74 el que no tenga js no puede ver las promos porque ÉL NO HA QUERIDO.
Al que tiene JS por supuesto no le afecta, wtf, de eso no estamos hablando. Estamos hablando de la funcionalidad que pierde el que lo tiene desactivado, que en este ejemplo en particular, es bastante importante. No poder comprar = no obtener beneficios.
Tenemos 1000 usuarios que están dispuestos a comprar en nuestra tienda, 990 con js y 10 sin js.
PORTAL A) Con un slider gigante con promos.
990 personas verán todas las opciones, seguramente les gusten porque son ofertas o packs, y compran.
10 personas no lo ven, van entrando por la navegación en otras categorías pero no le convencen y se piran.
PORTAL 
Sin slider de promos.
Ambos usuarios tendrán que navegar por las categorías de la tienda, y puede que vean, o no, las ofertas que tienes. Las ganancias serán notablemente menores.
#75 "Al que tiene JS por supuesto no le afecta, wtf, de eso no estamos hablando"
Me acabas de confirmar que no te has enterado de nada o se te ha olvidado de dónde viene la discusión. Repasa #13 #14 #15 #16
#76 "Sin embargo para nosotros, los webmasters que hacemos webs, no estamos obligados (mas que de forma moral, variable en cada individuo)"
No es una cuestión moral. Es una cuestión de dinero.
Allá ellos no. Allá tú.
#76 por fin aparece alguien coherente por aquí.
#77 me diste la razón aquí
si pierdes funcionalidad importante (que es lo que llevo diciendo todo el rato), es muy posible que estés perdiendo beneficios.
Por qué dices que no me entero de nada? El que tiene JS disfrutará de la web al 100% y el que tenga JS desactivado se perderá una experiencia de usuario importante y funcionalidades varias.
Y DIME QUÉ PORTAL ES MEJOR, el A o el B.
#78 "Por qué dices que no me entero de nada?"
Porque estás discutiendo de una tema que no se está tratando.
Aquí se hablaba de que una web deje de funcionar completamente porque los submits no existen y se han reemplazado al 100% por JS.
"Al que tiene JS por supuesto no le afecta, wtf, de eso no estamos hablando."
¡DE ESO SÍ ESTAMOS HABLANDO!
Estamos hablando de añadir funcionalidad para que el que tenga JS siga sin afectarle y al que no tenga JS le funcione igual.
La única razón que se me occure por la que sustituir un submit por js es validación de datos en frontend.
#79 que le follen a los input colega, el tema cambió hace 70 posts. Dije en esos posts que citas que preparar una web pensando en que el usuario puede tener JS desactivado es una gilipollez.
En todo caso, primero la haces full (con diseños modernos, nada de mierdas), y después si eso vas adaptando a contenido sin JS. Pero NUNCA al contrario joder!
#80 se pueden validar los datos del lado del cliente con el submit.
Vaya comos las liais hamijos!
#79 En el post que decías que usando el button en un form se pierde accesiblidad, toda la razón del mundo. Lo demás son 2 páginas de una discusión absurda.
#80 Se pueden validar usando el submit, que no es tan complicado.
#84 ¿Cargando el backend con tonterias? En fin /facepalm
Los datos se han de validar siempre en BACKEND, que luego por comodidad al usuario para no hacer miles de envios valides el JS en FE es otra historia.
#80 ni así. Se puede validar datos en FE pero en BE vas a tener que validar igual porque si no... ¿te paso los datos chungos por POST y santas pascuas?
Y con un submit vas a tener la validación en frontend con JS activado + backend para ambos.
#84 si necesitas validación la tienes que hacer en backend sí o sí. Validar sólo en frontend es un suicidio a no ser que no te importen los datos, en cuyo caso, ¿para qué validar?
Pero vamos que como dice #82 puedes validar en frontend sea submit o button, ¿eh?
La única diferencia es que el submit cuando no haya JS hará submit (y validará en servidor solamente) mientras que si pones button no funcionará y fin.
#85 él se refiere a validar expresiones, no datos. Evidentemente los datos hay que validarlos en el servidor, pero bien podría hacerse con ajax + jquery en vez de crear un chorro de peticiones.
Conclusión? Ganas rendimiento y rapidez para el usuario.
#86 ¿Expresiones?
El ser refiere a validar TODOS los datos, no solo el email con expresiones regulares.
Antes de pasar cualquier dato de la web a cualquier sitio BBDD, ficheros/loquesea lo que hay que asegurarse es que los datos no te la puedan liar o qué?
#87 expresiones regulares para comprobar que un email sea correcto, para comprobar que un número de teléfono sea correcto... etc.
Para comprobar que un email existe tienes que llamar al server sí o sí. A menos que cargues en un array todos los emails de la bd y los compruebes con js, cosa que evidentemente es inaceptable.