Elementos que desaparecerán en breve de HTML

Si te dedicas al mundo del desarrollo web, sabrás que con cada versión nueva de HTML, al igual que ocurren en otras tecnologías, hay elementos que aparecen y otros que desaparecen o se marcan como deprecated para avisar de que deseparecerán en breve. Con el tránsito definitivo a HTML5 del que tantísimo se lleva hablando, algunos elementos dejarán de existir. Aquí os traigo un listado de ellos, cuál era su función y cómo debemos sustituir su funcionalidad.

[#6 Desactivado]

Yo lo que no entiendo es que tienen en la cabeza los sabiondos del HTML. Hemos pasado de algo tan simple como poner unas negritas con:

< b >cosa en negrita< / b >

que es sencillo, simple, eficaz y que el navegador interpreta a toda ostia, a barrabasadas como:

cosa en negrita

para hacer exactamente lo mismo.

Keep It Simple Stupid!

[#8 Desactivado]

#6 De hecho desde hace un tiempo 'los expertos' consideran que no hay que usar < b > sino < strong >. Luego esos mismos lumbreras argumentan por otro lado que hay que hacer que el peso de las páginas sea mínimo.

[#15 Pijus_Magnificus]

#14 La pregunta debería ser qué han de hacer los responsables de esos navegadores para adaptarse a los nuevos estándares. Un navegador de solo texto puede estar más o menos bien para determinadas circunstancias, pero si no se adapta a un entorno en constante desarrollo como es la WWW, mal andamos.

Y sí, yo abogo por las hojas de estilos sencillamente porque hacen más claro el documento, más limpio, y te permite separar la parte que contiene información sobre la apariencia y la parte que contiene el contenido. Además, que yo sepa un fichero CSS se lee todo de una tacada, el resto del trabajo, lo hace el navegador.

#8 Hoy en día no creo que unos bytes de diferencia haga muy pesada una página web cuando nos solemos descargar terabytes de datos al mes en materia de películas, videojuegos y música sin un mínimo esfuerzo. Si estuviéramos en la década de los 80 con esas memorias y discos duros tan limitados lo podría entender.

[#16 Nenillo]

#15 El HTML es lo de menos en el proceso de carga. Hoy en día lo que más preocupa es el proceso de la página en el servidor, ya que la mayoría de páginas tienen una programación más compleja que la simple función de servidor un fichero HTML. Después está el contenido multimedia, luego las librerías javascript, el css y por último el HTML.

[#17 Pijus_Magnificus]

#16 No he dicho lo contrario a ti, y de hecho aquí se está hablando de HTML, no de ASP, PHP, JSP, etc..

[#18 Desactivado]

#15 Eso es muy relativo, porque no es ya el < b > concretamente, sino la forma de pensar en sí misma extendida a otras etiquetas html o css. Multiplica esos bytes o incluso Kbytes, según el caso, por cientos de millones de páginas transmitiéndose en todo el mundo cada día y la cantidad ya no es tan pequeña, además de forma innecesaria, porque una imagen en un archivo más grande implica mayor calidad, pero un < strong > en lugar de un < b > o el ejemplo que indicaba #6 no ofrece ninguna mejora a la hora de mostrar una página en un navegador.

[#19 Pijus_Magnificus]

#18 Si miramos en todo el mundo normal que sea mucho. Es como si me pongo yo ahora a decir que cada 3 segundos muere una persona a lo largo de todo el mundo. No es que haya una pandemia, sino simple estadística. Pero a efectos particulares o de un servidor determinados, esos bytes de más no son ni mucho menos una carga excesiva y ayudan a hacer más comprensible el código desde un punto de vista conceptual. Para mi un < center > puede querer decir que centre cualquier cosa que tenga dentro, con todo lo arbitrario que ello supone para según qué navegadores y qué elementos contenga, mientras que un text-align: center deja bien claro que lo que se está centrando es el texto. Y lo mismo para < strong > en lugar de < b >, se entiende mucho mejor desde un punto de vista semántico lo primero, es mucho más conciso, aunque sea más coñazo de escribir, y como bien ha comentado alguien antes que yo, hace más referencia al concepto de énfasis en el texto que a la negrita misma.

Yo sigo opinando que en la segunda década del siglo XXI, con la tecnología tan avanzada que tenemos en materia de ordenadores, y por ende, de servidores de Internet, quejarse de tener que escribir unas cuantas letras más o de tener que escribir una hoja de estilos por separado en vez de usar y otras etiquetas de los inicios de Internet, me parece cuanto menos por pereza e inmovilismo.

[#20 Desactivado]

#19 Pues esa opinión va en contra de una de las premisas básicas de cualquier sistema informático: la optimización, según tú habría que sacrificarlo en pos de la comodidad del programador o del diseñador web. Es como decir que los procesadores en pleno siglo XXI son muy rápidos, así que para qué molestarte en optimizar código o para qué comprimir ficheros antes de transmitirlos vía Internet si hay ancho de banda de sobra.

Imagino que relacionar 'escribir poco' con pereza es cuestión de desconocimiento, lee algo sobre lenguaje ensamblador, precisamente escribir menos a veces requiere más esfuerzo en contra de lo que pueda parecerte.

Aparte de eso, como ya dije en #18 no son 'unas cuantas letras más' cuando las multiplicas por el torrente de webs que circulan diariamente en Internet.

[#21 oxelo]

#20 Supongo que como adalid de la optimización escribes tus propios CGI en ensamblador.

Pues claro que se mira por la comodidad del programador, ¿si no para que cojones se creó el concepto de OOP? Cada día usamos más y más capas de abstración que permiten tiempos más cortos de desarrollo y menor coste de mantenimiento a expensas de usar cantidades obscenas de recursos, la separación conceptual entre contenido/estilo/estructura en la web no iba a ser diferente.

[#22 Desactivado]

#21 "Supongo que como adalid de la optimización". "Pues claro que se mira por la comodidad del programador".

Lógicamente, hay programadores y "programadores", pero pasa en todas las profesiones. Me hicieron hace poco un cambio de tuberías en casa hace poco barato barato y en tiempo récord. Los tuve que llamar a las dos semanas porque salía agua por todas partes. Es la diferencia entre optimización y chapuza, pero donde sí te doy la razón es en que al fontanero le resultó muy cómodo el trabajo.

[#27 Pijus_Magnificus]

#20 Yo no he dicho que no se deba optimizar el codigo fuente de una aplicacion, ni siquiera me he puesto a hablar de lenguaje ensamblador, porque no tiene nada que ver un lenguaje de marcas con un lenguaje de alto nivel, y mucho menos con uno de bajo nivel, pero tratandose de lenguaje HTML, llamar a eso optimizacion teniendo en la mano las razones que ya he mencionado me parece cuanto menos exagerado.

Es como decir que la lluvia sobre un punto de un gran lago sube mucho el nivel del agua cuando muy cerca hay un par de cascadas echando litros y litros de agua por segundo. Pues las gotas de lluvia son esos bytes de mas que os parecen fruto de la no optimizacion pero que a efectos globales de carga no son un lastre demasiado grande, mientras que las cascadas son todo el torrente de informacion que producen a diario determinados servicios como el P2P o el portal de videos YouTube.

Paso de seguir comentando, porque yo aqui hablo de unas letras de mas en un lenguaje de marcas y los demas meteis por medio lenguajes de programacion de alto nivel y lenguaje ensablador. Y perdon si faltan acentos, tengo el ordenador de sobremesa enfermo y estoy en un MiniXP intentando reparar el disco duro con el teclado en ingles.

[#46 Desactivado]

#27 "ni siquiera me he puesto a hablar de lenguaje ensamblador, porque no tiene nada que ver un lenguaje de marcas". Sí lo has hecho, porque has relacionado erróneamente el "escribir menos" con flojera, algo que claramente es falso. Más bien es al revés, el programador que prima su comodidad a la hora de escribir código frente a la optimización es el vago.

Lo de las gotas de agua es un ejemplo muy pobre, porque no es lo mismo un chubasco con cuatro gotas que una tormenta tropical, por desgracia muchos piensan así y es un lastre.

[#65 Pijus_Magnificus]

#46 "Sí lo has hecho, porque has relacionado erróneamente el "escribir menos" con flojera, algo que claramente es falso."

No lo he relacionado erróneamente, porque para mí, quejarse de eso mismo, en lenguaje HTML, te lo pongo en negrita para que lo veas bien, es sinónimo de no querer molestarse en escribir unas letras más. El que ha metido lo de la optimización y el lenguaje ensamblador de por medio has sido tú en aras de que te demos la razón, como si el HTML fuese un lenguaje de programación.

Luego también he de decir que tú también has relacionado erróneamente ese comentario con la que tú crees que es mi opinión sobre la optimización de código, que si bien es muy similar a la tuya, pese a que aquí no se discute sobre ello, pareces afanarte en que de la sensación de que he expresado algo que realmente no he escrito y que es frontalmente contrario a lo que tú piensas, cosa que no es en absoluto.

Y bueno, ya con respecto a lo de las analogías no pienso decir nada, creo que todos sabemos que no me refiero a una tormenta tropical, ni a un torrente ni al monzón, pero ni que tú fueses experto en hacer analogías. Si entiendes lo que quieres y respondes lo que te da la gana en base a una idea equívoca de lo que el otro ha escrito para intentar tener siempre la última palabra no es culpa mía.

[#86 Desactivado]

#65 "... porque para mí, quejarse de eso mismo, en lenguaje HTML ...". Está claro, se trata de una opinión tuya personal, pero equivocada, porque aunque no se considere html como un lenguaje de programación, el consumo de recursos está ahí. Sigues empeñándote en supeditar tu comodidad por encima de la optimización de recursos considerando que estos son ilimitados y siempre van a haber de sobra, lo cuál parece cuanto menos pereza e inmovilismo. Sea en html, ensamblador, en la compresión de imágenes, etc. la filosofía debe ser la misma y pensar en el sistema por encima de que al programador le resulte más fácil el trabajo.

#69 Ya comenté en #18 que esa forma de pensar de 'como es poco no importa' no es buena.

[#124 Pijus_Magnificus]

#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.

[#128 Desactivado]

#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

[#69 Desactivado]

#20 optimizar el texto de una web es algo infinitesimal, teniendo en cuenta que cualquier imagen, aplicacion, o publicidad es mucho mas grande que todo el texto, salvo que tengas una web sin imagenes modo texto

el codigo si esta pensado para optimizarse, pero no para el navegador e internet, que repito uno o dos kb es cero al lado la imagen del logo y los botoncitos de redes sociales, sino que esta optimizado para su mantenimiento, lo cual es logico, porque una web tiene contenido que cambia y necesita actualizarse

[#102 Guarrior]

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

[#13 Pijus_Magnificus]

#6 ¿Y qué me dices de < strong >?

#1 Pues pones un style="text-align:center" y va que se las pela. De hecho yo lo he usado más de una vez para cumplir XHTML 1.1 estricto. A mí tampoco me parece para llevarse las manos a la cabeza.

[#14 Saleroso]

#13 Que hacemos con los navegadores que no soportan style como Lynx yo no soy muy partidario de la hoja de estilos, al final son llamadas y llamadas, cuando se puede leer todo de una tacada, pero bueno cada uno tiene un criterio.

[#33 angelitoMagno]

#14 Precisamente en un navegador solo texto como Lynx obtendrá mejores resultados con páginas que solo tengan contenido en el HTML dejando la presentación visual para el CSS.

[#97 Guarrior]

#13 Pero normalmente tienes (o debes tener) una hoja de estilos genérica para tu web, y quizá alguna para secciones especiales, de manera que solo la descargas la primera vez que visitas una de las páginas de tu web, en las demás páginas y en las demás visitas, el usuario ya tiene cacheado el CSS, y le vas a hacer descargar mucha menos información repetida.
La gente que piensa estas cosas lo hace durante mucho tiempo y son gente muy válida, no os creais más inteligentes que ellos sin ni siquiera el preocuparos en por qué hacen las cosas.

[#123 Pijus_Magnificus]

#97 ¿En qué momento he dicho yo que se deban escribir todos los estilos en la propia etiqueta HTML? Simplemente di una equivalencia a , 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.

[#23 stygyan]

#6 tiene su sentido. Todo viene del querer separar presentación de contenido: quiere decir, "pon esto en negrita". "quiero que esto se resalte"; puedes resaltar con negrita, subrayados, colores, o incluso un cambio de letra si te apetece.

[#24 ckool]

#6 basta con una regla en el css

strong

usemos cada cosa para lo que toca, html es estructura y css estilos

[#40 Desactivado]

#6 #24

[#96 Desactivado]

#40 Te has dejado el punto y coma después del "font-weight: normal;"

[#29 Desactivado]

#6 Si es solo para ponerlo en una parte (SOLO UNA) del código, pase que sea mejor poner el < b > de bold, pero ahora como tengas que repetir esto en miles de paginas en tu web... multiplica...

en todo caso odio el CSS es complicadisimo cambiar atributos en pequeñas partes del código, antes era mucho mas facil de cambiar todo.

[#30 xenko]

#6 además, ahora proponen meter casi todo lo relacionado con el estilo en el css.

No tengo mucha experiencia en desarrollo web, pero creo recordar que el css era la cosa menos estándar que había en el mundo. Cualquier arreglo de estilo que ponías en el css se veía de forma distinta en Firefox y en el Explorer.

[#32 angelitoMagno]

#30 Cualquier arreglo de estilo que ponías en el css se veía de forma distinta en Firefox y en el Explorer.

En efecto, tienes poca experiencia. Eso sería hace años, ahora mientras uses el DOCTYPE correcto, la visualización es similar. Es posible que en webs con estilos muy complejos tengas que poner un par de estilos concretos para IE, pero eso, un par de estilos, no para cualquier arreglo.

Lo que pasa es que aún hay mucho manual y curso de HTML/CSS obsoleto, que hablan de estilos para el Netscape, para el IE4, para cosas que, en fin, nadie usa desde hace lustros.

[#53 scalvo]

#32 Todavía hay que tener en cuenta a IE6.... para dolor de todo el que alguna vez haya usado CSS...
#45 Nunca he usado cofee... pero javascript es un lenguaje divertidísimo de programar!! El coñazo es el DOM y los distintos navegadores...

[#55 EGraf]

#53 yo ya no doy soporte a ie6 salvo que sea un requisito explícito del proyecto, y de todas formas, salvo algunos bugs "supermágicos" que de vez en cuando suceden, con la ayuda de algún js como IE7.js o css3Pie, comentarios condicionales y un buen dominio teórico del hasLayout, se solucionan casi todos los problemas.

[#56 Desactivado]

#53 Perdón por el negativo. He escuchado que javascript es divertidísimo y me he ofuscado

[#62 scalvo]

#56 No problem pero... javascript es divertidísimo!! No sé si lo programas así, porque no enseñan el lenguaje así, es el lenguaje "peor" enseñado.

Pero en los lenguajes que conozco no hay ninguno que tenga la versatilidad de javascript. Tiene fallos, claro, te recomiendo las charlas de Douglas Crockford sobre el lenguaje. Pero tiene aciertos fantásticos... las funciones lambda, el prototype (quién necesita clases teniendo prototype! el prototype el acierto!)...

#57 Me encanta javascript... me fallan el DOM y los navegadores, por muchos frameworks que haya... Ahora quiero aprender extJS... tiene muy buena pinta! Además ahora han creado node.js para ejecutarlo en servidor, GNOME3 permite programar widgets de escritorio en puro javascript, hay intérpretes para consola... Creo que será uno de los lenguajes más importantes los próximos años.

Te puedo decir varias empresas de las más grandes de España que exigen Internet Explorer 6...

[#57 angelitoMagno]

#53 El coñazo es el DOM y los distintos navegadores
Usa JQuery y te quitas el 98% de los problemas de Javascript

Por cierto, llevo años trabajando en estos temas y el IE6 es cada vez más cosa del pasado. En serio, hace años que nadie me dice el terrible, 'Oye, esto no va con IE6'. Y he trabajado con empresas grandes, empresas chicas, particulares, administraciones públicas, etc.

Del IE7 'parriba' los problemas de compatibilidad se reducen bastante.

[#157 zorion]

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

[#47 Desactivado]

#30 No. El CSS es la cosa más estándar que hay en el mundo, siempre lo ha sido y siempre lo será. El estándar de cómo se tienen que escribir las cosas es CSS. Lo que no es estándar es la interpretación del mismo que los navegadores (IExplorer, principalmente) han hecho de él. Pero eso, como tantas otras cosas en el mundo de la confrutación (LDAP, POSIX, OpenDocument...) no es culpa del estándar, es culpa de Microsoft el sistema que lo implementa

[#31 EGraf]

muchos comentando.... y me doy cuenta que no tienen NI IDEA de HTML/CSS.

Me gano la vida con estos 2 lenguajes, y puedo asegurar que html5 está genial. Los elementos que desaparecen, deberían de haberlo hecho hace años y de todas formas ningún maquetador profesional los usa desde hace tiempo.

#1 margin:auto para elementos en bloque, text-align:center para elementos en línea.. tan complicado no es, no?
#3 ¿applet? ¿En serio? ¿alguien todavía usa applet? Es como reclamar por marquee, jajaja
#6 suerte que tenemos a los sabiondos del HTML y no te tenemos a ti, porque... madre mía. Para empezar, para enfatizar algo existe strong. Por otro lado, todo el html gira en torno a la SEMÁNTICA, y eso significa SEPARAR LA PRESENTACIÓN DEL CONTENIDO. Y por último, html5 realmente simplifica las cosas... vistes el doctype?


sobre los comentarios sobre el "peso de la página" mejor ni entrar...

[#48 nicorl]

Yo he hecho el mismo curso de HTML5 que #31, ni idea hoyganes.

[#61 iRiku87]

Iba a comentar mas o menos lo mismo que #31. Evidentemente que ya no se usa y mierdas de esas, hay que separar presentación de contenido, para eso existe CSS. ¿De verdad cuesta tanto hacer y en CSS meter .centered ? Semanticamente es mas correcto también para los buscadores, usar cada elemento HTML para lo que es.

[#63 Desactivado]

#61 Si tienes un blog, lo malo es que ese elemento obviamente no será respetado en el lector y la presentación en él queda fea. Por eso no lo uso, aunque en otros casos por supuesto no tiene ninguna otra justificación.

[#68 Desactivado]

#61 antes:
...lo que sea todo centrado...

ahora:
.centered
...lo que sea todo centrado...

o bien:
...lo que sea todo centrado...

En el caso de center, no gana mucho, de hecho ahora es bastante más largo, pero todo sea por estandarizar todo a css, y no tener las cosas duplicadas.

- Separar completamente la presentación del contenido no es imprescindible. Hay cosas que en una página no se van a mover. Ya veremos si quitan algún día las tablas.

[#70 iRiku87]

#68 No las van a quitar, ni deberían. Las tablas son para lo que son: para mostrar tablas, no para maquetar una web sin comerte la cabeza con las posiciones de los divs. Y en ningún momento digo que ahora sea mas corto, pero si que es mas correcto semanticamente hablando. HTML -> contenido, CSS -> presentación. No es tan difícil el separarlos bien.

[#71 Pingocho]

#70 "No las van a quitar"

Ya verás como las reemplazan con algo que te obligue a posicionar celda por celda, con el argumento de que es más reusable

[#75 Desactivado]

#71 Eso ya lo puedes hacer con CSS2 si te apetece. Unos cuantos divs con display table, table-row, table-cell, ..., y ya tienes tablas sin usar table, tr, td, ... Así que vete preparando

[#72 anacronico]

#7 si quieres cambiar el formato usa css, si quieres estructurar html, ejemplos:

1 - quiero formatear, que debo usar :
[a] - una estructura
[b] - un elemento de formato

la respuesta correcta es b porque se da formato con los elementos de formato no con las estructuras, dejemos de usar cosas para lo que no fueron pensadas, usemos bien las herramientas y listo.

( por lo menos es lo que entendí de los cambios )


#68 las tablas deben usarse para lo que las tablas fueron pensadas y diseñadas, para nada mas o menos.

[#82 grails]

#68 la propiedad margin no funciona en los elementos inline como son los span, para poder utilizarlo debes agregar la propiedad display: block sinó no funcionará .

Y para los elementos de bloque, la propiedad "margin: 0px auto" funciona siempre y cuando tenga un width y el doctype sea transitional o strict (esto ultimo para nuestro fantastico amigo... IE)

[#81 Desactivado]

#31, pues resulta que puede ser que estas cosas estén obsoletas, pero hay un detalle, es que existen muchas páginas antiguas que no se han cambiado en años o que han ido cambiando en parte pero buen porcentaje del código está formado por etiquetas de estas que pone que pronto dejarán de funcionar (no sé cuándo será pronto).

Y por ponerte un ejemplo te pongo una página: http://www.rubikaz.com que de hecho es mi página, que hice hace ya casi 10 años y que recibe unas 4000, 5000 visitas diarias.

Pues bien, dicha página está plagada de etiquetas < center > o etiquetas < b >. Es más, también tengo muchos applet metidos, algunos que metí hace casi 10 años. Y applets que son muy importantes para la página, no cosillas puntuales.

Pues bien, ciertamente que no soy profesional y he ido variando la página en cuanto he ido aprendiendo algunas cosillas, un poquito por aquí, un poquillo por allá, y vamos, es una página a la que le he cogido bastante cariño. Y ahora resulta que tengo que revisar todo el código, que es bastante, para eliminar etiquetas que van a dejar de funcionar.

Que sí, que no soy profesional ni nada, que no tendré ni idea, pero es que veo una noticia así y me acojono de pensar lo que me va a tocar arreglar ahora. Porque sí que sé hacer muchos de los cambios, sé algo de css (tengo páginas más actuales con todo con css y tal), pero puf..., encima hay otras cosas que no tengo ni idea de cómo hacer como por ejemplo lo de cambiar applet por object. Sé que no vale con cambiar esas palabras, hacen falta más cambios ya que no hace mucho le eché un vistazo a como iba.

Me alegro por ti porque haces todo esto muy bien y estos cambios no te van a afectar, pero a mucha gente que no es tan profesional y que tenga páginas antiguas que no ha actualizado, pues le va a tocar echar unas horas y calentarse la cabeza por estos cambios...

Y me pregunto, ¿tan importante es eliminar esas etiquetas? Lo sé, soy un analfabeto en estos temas así que no os riáis de mi si esta pregunta es estúpida.

[#85 pizte]

1º ¿Alguien usaba aún esas etiquetas?
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
3º Separar contenido de estilo, norma obligatoria, por puro sentido común de manutención, cambiar una línea versus cambiar 100 páginas HTML.
4º ¿qué pasa aquí, como maquetadores/programadores web no tenemos mejor cosa que hacer que tirarnos piedras por auténticas soplapolleces? ¡Reclamemos "marquee"! ¡Reclamemos "blink"! ¡Son esenciales para matar a la sociedad! ¡Condones sí! ¡Iglesia no!

Guardémonos las fuerzas para picar buen código y dejémonos de chorradas.

#81 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). Respecto a lo de la gente que no es tan profesional... es obligación de cualquier buen programador/maquetador mantener el código al día

[#89 Desactivado]

#85, pero lo que puede suponer a los programas estos yo diría que es mucho menor que lo que le supondrá a la gente arreglar todas las páginas "desfasadas". Y no solo arreglarlas sino que algunas páginas no se arreglarán y dejarán de funcionar correctamente solo porque para rederizarla el navegador se quería ahorrar 3 milésimas de segundo (por decir un tiempo).

Y sobre: es obligación de cualquier buen programador/maquetador mantener el código al día

En mi caso no es que no sea buen programador/maquetador, es que no soy programador ni maquetador, aprendí en su momento 4 cosas básicas e hice lo que hice, con el tiempo he aprendido cosillas sueltas pero no estoy al tanto de las actualizaciones de los estándares web.

Y respecto a las pregunta que haces...

A la 1, pues evidentemente sí que hay gente que las usa, o mejor dicho, muchísimas páginas que las contiene.

A la 3, ¿y la etiqueta applet? ¿Qué se gana con el cambio a object? Creo que con ese cambio no se separa estilo de contenido (al menos en lo que me afecta a mi).

[#94 Guarrior]

#89 No es necesario arreglar nada, si tienes una página en HTML4 pues la dejas tal cómo está. Los navegadores van a seguir leyendo HTML4 durante muchos años.

[#106 jynus]

#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.

[#142 Desactivado]

#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!!!

[#111 Gargos]

#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?

[#115 inconnito]

#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...

[#113 EGraf]

#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: https://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"

[#84 Desactivado]

#31 Dime una forma de acceder al hardware del ordenador cliente sin un applet y no te estoy hablando de hacer un virus ni nada. O usas un applet (multiplataforma) o usas un ActiveX

[#87 pizte]

#84 Perdona por la incursión, pero en mi opinión, si necesitas acceder al hardware del cliente y no te llega con lo que el navegador provee, lo que necesitas no es una web, sino una aplicación nativa.

[#107 jynus]

#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),...

[#98 Guarrior]

#31 puf, menos mal, un comentario de alguien que sabe. me estaba volvindo loco de ver que todo el mundo hablaba sin saber. Joder, que yo también empecé autodidacta en mi casita, pero no me creía más listo que los diseñadores de HTML. Poca predisposición a aprender veo en los nuevos desarrolladores de páginas web.

[#126 estoyausente]

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

[#129 Desactivado]

#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.

[#143 ktzar]

#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

[#159 disecain]

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

[#36 Desactivado]

#6 pues yo la negrita la pongo con 'em', y me parece bastante lógico, ya que si alguna parte del texto necesita negrita, probablemente es porque hay que darle énfasis a dicha palabra, así pues la etiqueta tiene bastante sentido. Yo hago todo mi HTML basándome en el currículum de opera y me parece bastante simple que hace años cuando todo se llenaba de etiquetas de b, i y demás

[#37 Pijus_Magnificus]

#36 Que yo sepa lo que se pone entre las etiquetas < em > se parece más a una cursiva que a una negrita.

[#39 Desactivado]

#37 Tuve un lapsus el énfasis con negrita es el strong, toda la razón.

[#45 Desactivado]

#1, #6, etc. Creo que os equivocáis. La razón de que o "bold" no sean válidas es que mezclan contenido con presentación. El HTML debe contener sólo el contenido y la especificación de las secciones de la página, navegación, pie, etc.
El porqué es bien sencillo: organizar el trabajo, modularizar y reutilizar.
Otra cosa es que CSS sea un "lenguaje" bastante coñazo, especialmente si no usas cosas como Compass, SASS o LESS, pero está ahí para presentar el contenido y lo hace de maravilla.
Javascript también hace bien su trabajo pero es un coñazo de programar. Para eso tenemos coffee

[#50 scalvo]

#6 KISS My friend:

Separa contenido de presentación!!! Si lo mantienes unido lo estás "keeping difficult to maintain". Por tanto sí: todo el formato a las CSS.

Por no decir que ponerlo como lo has puesto es un error; se debe poner así:

Texto en negrita, cursiva, como no los de la gana o controlado mediante javascript

Dónde algo tan poco "rehusable" como una negrita nos puede servir para muchos otros formatos según dispositivos, usos, personalizaciones...

[#64 Desactivado]

#50 comentario tocapelotas.. "keepting it difficult to maintain"

y ese it va con b, strong, o font-de...

a mi personalmente el CSS me encanta.. soy aficionado y tengo varias webs, pero todo el HTML y CSS, y el php lo he ido aprendiendo yo solito a medida que necesitaba hacer cosas.. es muy gratificante.. sobre todo ver lo últi que resulta el css para descargar el html de estilos.

[#79 Karmakoma]

#64 Yo también aprendí CSS solito, para hacer mi web personal, y no es tan difícil. ¡Y soy muy de letras!

[#73 Desactivado]

#6: Diseña la página web para un HTML 4.0 y a correr.

PD: si es algo personal, es una buena solución (de hecho, yo no soy profesional y uso 4.0 para mis cosas personales). Si vas a cobrar dinero por eso (es decir, profesional), mejor usa CSS.

[#76 miguelpedregosa]

#73 si vas a cobrar dinero por algo que no sabs hacer mejor dejalo en manos de profesionales, así está el sector que da penita por culpa de tanto intruso que como no tiene ni puta idea pues cobra barato

[#93 Guarrior]

#6 Por favor, leeté un par de libros, uno sobre HTML5 y otro sobre CSS. Los "sabiondos" de HTML te aseguro que son mucho más inteligentes que tu y por eso stán donde están. Si en vez de despotricar por que cambian las reglas (que en este mundo es lo normal) la gente se dedicase a comprenderlas, la web sería un mundo mucho mejor construído.

Ahí se ve que no eres un buen desarrollador, de andar por casa quizá, pero no bueno.
Para empezar, para lo que tu quieres hacer te vale con poner , pero es que es más, ni siqueira te debes preocupar de que el texto salga en negrita, tu te debes preocupar de que el texto es importante, y como tal lo marcas con , y después, una vez hayas terminado de escribir el HTML, entras con CSS y decides si quieres que el texto importante sea negrita o sea verde.

Que a estas alturas de la historia haya que explicar todavía el por qué se separan información y estilo...

[#125 Nova6K0]

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

Lo mismo con . 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

[#10 Thau]

Esos tags se retiran porque son tags exclusivamente de estilo, que no dan información sobre la intención real del texto. < b > solo significa "negrita", mientras que < strong > incluye el concepto "énfasis". Son cosas útiles para la gente que utiliza lectores de texto para navegar, por ejemplo (ciegos o gente con visión parcial).

[#35 Desactivado]

#10 Para representar énfasis está < em > (nunca mejor dicho). El caso es que la gente no entiende que en el HTML no tiene que haber estilos.

[#34 angelitoMagno]

Leyendo los comentarios, creo que es fácil saber quien se dedica a esto de manera profesional y quién ha mirado un par de manuales alguna vez

[#42 EGraf]

#41
- por experiencia te digo que si el código termina siendo una sopa de divs, es culpa del maquetador y no del lenguaje
- "red" es un pésimo nombre para una clase, el día de mañana te da por cambiar el color y terminas con un .red
- muchísimas veces no hay ni necesidad de agregar elementos extra, por ejemplo si quieres seleccionar la primera letra de de una frase, lo puedes hacer con p:first-letter sin necesidad de spans ni nada de eso.

[#120 Desactivado]

#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 y display:cell-table y cosas de esas.

[#153 EGraf]

#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 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

[#5 matacca]

¿Alguien las seguía utilizando?

[#25 Desactivado]

Odio el HTML 'moderno'. Es la cosa más poco coherente que existe.
Así que quitan el , porque no tiene significado semántico, pero el sí lo tiene porque así separamos el contenido de la presentación. Pero claro, a la hora de maquetar un HTML, por muy bonito que sea el CSS, has de empezar a llenarlo todo de y , cuyo contenido semántico es... ninguno!!
Luego por otro lado, ves a programadores defendiendo esto mismo de separar el contenido de la presentación; como vean que haces: Hola, ponen el grito en el cielo. Luego ellos van y hacen Hola y se quedan tan panchos.
(Al le he puesto un punto porque si no me tacha el texto)

[#26 oxelo]

#25 Tu fijo que eres de los que crean archivos de 2500 lineas con PHP+HTML+JS todo mezclado y cuando se lo echan en cara dices que todo el mundo lo hace así y que es mejor.

[#41 Desactivado]

#26 Tu fijo que eres un listillo que se ha sentido identificado con lo de class='red' y aun así no entiendes que hay de malo en ello.
No te equivoques, creo que es muy importante separar contenido de presentación y lo hago en medida de lo posible; pero a)Cuando intentas ser un purista al final el código acaba resultando peor y b) El CSS nunca ha podido cumplir con dicho objetivo (a eso me refiero con div's y span's.

[#51 scalvo]

#25 Es que hay mucha diferencia entre definir una clase y poner una etiqueta de estilo!!

Por otro lado, div y span son contenedores; es decir, son herramientas "conceptuales": son los cajones del contenido. Cuando tú dices lo de abajo estás describiendo el documento! En HTML5 ya existen estos elementos pero versiones antiguas de los navegadores no los usan.

...

...

...

Algo como aquí datos sobre manzanas aquí datos sobre peras tiene una buena fuerza expresiva.

[#114 darccio]

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

... --> ...
... --> ... o ...
... --> ... .

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

El tema retrocompatibilidad es tan simple como usar html5shiv http://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!" http://www.alistapart.com/articles/semanticsinhtml5

[#103 Guarrior]

#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.

[#105 jynus]

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

[#112 aqeloutro]

#25 como vean que haces: Hola, ponen el grito en el cielo. Luego ellos van y hacen Hola 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.

[#78 centelleante]

Jajaja joder, la gente en menéame se llevará mucho tiempo navegando, pero parece que no saben cómo funciona la web.

Vamos a ver, como ya han comentado por ahí, el presente de la web, por el que se ha trabajado tantos años desde la W3C, es hacer una web semántica, en la que haya una separación a ser posible total entre el contenido y el diseño. Los más ancianos del lugar seguramente conozcan csszengarden, que hace bastantes años era el paradigma de la reutilización del contenido semántico para diferentes diseños (y donde yo mismo tengo un diseño oficial en línea).

La práctica totalidad de las etiquetas que se están dejando atrás son etiquetas que hacen referencia al diseño, a la vista, y eso es trabajo del CSS. Si tenemos un texto y queremos que algo sea importante, tal vez nosotros le demos esa importancia poniendo el fragmento en negrita, pero puede que un navegador para invidentes le dé la importancia incrementando el volumen del Text-To-Speech en ese fragmento. Por eso, no podemos indicar la importancia de un texto utilizando la etiqueta < b > (bold, negrita), sino < em > (emphasis) y < strong >.

Lo de que la gente siga usando , en 2012, es de puto juzgado de guardia joder. margin: 0 auto; o text-align: center.

[#80 Karmakoma]

#78 Anda, no seas modesto y pon un link a tu diseño

[#88 centelleante]

#80 Es este http://www.csszengarden.com/?cssfile=185/185.css ojo, tiene 7 años ya, que se dice pronto, por aquel entonces se llevaban las pixel fonts, los fondos con diagonales y tal. Puedes comprobar la autoría en la esquina superior izquierda

La verdad es que ahora que lo miro, lo hago con bastante nostalgia. Entonces no había web developer toolbar, ni firebug, ni la consola de chrome, de hecho no había chrome, y firefox estaba en pañales.

[#104 Karmakoma]

#88 Pues mola.

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

[#7 dominator]

Yo center y u no entiendo por que los quitan. Son simples y rápidos de usar, igual que b o i. Los demás sí que entiendo que son obsoletos.

[#12 Desactivado]

#11 Hombre, teóricamente sí, pero dudo que los principales navegadores las vayan a eliminar pronto.

[#95 Guarrior]

#11 #12 Ni teoricamente ni nada, si tu página tiene la etiqueta de HTML4, esto no te afecta para nada, lo único es que no podras utilizar las características de HTML5, pero tu página se seguirá viendo igual derante muchísimos años.
Por favor, hablemos sabiendo.

[#132 Desactivado]

#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.

[#67 efoncubierta]

Hola soy Edu y pico HTML desde el año 98... En serio, mucho enteraillo de HTML por aquí Datos por aquí y presentación por allá. No hay más. HTML5 rules!

[#66 edgard72]

Primera noticia sobre HTML5 en menéame: El futuro de la web en estándares: XHTML2, HTML5, CSS3

El futuro de la web en estándares: XHTML2, HTML5, ...

Solo digo que han pasado seis años ya, y...

[#90 grails]

Una de las principales razones por la cual meter el estilo en un archivo css o un javascript en un archivo js (mas d allá de por que es la opción correcta) es que los css y los js se pueden cachear fácilmente en los navegadores y estos mismos no tienen porque volver a descargarse los css y los js.

[#1 Saleroso]

Pues que quieres que te diga el es fundamental y puntual, utilizar CSS para ello me parece una p**tada, tardas más tiempo en buscarlo que en hacerlo, y no rebaja la carga de la página.

[#3 aitkiar]

#1 lo de center no es nada con lo de quitar applet. Hasta cuando usas las utilidades de oracle te genera applet en lugar de object para incrustar los applets. Object no ha funcionado bien nunca, y encima cada navegador lo interpreta como quiere.

[#4 Saleroso]

#3 Esa es otra, cada navegador, sistema operativo, yo cuando trabaja en la primeras páginas en java, veía a los programadores volviendose locos, sobre todo con Opera, había que hacerlo perfecto para todos los navegadores, así que había una retaila en las cabeceras

[#49 scalvo]

#1 Hay que quitar center sí o sí por cuestión "descriptiva" no funcional.

HTML es un lenguaje de marcaje descriptivo; center es una etiqueta de formato. Con las nuevas revisiones se eliminan las etiquetas de formato, como subrayado, u, negrita b o cursiva i.

Por ejemplo, se mantiene em y strong que, por defecto, muestra el texto en cursiva y negrita respectivamente porque su objeto no es mostrar el formato del texto; em "emfatiza" y strong "fortalece" el texto. Son etiquetas descriptivas, no de formatos.

Por tanto, sí, hay que eliminar center. Todo el formato y el diseño a las CSS.

[#58 SHION]

La de quebraderos de cabeza que me dieron los frames en el pasado de todos modos ya pasé de ese mundo...

[#43 disecain]

Madre mía, nivelazo de meneame con el comentario mas votado.

[#2 Desactivado]

Todavía hay páginas que no se han adaptado (mensaje a la derecha) http://postcoitus.opinionware.net/netart/

[#11 Desactivado]

#2 Traduciendo: ¿Hay que cambiar el código donde se utilice esas etiquetas? Gracias.

[#74 miguelpedregosa]

Demasiado experto por metro cuadrado, esto parece un meneo de economía

[#92 Marinmenyo]

"En realidad si aun estás usando font, u y center en el 2012 habiendo css estás en problemas."
+1

[#9 Desactivado]

Ahí, ahí, backward compatibility por los cojones y aumentando la carga de datos a transmitir.

[#28 Desactivado]

Yo pienso que es mejor que se mantengan las etiquetas antiguas, total, nadie te obliga a usarlas

[#100 Guarrior]

Ahora, lo que me estoy dando cuenta es que aquí todos somos desarrolladores

[#136 scalvo]

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

[#77 Desactivado]

Gente que maqueta con tablas y que mezcla estilo con contenido quejandose de que ya no les dejen hacer las cosas mal... pues vaya.

La verdad es que todo lo que quitan está bien quitado, son cosas obsoletas.

[#44 nosolovih]

Pues me parece una faena que lo cambien, con lo que cuesta aprenderlo

[#83 DidE]

Deben pasar muchas décadas para que los navegadores dejen de interpretar estas etiquetas, todos buscan la máxima compatibilidad y como ha dicho alguien , hay mucha pagina antigua que nadie se molestará en actualizar.

[#38 Desactivado]

Me parece bien, de hecho era lo logico

[#60 Desactivado]

Desaparecerán... de las próximas versiones de HTML, y de los navegadores pijos que no quieran tener retrocompatitibilidad con páginas web antiguas.

[#59 Desactivado]

Edit

[#99 Desactivado]

El mayor problema es de retrocompatibilidad. Supongo que cualquier diseñador HTML usará algún tipo de herramienta para aplicar estilos. A lo mejor soy muy interesado, pero quizás sería interesante ver como se diseñaría html si tuviera que ser creado desde cero. HTML arrastra muchos problemas.

Por mucho que se quiera, el html realmente no dice mucho sobre la estructura, y eso siempre es un quebradero de cabeza para los desarrolladores.

[#101 Guarrior]

#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?

[#52 sangaroth]

Entendiendo la evolución de las 'paginas web' a interface de aplicaciones RIA (rich internet apps) el HTML+CSS+JS lo veo obsoleto por mucha nueva versión que salga.
El coste e incompatibilidades de crear interfaces modernas así como volumen de datos transferidos, parseos y redimientos son muy malos en comparación a una maquina virtual que ejecute contenido pre-compilado y binario!!
Si todos estamos de acuerdo que los antiguos applets eran lentos de cojones y el Flash nunca ha convencido a nadie (pocos conocen las virgerias de Flex en rendimiento/coste).

Si en lugar de enfocar los esfuerzos se hubiera desarrollado un standard al estilo Silverlight,Flex con protocolos (seguros) para ayudar a la indexación de los buscadores tendriamos un salto cualitativo brutal que tarde o temprano tendremos necesidad de implementar.

[#54 scalvo]

#52 Es que tu hablas de RIA. HTML es para "documentos". Son cosas distintas y por eso siempre el HTML ha de ser un lenguaje de marcado descriptivo con separación a tres niveles:
HTML: información
CSS: presentación
javascript: interacción.

Lo que tú describes son RIA que son "aplicaciones".

[#91 Desactivado]

#52 NetBSD soporta 17 arquitecturas así por lo bajo. ¿Pretendes crear una VM para todas ellas, teniendo en cuenta que tanto el Motor Webkit como Gecko compilan perfectamente hayá donde esté disponible un compilador de C, sus librerías y TCP/IP?