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.

[#1 Saleroso]

Pues que quieres que te diga el <center> 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.

[#2 --240474--]

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

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

[#5 matacca]

¿Alguien las seguía utilizando?

[#6 --198199--]

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:

<span style="font-weight: bold;">cosa en negrita</span>

para hacer exactamente lo mismo.

Keep It Simple Stupid!

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

[#8 --91567--]

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

[#9 --298049--]

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

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

[#11 --243596--]

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

[#12 --240474--]

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

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

[#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 --91567--]

#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 <font> y otras etiquetas de los inicios de Internet, me parece cuanto menos por pereza e inmovilismo.

[#20 --91567--]

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

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

[#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{font-weight: bold}

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

[#25 --78935--]

Odio el HTML 'moderno'. Es la cosa más poco coherente que existe.
Así que quitan el <u>, porque no tiene significado semántico, pero el <d.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 <div> y <span>, 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: <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.
(Al <d.el> 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.

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

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

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

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

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

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

[#35 --10902--]

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

[#36 --250545--]

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

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

[#40 --152556--]

#6 #24 <b style="font-weight: normal">

[#41 --78935--]

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

[#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{color:green}
- 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.

[#43 disecain]

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

[#44 nosolovih]

<p align="left">Pues me parece una <b >faena</b > que lo cambien, con lo que cuesta aprenderlo</p>

[#45 --109371--]

#1, #6, etc. Creo que os equivocáis. La razón de que <center> 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

[#46 --91567--]

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

[#47 --159598--]

#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

[#48 nicorl]

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

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

[#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í:

<span class="nombre_estilo">Texto en negrita, cursiva, como no los de la gana o controlado mediante javascript</span>

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

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

<div id="header">... </div>

<div id="content">... </div>

<div id="footer">... </div>

Algo como <div id="manzanas">aquí datos sobre manzanas</div> <div id="peras">aquí datos sobre peras</div> tiene una buena fuerza expresiva.

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

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

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

[#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 --155529--]

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

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

[#58 SHION]

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

[#59 --259638--]

Edit

[#61 iRiku87]

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

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

[#63 --45633--]

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

[#64 --46364--]

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

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

[#66 edgard72]

Primera noticia sobre HTML5 en menéame: www.meneame.net/story/el-futuro-de-la-web-en-estandares-xhtml2-html5-c

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

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

[#68 --187454--]

#61 antes:
<center>...lo que sea todo centrado...</center>

ahora:
.centered { margin:auto; text-align:center; }
<span class="centered">...lo que sea todo centrado...</span>

o bien:
<span style=" margin:auto; text-align:center;" >...lo que sea todo centrado...</span>

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.

[#69 --259400--]

#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

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

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

[#74 miguelpedregosa]

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

[#75 --8686--]

#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

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

[#77 --285042--]

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.

[#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 <center>, en 2012, es de puto juzgado de guardia joder. margin: 0 auto; o text-align: center.

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

[#80 Karmakoma]

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

[#81 --165145--]

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

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

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

[#84 --166178--]

#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

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

[#86 --91567--]

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

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

[#88 centelleante]

#80 Es este 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.

[#89 --165145--]

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

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

[#91 --125581--]

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

[#92 Marinmenyo]

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

[#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 <strong\>, 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 <strong\>, 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...

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

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

[#96 --308400--]

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

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

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

[#99 --143520--]

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.

[#100 Guarrior]

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