Elementos que desaparecerán en breve de HTML

#101   #99 Explícate por favor, yo creo que el HTML es un lenguaje muy bueno y muy bien hecho, siempre que tengas claro qué es, para qué sirve, y cuales las las diferencias entre HTML (información), CSS (estilo) y Javascript (interactividad avanzada).

¿Cuales son esos problemas que arrastra?

#102   #8 #18 Es mucho más beneficioso para el peso de una página que esté correctamente formada a ahorrarse 10 bytes por etiqueta strong. Y si no lo entiendes es que no comprendes las definiciones de HTML y CSS y por qué se quiere conseguir la separación de funcionalidades (y no será por que no lo hayan explicado mil veces en mil sitios).

#103   #25 Sufres del llamado "divitis". No debes rellenar todo de divs y spans, con CSS puedes modificar cualquier etiqueta casi por completo, puedes no metas un enlace en un div para darle estilo y convertirlo en un botón, dale estilo al enlace directamente, ¡con display block ya es practicamente un div!

Por otra parte, también estaría mal escribir class="red", un nombre de clase debe definir qué funcionalidad tiene su contenido, no su estilo, todo lo que tiene que ver con el estilo debe ir en la CSS. Debería tener un class="descripcion coche" y en la CSS decirle que ese elemento es rojo.

#104   #88 Pues mola.

Yo lo hacía casi a pelo, solo con bluefish. Pero expresamente, porque quería aprender.

#105   #25 aparte de lo que te han dicho arriba, una de las cosas geniales (entre muchas otras) que añade HTML5 son etiquetas como header, footer, nav, article, section, etc. con lo cual se acabarán la mayoría de divs sin semántica (y como consecuencia, se podrá jugar con la manera de visionarlos en distintos dispositivos).

#106   #89 Completando lo que te dice #94, applet siempre ha sido desaconsejado por el estándar W3C, (ya que existía object, que era lo que usaban todos los demás plugins) lo que pasa es que Sun era lo que animaba a usar a los desarrolladores, por compatibilidad con navegadores viejos. De todas formas, applet no desaparece, se deja como obsoleta para los desarrolladores, pero se sigue obligando a los navegadores compatibles con HTML5 que la implementen (aunque produzca un warning). En cualquier caso, es una de esas cosas que con la magia de JS se puede intercambiar al vuelo.

#107   #84 Usando HTML5! (incluyo aquí JS) Las novedades que traerá (algunas ya están implementadas) son: almacenamiento local de información, aplicaciones offline, acceso a streaming de tu webcam y micrófono, geolocalización (podría ser mediante GPS/red movil/wireless/IP), sensores hardware (acelerómetro, temperatura, rotación,...), drag & drop, mensajería, sockets (conexiones entrantes y salientes hacia otras aplicaciones),...

#108   Uff! ¡que alivio! No tocan <BLINK>
En cualquier caso siempre me quedará text-decoration:blink

#109   Elementos que desaparecerán en breve de... HTML5
Porque el HTML es un estándar y seguirá siéndolo siempre.
Cuando el W3C coloque la etiqueta de Obsoleto, entonces quizas.
www.w3.org/TR/html4/

#110   <marquee> Hola mamá, me muevo sin manos!! </marquee> </nostálgico>

#111   #81 Esas etiquetas no van a desaparecer, solo han sido depreciadas. Es decir, se recomienda que no se usen más porque han sido sustituidas por otras que se consideran más correctas. Pero no van a dejar de funcionar. Todos los navegadores incluyen un modo de renderizado acorde a estándares (más rápido, y para el que deberías desarrollar si empiezas un proyecto nuevo) y otro de compatibilidad, para dar soporte a páginas que no sigan estrictamente el último estándar. Mientras mantengas el doctype de cada página bien declarado, tu web seguirá funcionando sin que tengas que hacer nada.

#89 El problema de la etiqueta applet es que hace referencia a una tecnología específica. ¿Qué sentido tiene utilizar una etiqueta para incrustar un applet y otra distinta para hacer lo mismo con un cualquier otro tipo de objeto?

#112   #25 como vean que haces: <span style='color:red'>Hola</span>, ponen el grito en el cielo. Luego ellos van y hacen <span class='red'>Hola</span> y se quedan tan panchos.

Imagina que tienes una web grandecita con unos cuantos miles de páginas y que tu jefe te dice que esos trozos de texto de color rojo los tienes que poner de color verde. ¿Prefieres buscar y reemplazar en miles de páginas o cambiar una línea de un fichero .css? Por no hablar del contenido que pueda estar en BBDD.

#113   #81 no te debes de preocupar por eso porque se eliminan del html5, no del html4... de todas formas, que a ti no te de la gana de aprender a escribir un lenguaje correctamente no es razón de peso para que el html no avance.

#84 se pueden incluir applets con el elemento OBJECT de html5: eyeasme.com/Shayne/HTML5_APPLETS

#99 por lo menos a lo que a mi respecta, escribo todo el html y css a mano, desde 0 (que para eso me pagan) así que no se a que te refieres con "algún tipo de herramienta"

#114   #51 Para que #25 y el resto sepan a que otros elementos te refieres, pongo sus equivalentes al lado

<div id="header">... </div> --> <header> ... </header>
<div id="content">... </div> --> <article> ... </article> o <section> ... </section>
<div id="footer">... </div> --> <footer> ... </footer>.

Además hay otros como <aside> para los típicos menús laterales o <nav> para las barras de navegación.

El tema retrocompatibilidad es tan simple como usar html5shiv code.google.com/p/html5shiv/ o cualquier otro que hacer que IE lo pille correctamente. El resto de navegadores asumen que los tags desconocidos son divs o ya soportan HTML5. A la práctica puedes crear nuevas etiquetas (consecuencia de la actual implementación de los principales navegadores), aunque el estándar no lo recomienda pero eso no evita que recomienden a los navegadores intentar mostrar el contenido de los tags desconocidos.

Para los que reniegan de la pérdida de esas etiquetas: "It's all about semantics, stupid!" www.alistapart.com/articles/semanticsinhtml5

#115   #85 No tiene mucho sentido que primero digas:
2º ¿Optimización? strong = 9 Bytes, b = 4 Bytes... 5 bytes de diferencia... conexiones de 20Mbits... procesadores con tantos núcleos como pedos se tiran al día... creo que no es relevante
Y luego te contradigas:
No eliminarlas implica que el navegador tenga que saber parsearlas, y eso aumenta el código del navegador y el tiempo de renderizado (en unidades infinitesimales, pero oye, grano a grano se hace el granero).
Pues lo mismo se te puede decir respecto al strong, el b y todo lo demás. Grano a grano se hace el granero...

#116   #112 A los hombres no nos da miedo ejecutar
find -name '*.html' -exec sed -i 's/<span style='color:red'>/<span style='color:green'>/g' {} \;

#117   <u>

Utilizado para indicar texto subrayado, ahora usamos CSS y más concretamente: text-decoration:underline


Pasamos de utilizar 3 caracteres a usar 25. Cierto es que una sola vez, pero se podrían mantener las etiquetas HTML dentro del CSS, las que eran muy ligeras.

#118   Para aquellos que se rasgan las vestiduras pensando en el peso de un documento HTML porque vayan a dejarse de usar etiquetas "cortas" a favord de etiquetas más descriptivas: la mayoría de servidores web sirven el contenido HTML comprimido con gzip. Y en caso de no hacerlo, es relativamente sencillo configurarlo para que lo soporte (os costará más buscarlo en Google que configurar el servidor, y no es que os vaya a costar nada buscarlo...).
Cualquiera con unas mínimas nociones de compresión de datos (y yo no soy un gurú del tema precisamente), sabe que el texto plano tienes un factor de compresión bastante grande.

user@host:~$ wget -qO - meneame.net|wc -c
67501
user@host:~$ wget -qO - meneame.net|gzip|wc -c
15343

Como podéis ver, 4 veces menor de una a la otra. Que algunas etiquetas tengan algunos caracteres de más respecto de las que replazan, no es ningún drama. Máxime en los tiempos en los que te bajas películas de varios megas (o gigas) en cuestión de minutos. Para los que no dominen las unidades de tamaño en bytes: 67501 es la 0.000067501 parte de un giga (asumiendo que un giga son 1000M...). Vamos, eso en mi pueblo no es nada...

#119   Creo que la gente no ha entendido bien la noticia:
Las etiquetas no van a desaparecer de HTML. Van a desaparecer de HTML5.
Los navegadores seguirán renderizando igual las páginas antiguas, con lo que estas nuevas reglas son sólo para las nuevas páginas en HTML5.

#120   #51, #112, #105, #103, #51, #42 Guau cuanta gente ha saltado
-Soy programador, no maquetador. A mí me pasan el html ya maquetado, así que no tengo mucha decisión sobre donde va un div.
-Sigo pensando que no se arregla nada con html5 con añadir un tag para el footer y otro para el header.
-Y #25, a eso me refiero con lo de definir una clase como 'red' para aplicar el rojo. Ahí te estás cargando el concepto. Si haces así y pasa lo que dice el jefe de #112 ¿qué haces? ¿que la clase red pase a colorear el texto en verde? Con eso quería decir que hay mucha gente que defiende el CSS y luego hace esas cosas creyendo que ahora lo está haciendo bien. Otro ejemplo: las tablas son malas, no hay que usar las tablas. Y van y crean lo que viene siendo una tabla con <div> y display:cell-table y cosas de esas.

#121   #120 No hay que diseñar webs con tablas básicamente porque las tablas se pensaron para presentar datos tabulares. Como han dicho en un comentario anterior, se busca que el HTML tenga cierta semántica. Además, los diseños con tablas pueden hacer que los dispositivos para personas con discapacidad visual se armen la picha un lío.

Nadie criticaba el diseño web con tablas por el concepto en sí, si no por el uso de las tablas propiamente. Yo soy el primero que cuando esté bien soportado el display:cell-table en la mayoría de navegadores, lo usaré como un loco en mis proyectos (qué ganas de que desaparezcan Explorer 6 y 7...)

#122   #121 No hay que diseñar webs con tablas básicamente porque las tablas se pensaron para presentar datos tabulares. A eso me refiero. Frases así las he visto en muchos sitios y, o lo entendiste mal, o no te expresas bien y llegará otro y lo entenderá mal. No se han de posicionar elementos con tablas. Pero diseñar una web con tablas es perfectamente válido si en las tablas van... datos tabulados!!

#123   #97 ¿En qué momento he dicho yo que se deban escribir todos los estilos en la propia etiqueta HTML? Simplemente di una equivalencia a <center>, pero a mí me gusta tenerlo todo bien separado, por un lado la hoja de estilos y por otro el HTML con sus atributos class e id.

#84 ¿El consumo de recursos, en qué exactamente? ¿En serio? Si no puede haber nada más compacto que un fichero HTML limpito, con solo la información justa, y por otro lado una hoja de estilo. Incluso más limpio que usando todas esas etiquetas tan anticuadas que la gente se niega a dejar de utilizar.

#124   #86 ¿El consumo de recursos, en qué exactamente? ¿En serio? Si no puede haber nada más compacto que un fichero HTML limpito, con solo la información justa, y por otro lado una hoja de estilo. Incluso más limpio que usando todas esas etiquetas tan anticuadas que la gente se niega a dejar de utilizar.

(perdón #84)

#120 Las tablas son malas porque los buscadores tienen problemas para indexar la información que contienen, a parte de que se comportan un poco como les da la gana según el navegador con el que las visualices.

#125   #6 Estás "sembrao" con los comentarios compañero. Toda la razón.

Lo mismo con <center>. Por ejemplo

Además usar CSS es mucho más engorroso que el HTML en sí.

#119 Realmente aunque yo entendí la noticia. Es lo que pone el titular y debería ser "desaparecerá de la versión 5 de HTML o de HTML5". Y no "de HTML" como pone la propia noticia.

Salu2

#126   Iba a comentar algo parecido a #31 pero ya me lo ahorro.

Desde luego una de las peores lacras del mundo del desarrollo web es que hay muchísima gente que se cree super guay por usar la etiqueta "b" que está completamente obsoleta y debería de haber desaparecido hace eones.

Basta ya de estilos en línea y de dar estilos con etiquetas. Usemos las "hojas de estilo" para eso, que su nombre indica perfectamente para que valen.


+1 para HTML5

#127   #124 Otro con verdades absolutas. Dudo que los buscadores tengan problemas en indexar los datos de una tabla si realmente los datos son una tabla.

#128   #86, pues tenemos ideas distintas , la idea de pensar, como sobra memoria y ancho de banda da igual a mi tampoco me gusta, es un cancer para la informatica de ahora que genera codigo y abuso de recursos, pero:

yo antes tambien pensaba que cuanto menos bytes mejor, y soy fanatico de la optimizacion, pero optimizar significa buscar un compromisos, el mantenimiento de una web se hace un dia si otro tambien y sacrificar unos bytes por hacer un codigo facilmente mantenible es una gran ventaja que añade un "infinitesmal" de bits

con un buen sistema de compresion de imagenes, cuidando la publicidad, los efectos.., si que se quitan quitan muchos mas bits, lo otro es como pensar que por quitarle un grano a un reloj de arena va a durar menos tiempo

pero repito, es opinion personal

#129   #31 #45 #50 #93 Mucho separar presentación del contenido, pero no os habéis sentado a darle vueltas dos minutos, porque si lo hubieseis hecho, habríais descubierto que es IMPOSIBLE separar la presentación del contenido, ya que todo forma un conjunto.

¿Acaso no tenéis que meter marcadores entre medias del contenido para hacer la presentación? ¿Que creéis que es si no un < b >, o un < span > o un < div >? ¿Contenido? JAJAJA!

Contenido: El microprocesador (o simplemente procesador) es el circuito integrado central y más complejo de un sistema informático; a modo de ilustración, se le suele asociar por analogía como el «cerebro» de un computador. Es un circuito integrado constituido por millones de componentes electrónicos. Constituye la unidad central de procesamiento (CPU) de un PC catalogado como microcomputador.

Presentación: El microprocesador (o simplemente procesador) es el circuito integrado central y más complejo de un sistema informático; a modo de ilustración, se le suele asociar por analogía como el «cerebro» de un computador. Es un circuito integrado constituido por millones de componentes electrónicos. Constituye la unidad central de procesamiento (CPU) de un PC catalogado como microcomputador.

¿Como se pasa de contenido a presentación? Pues juntándolo todo así: El < i >microprocesador < /i >(o simplemente < i >procesador< /i >) es el circuito integrado central y más complejo de un sistema informático; a modo de ilustración, se le suele asociar por analogía como el < b >«cerebro»< /b > de un computador. Es un circuito integrado constituido por < i >millones de componentes electrónicos< /i >. Constituye la < b >< i >unidad central de procesamiento< /i >< /b > (CPU) de un PC catalogado como < b >microcomputador< /b >.

Bien, una vez que hemos descubierto que no se puede separar presentación de contenido, joder, haz una marcas (hypertext markup language) simples, sencillas, lógicas. Si ya tienes < b > para bold, ¿a que coño viene em, strong, o todas las demás complicaciones? Pon una marca sencilla como < b > y luego si quieres, en un fichero aparte (el CSS o equivalente) indica que b se va a pintar con letra de tamaño tal, fuente cual, color pascual y todo lo que haga falta. Pero usa < b >, no < span style="font-weight: bold;" >, que por si no lo estais notando, incluye la presentación (font-weight: bold) con la información: No se pueden separar.

El problema es que muchos porque os dediquéis a ello ya creéis que sois la reostia, pero no habéis hecho más que memorizar y aplicar lo que os han enseñado, sin pensamiento crítico, sin dudar, sin pensar si eso es mejorable o no, sin nada, solo repetir como loros. Bien por vosotros, os ahorrareis muchos disgustos en vuestras vidas.

#130   #120 exacto, el problema es que la gente se cree que sabe y en realidad no sabe nada (como podemos ver en este mismo meneo) o subestiman al lenguaje y no se toman las molestias de aprenderlo bien. Como te dije arriba, si alguien pone class="red" está haciendo mal, pero la solución no es poner un estilo inline. Sobre ejemplo de las tablas, también es cierto, por eso dije que si el código termina siendo una sopa de divs, la culpa es del maquetador.

#131   #129 pero erre que erre... NADIE está diciendo de poner <span style="font-weight: bold;"> no es tan complicado de entender...

y en tu ejemplo... porqué quieres poner esas palabras en negrita? porque si? NO. Las quieres poner porque quieres transmitir una fuerza especial, quieres recalcarlas. ESO ES CONTENIDO, NO PRESENTACIÓN.

En fin, tu pon <blink>gifs animados</blink> igual si quieres.

#132   #95 ¿Te has espertado con el pie izquierdo? Si quitan algo de la especificación, los navegadores pueden hacer dos cosas, pasar de ello o mantener lo obsoleto. No creo que hablar de ello sea un crimen. Tomate la pastilla. No me vengas precisamente en este asunto con "saber de que se habla". Cojones con la juventud.

#133   #116 find -name '*.html' -exec sed -i 's/<span style='color:red'>/<span style='color:green'>/g' {} \;

Ejemplos de código que te vas a encontrar seguro donde eso no funcionaría:

<span style="color:red">
<span style='color: red'>
<span
style='color:red'>
<span style='color:red'>
<span style='color: red;'>
<span style='color:red;border:none'>
<span style='color:red' class='foo'>

Por no hablar del contenido dinámico que venga de BBDD.

#134   #107 No hablo de webcams ni hardware que puede llevar cualquier PC me refiero por ejemplo a lectores de tarjetas, lectores RFID, lectores NFC, hardware que no es comun.

#135   #133 Era un ejemplo rápido, pero todo eso se soluciona con expresiones regulares en un momento. Claro, que la gente antes sabía programar y ahora hacen copypaste.

#136   #100 No sé si hay estadísticas, pero me da que menéame está plagado de gente que programa, desde juniors hasta analistas funcionales...

#137   #135 Moraleja, pásate cinco minutos maquetando y dos días buscando expresiones regulares para solventar problemas . No será mejor pasarse 30 minutos maquetando?

#138   #127 Vale, entonces hazme una página web con tablas y después otra con divs, a ver cuál obtiene mejor pageranking y mayor visibilidad.

#139   #120 pero el hecho de que te hayas topado con gente que no sabe maquetar no significa nada. Esos que dices, ponen nombres malos a lsa clases, y esos que dices no teinen puta idéa de qué es una tabla, son malos maquetadores, pero eso no exculpa a quién utiliza tablas para maquetar.

#140   #129 a ver cómo te lo explico. Hace años yo estaba en la fase en la que estas tu ahora, pero tras mucha experiencia y pensar con pensamiento crítico, y pensando en por qué las cosas son como son, entendí por qué se separan. Te lo repito, ten un poco de humildad, y lee con mente abierta las especificaciones HTML.
Con el ejemplo que has puesto, te puedo decir que, sencillamente, no comprendes lo que es el contenido y la forma, no puedes separarlo por que no comprendes su diferencia.

#141   #132 para empezar, no conoces mi edad ni mi currículo, pero obviamente es mejor que el tuyo.
- La especificación HTML4 no cambia ni se destruye, todo esto que se habla es para especificación HTML5, son cambios que no van a alterar páginas antiguas.
- Los navegadores van a mantener la retocompatibilidad con HTML4 durante muchísimos años, sencillamente por que no pueden obligar a rehacer toda la web. No tienen que ser compatibles con una sola especificación. De hecho los actuales son compatibles con las versiones antiguas de HTML y CSS.
- En el DOCTYPE indicas la especficación a utilizar. No hay ningún tipo de problema de compatibilidad, por que el navegador gracias a ello sabe qué reglas utilizar.

#142   #94, #106, #111 y #113, gracias por aclararme lo de que seguirá funcionando, pero tal como lo pone en la noticia parecía que dejarían de funcionar. A mi no me importa adaptarme a las cosas nuevas que haga (de hecho lo que he hecho recientemente ha sido con su css, muchos divs, ninguna tabla, etc), pero ponerme a revisar lo que ya tengo me ponía de mala leche!!!

#143   #31 #141 Joder, cómo andan los egos por aquí

#129 y las pajas mentales

Y los que solo critican, como el idiota de #143

#144   #137 Como digo, la gente antes sabía programar. La expresión regular que soluciona ese problema no se "busca en dos días", se crea en 2 minutos
Pero es lo que digo, la gente antes sabía hacer las cosas, ahora las copian

#145   #142 html debe de ser de los lenguajes más retrocompatibles que existen, imagina que con navegadores del 2012 podemos seguir accediendo al primer documento html creado: www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html
a ver si pueden decir lo mismo los usuarios de Word

#143 me haz hecho sonreír

#146   #144 te digo un secreto... los maquetadores no somos programadores.

Ah... y los programadores (y los diseñadores) tampoco son maquetadores.

#147   #141 Pues pon en tu CV que asumes que HTML 1.0 seguirá de por vida presente y así lo mejoras aún más hasta que te jubiles. Pon también que tienes gran habilidad social.

#148   #146 Pues maquetad con el FrontPage y no pretendais usar sistemas basados en lenguajes como si fuerais programadores.

#149   #148 oh claro, porque html es un lenguaje de programación

#150   #138 Aceptaría el reto si no fuese una pérdida de tiempo
En el posicionamiento hay factores que cuentan mucho, como el linking externo, otros que cuentan menos, como el uso correcto de ciertos tags, y otros que no cuentan nada, que son esos trucos que se inventan los gurús del SEO que no tienen ningún sentido.
He aquí una de mis páginas preferidas , muy a pesar de que usa tablas: eztv.it/. Su estructura es clara, el uso de tablas yo creo que es correcto, aun habiendo diseños alternativos. Lo que me parecería una tontería es implementar ese diseño de tablas exactamente, usando divs en lugar de tablas. Luego vienes tú y dices que, en el año 2012, el bot de google va a tener problemas para parsear esa página, porque tiene tablas, y le va a poner menos pagerank. ¿Por qué podría ser eso? ¿Porque los sres. de google no han tenido tiempo de hacer un bot que entienda ese contenido? ¿O quizás si que pensaron en ello en el diseño, y decidieron otorgar menos peso a los datos estructurados en tablas por alguna razón que desconozco?

#151   Se suele suponer que en Menéame hay gente con ciertos conocimientos en estos temas pero la realidad es que es tristísimo leer lo que ponen algunos.

#152   A ver, los talibanes de la optimización, ¿qué dicen de esto?

Por un lado: el html generado desde PHP o lo que sea, dentro de matete de código importante:

<p id="user">Hola <strong class="blue">Usuario!</span></p>
...
<p>Es importante <span class="blue">destacar</span> que.... </p>

Y por otro lado lado, un simple css:

.blue{ color: #00F;}

Casi terminas el proyecto al i...a de tu cliente se le ocurre que ahora sería mejor mostrar los textos destacados en rojo. ¿cómo lo resuelves?

.blue { color: #F00;}

Punto... no tienes que tocar un más que un simple archivo de texto sin meterte en la lógica de la aplicación. Ahora bien, ¿tu cliente quiere que el nombre de usuario aparezca no en negrita sinó subrayado y en verde? Oks:

#user strong.blue{
font-weight: normal;
color: #0F0;
text-decoration: underline;
}

Incluso, los cambios en el CSS podría hacerlos alguien como un diseñador que no quiera complicarse con código. De hecho, si siguen jodiendo con esto del <.b.> por el <.strong.>, entiendan algo bastante simple que hace también a la optimización: el contenido html muchas veces generado dinámica se sirve independientemente de los estilos, en archivos separados que pueden ser cacheados por los browsers. Entonces, el servidor estaría solamente "ocupado" en generar y enviar contenido, y no estar mandando miles de veces código que tengan que ver con la presentación.

Y para cerrar:

- HTML ni HTML5 ni CSS son lenguajes de progamación, esto creo que ni se debería discutir acá.
- Que muchos no sepan separar contenido de presentación, no significa que no se pueda o sea imposible.
- HTML5 no creo que sea la salvación ni alivia el trabajo de maquetar. Provee nuevas etiquetas para marcar semánticamente el contenido de forma más clara, y unifica algunas cosas, y saca del medio algunas etiquetas redundantes.
- Por último, debe prevalecer el sentido común. Si tengo un site en producción, y por alguna cuestión urgente tengo que sacar un logo o destacar un texto, nada me impide que use un <span style="bla bla bla">texto</span> enh vez de meterme a buscar hojas de estilos. Lo mismo si tengo que desarrollar una simple página para poner de portada de algo.

Saludos!

#153   #152 go to mi comentario #42, tener una clase .blue es una MUY MALA práctica. Si justamente le damos importancia a la semántica, terminar con un .blue{color:red} es un poco contradictorio (y bipolar), no te parece?

y con esto concluyo mi participación en este tema.
La conclusión que saco de todo este meneo es agridulce: en el mercado español no voy a tener mucha competencia por bastante tiempo porque vaya nivelazo el de la mayoría de los meneantes

#154   Madremia, no dejo de sorprenderme con la gente. Si no somos capaces de ponernos de acuerdo en cosas que me parecen tan obvias!!!!

#155   #153 estimado, solo fue a modo de ejemplo

#156   Me parto con algunos los puristas que no pueden programar y por ello se centran en criticar las tablas.

#157   #53 #45 Nunca he usado cofee...
Yo cada vez que me entra sueño uso coffee

#158   #101 No digo que sea malo, no se trata de eso. En su momento html se hizo para cumplir unos requisitos que han ido cambiado y que se han ido solventando como se ha podido, añadiendo CSS, con javascript, con applets, con flash, con php. En este caso quizás en su momento tuvo sentido tener etiquetas de formato, ahora se va solventando desaconsejando su uso en favor de etiquetas más semánticas.

Simplemente digo que sería interesante que saldría si se pudiera replantear desde cero un lenguaje web ajustado a los planteamientos actuales.

#159   Claro está que con #43 me refiero a #6. #31 lo explica bien.