La web ha evolucionado enormemente desde sus inicios, pero en algunos aspectos cruciales sigue anclada en el pasado. Mientras tecnologías como WebAssembly (WASM) ganan terreno incluso en el servidor, las páginas web que usamos todos los días todavía funcionan con sistemas viejos como el DOM, HTML y CSS, que fueron creados hace décadas y no están pensados para las necesidades de hoy.

En su blog profesional, el desarrollador Steven Wittens ha expuesto con detalle esa idea (y dejado caer, al final, algunas posibles soluciones) en un texto que propone repensar, desde su misma base, los fundamentos del desarrollo web.

¿Qué es el DOM y por qué es un lío?

Cuando visitas una página web, tu navegador construye una especie de "árbol" interno para entender y mostrar el contenido. Ese árbol se llama DOM, que significa Document Object Model o "Modelo de Objetos del Documento".

Imagina que el DOM es como una maqueta de LEGO de la página, donde cada bloque representa un elemento: un título, una imagen, un botón, etc. Suena bien, ¿verdad? El problema es que este sistema se ha vuelto tan viejo y complicado que ya nadie lo entiende del todo bien… ni siquiera los expertos.

Por ejemplo, en Google Chrome, un solo bloque de esa maqueta (document.body, que es básicamente el cuerpo de la página) tiene más de 350 funciones y propiedades diferentes. Y si hablamos del estilo (colores, márgenes, tamaños), hay más de 660 opciones solo para eso.

Es como tener una caja de herramientas tan grande que ya no sabes qué usar, ni cómo. Además:

• Muchas herramientas están obsoletas (ya no se usan, pero ahí siguen).
• Varias hacen lo mismo, pero de formas diferentes.
• Algunas cambian cosas en la página de maneras inesperadas.

Debido a este caos, la mayoría de desarrolladores modernos evitan trabajar directamente con el DOM. Usan herramientas más fáciles y organizadas (como React o Vue), que simplifican todo.

Y aunque hay intentos por mejorar esto, como los Web Components (una forma más moderna de crear partes reutilizables de una página), llegaron tarde y no son muy populares porque son difíciles de usar.

HTML: ¿Y la semántica, dónde quedó?

HTML es el lenguaje básico con el que se construyen las páginas web. Su objetivo original era permitir que los sitios fueran claros y organizados: con títulos, párrafos, listas, artículos, comentarios… todo bien etiquetado.

Eso se llama semántica: usar etiquetas que explican qué es cada parte del contenido, no solo cómo se ve.

Pero, aunque han pasado más de 10 años desde que salió la versión vigente de HTML (HTML5), seguimos sin tener etiquetas para cosas tan comunes como un hilo de conversación (<thread>) o un comentario (<comment>). Eso significa que los desarrolladores tienen que improvisar y usar etiquetas genéricas como <div> o <article>, que no dicen claramente lo que representan.

En Genbeta

No suele considerarse a HTML y CSS lenguajes de programación... pero hay quien no está de acuerdo (y tienen buenos argumentos)

Además, las reglas para usar las etiquetas "correctamente" son confusas. Por ejemplo, según algunas guías, un artículo dentro de otro artículo podría considerarse un comentario... pero eso no tiene mucho sentido, ¿verdad?

Hoy en día, las grandes decisiones sobre cómo evoluciona HTML las toman principalmente los creadores de navegadores (como Google o Apple), no una comunidad abierta. ¿Y qué han hecho? Pues en lugar de rediseñar o simplificar HTML, han ido agregando pequeñas cosas nuevas aquí y allá, como quien sigue parcheando una prenda vieja.

CSS: ¿por qué alinear cosas en la web es tan difícil?

CSS (siglas en inglés de "hojas de estilo en cascada") es lo que usamos para darle forma y colores a una página web: tamaños, márgenes, colores, posiciones, etc. Pero a pesar de ser tan importante… muchas veces parece estar en contra nuestra.

¿Te ha pasado que simplemente quieres poner dos cosas una al lado de la otra, o que algo quede centrado en la pantalla, y por más que lo intentas no pasa lo que esperas? No estás solo.

El problema principal es que CSS no funciona como creemos.

Imagina que tienes una caja con dos cajones adentro y que quieres que cada cajón ocupe la mitad del espacio. Lógico, ¿no?

<div>
 <div style="height: 50%">...</div>
 <div style="height: 50%">...</div>
</div>

Pero CSS no lo entiende así. En realidad, necesita que primero le digas cuánto mide la caja grande. Si no lo haces, simplemente ignora tus instrucciones.

Esto es porque CSS trabaja de una forma algo rara: primero mira el contenido (lo que hay dentro) y luego decide qué tamaño debería tener el contenedor. Es como si compraras una caja para tus cosas... después de ver cuántas cosas tienes.

¿Cómo se soluciona eso? Bueno, el CSS moderno tiene herramientas como Flexbox, que ayudan a distribuir mejor el espacio entre elementos. Pero hasta esas herramientas cuentan con sus propios problemas.

SVG: potente pero caótico

SVG son las siglas en inglés de "gráficos vectoriales escalables". Es una tecnología que permite dibujar cosas como iconos, gráficos, logotipos o ilustraciones directamente dentro de una página web, sin que se vean borrosas al hacer zoom. Resulta útil porque...

En Genbeta

Así se ha ido complicando la arquitectura detrás de las aplicaciones web en los últimos 26 años

• Puedes cambiar el tamaño de un dibujo sin perder calidad.
• Puedes modificar colores, formas o posiciones con código.
• Incluso puedes hacer que reaccione al pasar el mouse o hacer clic.

Pero, aunque SVG sea tan polivalente, usarlo en combinación con HTML y CSS puede volverse un lío por varias razones:

• No 'habla el mismo idioma' que CSS: Aunque a veces puedes aplicar estilos CSS a los dibujos SVG, no siempre funcionan igual. Hay reglas que se comportan diferente o simplemente no aplican.
• Es complejo: Para hacer un dibujo, tienes que escribir instrucciones como <path d="M150 0 L75 200 L225 200 Z" />. ¡Sí, eso es un triángulo! Pero no es precisamente amigable a la vista ni fácil de entender.
• ¿Cuándo usar SVG y cuándo HTML?: A veces puedes hacer una figura con HTML y CSS, otras veces necesitas SVG. Pero no hay una regla clara. Elegir entre uno u otro puede depender de detalles técnicos molestos.
• Algunas cosas útiles solo están en SVG: Por ejemplo, si quieres detectar clics en formas con bordes irregulares (como una estrella), SVG lo hace fácil. HTML y CSS... no tanto.

La pesadilla del 'kitbashing web'

A lo largo de los años, el desarrollo de interfaces web ha evolucionado a base de "parchar" las herramientas existentes. Esto ha dado lugar al fenómeno del kitbashing, un término tomado del modelismo donde se ensamblan modelos a partir de piezas que no estaban diseñadas para funcionar juntas. En la web, esto se traduce en construir interfaces sofisticadas combinando HTML, CSS y SVG en formas para las que nunca fueron concebidos.

Esto ocurre porque HTML y CSS no fueron pensados originalmente para hacer aplicaciones. Se crearon para mostrar documentos, como artículos o noticias, no para hacer cosas como editores de texto tipo Google Docs o chats como WhatsApp Web.

Ejemplos de lo difícil que puede ser:

• Un chat que se quede pegado abajo (como en WhatsApp):
  Parece algo básico, ¿no? Pero lograr que la ventana del chat se quede abajo cuando llega un nuevo mensaje requiere escribir código personalizado cada vez. No hay una forma fácil y automática de hacerlo con HTML y CSS.
• Copiar y pegar texto con formato: Si alguna vez copiaste texto de una página web y lo pegaste en otro lugar, sabrás que a veces se conserva el color o el estilo… y a veces no. Hacer que eso funcione bien en una app web requiere "trucos invisibles", como poner elementos escondidos fuera de la pantalla para que el sistema entienda qué se está copiando.
• Listas y tablas muy largas (como una hoja de cálculo): Mostrar muchos datos (como en Excel) es difícil en una web. Si lo haces directamente, la página se vuelve lenta. Para solucionarlo, los desarrolladores tienen que "engañar" al navegador: solo muestran una parte de la lista y cambian lo que se ve a medida que el usuario se desplaza.
• Cajas que se vean bien en diferentes tamaños de pantalla: Ajustar el diseño para que se vea bien en un celular y en una computadora suena lógico, pero hacerlo con HTML y CSS puede ser muy complicado. A veces hay que escribir muchas reglas específicas, o usar herramientas externas que tratan de hacerlo más fácil.

En Genbeta

Estos son los errores que todo desarrollador web debería evitar (si no quiere perder tiempo y energía), según este experto

Canvas: ¿una solución?

Ante las limitaciones evidentes del DOM y CSS, algunos desarrolladores y estándares emergentes han puesto sus ojos en una alternativa radical: usar <canvas> como plataforma principal para renderizar interfaces. La propuesta más notable en esta línea es HTML-in-Canvas, que plantea la idea de renderizar fragmentos de HTML dentro de un <canvas>, permitiendo personalizar completamente su presentación visual.

Suena atractivo: ¿por qué no aprovechar la potencia gráfica de Canvas para superar las deficiencias del modelo de caja y de estilo del navegador? Pero este enfoque trae consigo una gran cantidad de obstáculos tanto técnicos como filosóficos.

Para empezar, la API propuesta sigue estando atada al DOM, lo que significa que los elementos a renderizar deben seguir existiendo dentro del árbol de documentos para ser interpretables. Esto introduce una contradicción: si necesitas <canvas> para librarte del DOM, ¿por qué seguir dependiendo de él para dibujar?

Además, para lograr interactividad, el sistema obliga a reimplementar el modelo de interacción desde cero: gestión de eventos de mouse, teclas, estados de foco, accesibilidad... todo debe recrearse manualmente.

Se trata de un sistema donde el desarrollador asume el control absoluto, pero también la carga completa, como si estuviera desarrollando usando un motor de videojuegos.

Uno de los principales argumentos a favor de usar canvas es que “al menos es programable”. Pero en realidad, es un recurso extremadamente limitado:

• No tiene acceso directo a fuentes del sistema ni a APIs nativas de layout de texto.
• No ofrece herramientas nativas para manejar accesibilidad, localización o compatibilidad móvil.
• No permite reusar eficientemente estilos, efectos ni interacciones predefinidas del navegador.

¿Y entonces, qué?

Después de todo lo que hemos visto, queda claro que el modelo actual de cómo se construyen las páginas web —usando HTML, CSS y el famoso DOM— está roto, pero eso no significa que no haya solución. De hecho, según Wittens es totalmente posible mejorar todo esto… si nos atrevemos a cambiar las bases. Así que, ¿qué deberíamos hacer?

Empezar con una estructura más clara

Hoy en día, cuando haces una web, terminas mezclando muchas cosas: contenido, estilo y comportamiento. Todo está enredado.
Lo ideal sería separar mejor:

• Lo que se muestra (el diseño).
• Cómo se comporta (la interacción).
• Qué significa cada cosa (la semántica).

En Xataka

La web se ha convertido en un lugar horrendo para mucha gente. Así que están reconstruyendo su versión 1.0 como refugio

Tener estos tres aspectos separados haría que todo fuese más fácil de desarrollar, mantener y escalar.

Diseñar pensando en cómo se hacen apps hoy

Las páginas web de hoy ya no son solo documentos, son aplicaciones completas, como redes sociales, editores de texto, videojuegos… Y para eso necesitamos herramientas más modernas. Cosas como React, Vue o Svelte existen precisamente porque el sistema base (HTML+CSS+DOM) no da la talla.

Así que ¿por qué no rediseñar esas bases para que lo moderno ya venga incorporado?

• Que los cambios en la pantalla sean automáticos cuando cambie algo en el sistema.
• Que podamos mover elementos o cambiar estilos sin pelear con reglas raras de CSS.
• Que el código sea fácil de leer, escribir y entender.

Ya hay ejemplos funcionando

Wittens insiste en que no estamos hablando de fantasías, pues ya hay proyectos reales que ya están probando cómo se podría hacer todo esto mejor. Uno de ellos, por ejemplo, es Use.GPU, un sistema visual hecho con tecnología nueva llamada WebGPU. ¿Qué logra?

• Interfaces mucho más rápidas y suaves.
• Diseños con menos líneas de código.
• Posicionamiento de elementos que por fin tiene sentido (sí, centrar cosas es fácil).
• Efectos visuales sin trucos raros ni dolores de cabeza.

Y esto lo ha hecho una sola persona, con un sistema más claro y moderno que toda la maquinaria actual del navegador.

También hay navegadores nuevos como Servo y Ladybird que están empezando de cero. No arrastran todo el peso de 30 años de web, así que pueden tomar decisiones más inteligentes desde el principio.

Imagen | Marcos Merino mediante IA

En Genbeta | En esto consiste la labor de un desarrollador Full Stack: un perfil laboral todoterreno

En el mundo de la programación lleva mucho tiempo vigente un debate acerca de si los lenguajes HTML y CSS, que son la base del desarrollo web, son o no 'lenguajes de programación'. Sea en discusiones online o no, no es infrecuente encontrarnos con programadores de lenguajes de programación 'de verdad' siendo cortantes cuando oyen a alguien sugerir que sabe programar sólo porque ha aprendido HTML.

En StackOverflow, de hecho, se preguntan por qué tienden a ser "tan pendantes" con este tema, mientras que algunos diseñadores web consideran que los programadores con 'pedigree' son demasiado dogmáticos en su definición de lenguajes.

Pero no se trata de un debate baladí: a nivel técnico, es importante tener claro qué constituye un lenguaje de programación y qué no lo hace. Y también tener claro qué son realmente capaces de hacer HTML y CSS, para despejar cualquier duda sobre la etiqueta más correcta a aplicarles.

Lo primero que hay que tener claro es qué criterio utilizar para decidir qué es un lenguaje de programación y qué no. Y el más habitual y tradicional para ello es la capacidad de un lenguaje para ser 'Turing-completo'. Pero, ¿qué demonios es eso?

¿Turing-Qué?

Un lenguaje de programación se considera Turing-completo cuando tiene la capacidad de realizar cualquier cálculo que una Máquina de Turing pueda llevar a cabo. La pregunta es obvia, entonces, es "¿Qué es una Máquina de Turing?".

Como habrás supuesto ya, el Turing al que no dejamos de hacer referencia es Alan Turing, el padre de la computación moderna, popularizado por su trabajo con las computadoras Enigma durante la Segunda Guerra Mundial.

Pero esas no son las máquinas a las que nos referimos, sino a un dispositivo abstracto que Turing teorizó en 1936, que contaba con las siguientes características:

• Consta de una cinta infinita dividida en celdas, una cabeza de lectura/escritura que se mueve a lo largo de la cinta y un conjunto finito de estados y reglas de transición.
• Puede leer y escribir símbolos en la cinta, cambiar de estado según las reglas y moverse hacia la izquierda o la derecha.

En Genbeta

La estructura IF-THEN-ELSE: su origen y su papel en la creación de la inteligencia artificial

Esta descripción puede parecer simple, pero es una abstracción utilísima con la que Turing demostró que -si bien hay problemas que, efectivamente, una computadora nunca podrá resolver- si un problema puede resolverse mediante un algoritmo, puede resolverse con una máquina de Turing.

Por lo tanto, ser 'Turing-completo' significa que el lenguaje en cuestión debe ser capaz de simular cualquier algoritmo de computación, realizando para ello tres tareas fundamentales:

• Leer y escribir sobre un medio de almacenamiento.
• Controlar el flujo de ejecución mediante instrucciones condicionales (como if/else) y bucles (como for o while).
• Modificar su propio código o estado durante la ejecución.

Tres ejemplos rápidos de lenguajes Turing-completos serían Python, Java y C++.

HTML y CSS, sin embargo, no cumplen con estos criterios: HTML es un lenguaje de marcado utilizado para estructurar contenido en la web, mientras que CSS es un lenguaje de estilo usado para describir la presentación visual de un documento HTML.

HTML y CSS, más de lo que parecen (¿pero no lo suficiente?)

HTML: El HTML ha sido la columna vertebral de la web desde sus inicios. A primera vista, HTML puede parecer un lenguaje simple que se limita a definir encabezados, párrafos y enlaces, pero en realidad, ha evolucionado para incorporar elementos más avanzados, como multimedia, formularios interactivos con elementos de entrada y validación, almacenamiento local...

CSS: Por otro lado, el CSS se encarga de dar estilo y formato a los elementos HTML. Más allá de ser simplemente un conjunto de instrucciones de presentación estática, CSS también involucra el uso de conceptos lógicos: los 'media queries', son reglas condicionales que permiten que las páginas web se adapten a diferentes tamaños de pantalla y dispositivos. Han existido incluso exploits para vulnerabilidades de Mozilla Firefox basados únicamente en CSS.

Pero nada de esto basta para convertirlos en lenguajes Turing-completos. Así que, ¿hay más que argumentar o terminamos aquí la discusión sobre si son o no lenguajes de programación?

vía r/ProgrammerHumor

¡Tenemos un último testigo, señoría!

Un desarrollador web llamado Eli Fox-Epstein presentó una forma de simular la Regla 110 utilizando CSS y HTML en un evento llamado Hack && Tell en 2011. Dicha 'Regla' es un modelo de autómata celular (un patrón unidimensional compuesto por varios unos y ceros, que van evolucionando de acuerdo a ciertos patrones) creado por Stephen Wolfram que, pese a su extraordinaria simplicidad, en 2004 se demostró que es Turing-completo.

La simulación de Rule 110 en CSS se basa en la idea de que el código CSS puede representar el estado de las células en un autómata celular, y las interacciones de los elementos HTML pueden simular las reglas de transición de Rule 110. Cada paso del autómata celular se ejecuta mediante cambios en el DOM (Modelo de Objetos del Documento) y se aplican reglas de estilo condicionales en CSS para representar los cambios de estado.

En este enlace tienes todos los detalles necesarios (fragmentos de código incluidos) para comprender este peculiar experimento.

Lo que nos interesa es que si un modelo de autómata celular Turing-completo puede ser simulado con CSS3 y HTML5, eso significa que, si no ambos lenguajes, la suma de ambos sí puede considerarse Turing-completo... y, por tanto, un lenguaje de programación con todas las de la ley.

Imagen | Marcos Merino mediante IA + Foto de Alan Turing (dominio público)

En Genbeta | Escribe en once lenguajes de programación sabiendo sólo uno de ellos con esta herramienta web

Este artículo está encabezado por la imagen de una Nintendo Game Boy... cuya única peculiaridad es que, antes de que hiciéramos la pertinente captura, no era una imagen ni por asomo: sólo el resultado de utilizar código CSS (siglas de 'hojas de estilo de cascada') en una página web.

La imagen en cuestión es una creación del desarrollador y streamer español 'Manz', que la publicó ayer en Twitter acompañado de sendos enlaces a una demo visual y al correspondiente repositorio de código. Te animamos a entrar en el primero e intentar hacer clic con el botón derecho sobre la 'imagen'... ¡A ver si eres capaz de lograr que aparezca aquello de 'Guardar imagen como'!

⬅ Izquierda: La fotografía original
➡ Derecha: Código CSS (sin usar imágenes)

🤯¿Qué te parece?
<👇> Links en el siguiente tweet pic.twitter.com/z6aLLp9O5U

— Manz 🇮🇨⚡👾 (@Manz) January 26, 2023

Y si no sólo te has quedado boquiabierto con el truco, sino que te pica la curiosidad sobre cómo es posible hacer algo así, sigue leyendo (claro que, si por el contrario, ya tienes una idea básica de cómo hacerlo, revisar el enlace a GitHub te mostrará las herramientas y recursos usados por Manz para lograrlo).

Una explicación rápida

Crear una imagen usando únicamente tecnología CSS se diferencia poco o nada de la creación de un gráfico vectorial (esas imágenes que puedes ampliar indefinidamente sin que se pixelen); lo que ocurre es que, en lugar de usar para ello un software de ilustración vectorial como Adobe Illustrator usamos una dosis generosa de código CSS (y algo de HTML para poder mostrar el resultado, por supuesto).

Al igual que ocurre con las vectoriales, la forma de crear una imagen CSS se basa en ir separando y superponiendo cada capa de la misma. Por supuesto, cuanto mayor es el realismo buscando en el resultado, mayor número de capas hay que crear para no simplificar en exceso las formas y colores.

Créditos: Miguel Mangialardi

Eso, en el caso del CSS, exige lo siguiente:

• Un campo 'div' para cada capa.
• Una clase CSS asignada a cada 'div'.
• Clases CSS complementarias que definan los estilos a aplicar al citado 'div'.

Esto se puede hacer directamente tecleando código CSS y HTML en un editor de texto, o bien recurriendo a los múltiples frameworks y herramientas de desarrollo web disponibles en el mercado.

En Xataka

Cómo vectorizar una imagen

Y es que el CSS no permite sólo crear formas geométricas y colores, también degradados... y sombras. Y las sombras pueden resultar fundamentales a la hora de dotar de volumen (y, por tanto, de realismo) a una imagen antes plana. La diferencia, como se observa en la siguiente es notable; y para lograrlas basta con utilizar las propiedades 'text-shadow' y 'box-shadow' del estándar CSS:

Créditos: Mustapha Aouas

Lo anterior forma parte de otro ejemplo magnífico de Game Boy creada íntegramente con CSS, sólo que esta incluye sus propios juegos desarrollados con JavaScript:

Check out this CSS art of a Gameboy I made with a small peculiarity, it's actually playable 🕹
Link 👉 https://t.co/NhuY6SguLv

What's your highest score? Mine is 90...almost 💯

Use your keyboard if you're on a laptop
Made with the #angular game engine & #javascript #html #css pic.twitter.com/oavVNkAsqV

— Mustapha Aouas (@TheAngularGuy) November 25, 2021

Una vez que has entendido eso, quizá quieras pasarte por el canal de YouTube de Manz, donde nos muestra un 'paso a paso' cómo crear una Game Boy con CSS:

Si eres diseñador, desarrollador, trabajas en marketing, o creas contenido para la web, quizás esta herramienta te venga bien. WebSlides es un proyecto del sevillano José Luis Antúnez que busca ofrecer una buena plataforma para contar historias, solo necesitas conocimientos básicos de HTML y CSS para crear tu propia presentación en pocos minutos.

WebSlides ofrece una base bastante completa para que cualquiera pueda editar los componentes de la presentación a su gusto y crear algo verdaderamente genial sin ser un desarrollador web experto. Puedes enfocarte en el contenido y WebSlides se encarga del aspecto técnico y visual de la presentación.

Puedes descargar el proyecto desde su web en GitHub y comenzar a editar cualquiera de los demos disponibles con tu propio contenido, o si lo prefieres puedes mirar como luce cada uno desde esta página. Tienen un estilo bastante moderno y minimalista ideal para contar historias.

Los demos incluyen varias características interesantes, como navegación usando las flechas del teclado o deslizando sobre la pantalla, enlaces permanentes, contador de diapositivas, más de 500 iconos SVG, componentes adicionales como portadas, tarjetas, citas, etc. El código es lo más limpio posible sin uso de demasiadas clases o anidamiento de los elementos.

WebSlides está basado en SimpleSlices y ofrece otra alternativa más para crear presentaciones de forma sencilla sin tener que recurrir a software especializado y con resultados sumamente profesionales. Si eres alguien que maneja lo más básico del código HTML y CSS, puedes fácilmente editar una de estas plantillas y crear una presentación genial.

En Genbeta | 11 webs y canales de YouTube para aprender HTML5 desde 0 hasta nivel experto

En la primera parte de la entrevista a Paul Cotton que publicó mi compañero Guillermo, el director del equipo interoperabilidad de Microsoft nos dejó unas reflexiones más que interesantes. Entre ellas, el porqué de la apuesta en exclusiva para Windows de Internet Explorer, el estado de desarrollo de HTML5 o su opinión sobre Chrome OS.

En esta segunda, aparte de seguir comentándonos aspectos sobre su trabajo en el mundo de los estándares (recordemos que es miembro del grupo de trabajo de W3C sobre estos temas), conversamos un poco sobre cómo ve el futuro de Internet Explorer, especialmente tras la compra de Skype o la irrupción de Kinect. E incluso se atreve a hablar un poco de la navegación “en la nube” como gran apuesta a medio plazo para Internet.

Genbeta: En el pasado W3C, Microsoft presentó Same Markups. Fue algo realmente impactante y novedoso. ¿Crees que es el primer paso para que en el futuro todos los navegadores muestren y hagan funcionar las páginas webs de igual manera?

Paul Cotton: Es el primer paso. Hay otras partes del HTML5 también importanes. Same Markups es algo clave, pero hay otros pequeños aspectos de HTML5 que también lo puede ser. Pero si Same Markups está mal, todos los navegadores tendrian un el mismo fallo. Same Markups tiene las dos vertientes, la positiva y la negativa. Una pagina web mal construida tendrá unos errores en IE y otros en Mozilla. Queremos que si el desarrollador se equivoca en su página, en su desarrollo, tenga el mismo mensaje que cuando lo estaba probando.

“Queremos que todos los navegadores muestren los mismos errores. No queremos que un desarrollador cree una página web, la pruebe en Firefox y piense que funcione, pero que al ponerla en Internet Explorer se vaya todo al carajo”

Genbeta: Sobre los estándares, nosotros solo vemos el trabajo en la implementación en los navegadores. ¿Cuál es el trabajo que está detrás de todo el mundo de los estándares y el W3C?

Paul Cotton: Mi equipo lleva trabajando en esto del W3C los 11 años que llevo en Microsoft. En W3C se encuentra el equipo de trabajo centrado en Windows, el de Internet Explorer y el mío. Trabajamos juntos para Microsoft y estamos siempre hablando vía e-mail.
Creo que la gente no valora todos las pruebas que hacemos. En Redmond hay una sala con un superordenador formado por cientos de ordenadores, cada uno corriendo una o varias versiones de Windows para hacer tests. En el aŕea de Internet Explorer, cada vez que un equipo está produciendo nuevo código, se hacen pruebas regresivas.
Lo que no ve en lo que llamamos “hard engineering” de construir un navegador es hacer un montón de tests. Por ejemplo, grupos de trabajo con las últimas versiones de CSS hacen más de 9000 pruebas para comprobar que funciona. Es un número alto, pero es que 6000 pueden no ser suficientes.
En Microsoft tenemos 3 tipos diferentes de ramas: los desarrolladores, los programadores y los probadores. Y los probadores son tan de primera clase como los otros.

Genbeta: Tras dos de las últimas incorporaciones a Microsoft, la compra de Skype y la consolidación y el éxito de Kinect, la gente tiene muchas esperanzas en su integración en Internet Explorer. ¿Ves posible lo que algunos sueñan de un navegador que se controle con voz y gestos, como las interfaces de la película Minority Report?

Paul Cotton: Os cuento mi experiencia. Tengo una Xbox 360 con Kinect. Y mucha gente no se da cuenta de que aparte de interpretar posiciones y gestos, también tiene reconocimiento facial. Unir esto a la tecnología de VoIP de Skype puede ser genial. Me imagino estar sentado en mi sofá, con mi Tablet con Internet Explorer, -con el que puedo controlar lo que hay en la TV – viendo un vídeo y mirar a la TV, que me reconozca Kinect y decir “¡Llama a mamá!”, y que lo haga.
Yo vivo en Ottawa, Canadá, y tengo que viajar un montón a Redmond. Y una de las cosas que más uso para comunicarme es un sistema de VoIP. Pero ahora también tenemos herramientas que, por ejemplo, si nos mandan un e-mail y hago click en la persona que me lo ha enviado, puedo chatear con él. Y trasladar esa experiencia al cuarto de estar, enfrente de la televisión, cambiará un montón de cosas.

Tengo un teléfono fijo encima de la televisión. Creo que en el futuro desaparecerá y hablaré por medio de la Xbox.

Genbeta: ¿Crees que es posible que veamos esto, en 3 o 4 años, en millones de casa por todo el mundo?

Paul Cotton: Ha habido una magnifica adopción de Kinect, esa máquina capaz de reconocer nuestros movimientos. Ya puedes conectar tu PC a la Xbox. Y vas a tener una conexión con tu calendario, y llamar a tus contactos. Podré hacer una videoconferencia sin un dispositivo físico, sin tener que tocar nada.
Hay un enorme potencial. Y podría decirlo incluso como simple usuario, estoy impactado. Ví Kinect en una feria científica que organizó Microsoft hace 4 años. En otra ví Microsoft Surface. Y convertir un aparato que formaba parte de una investigación en algo que se vende de forma masiva al gran público es increíble.

Genbeta: Una de las nuevas cosas de HTML5 es HTML.Next ¿Cómo crees que va a evolucionar en el futuro?

Paul Cotton: Cuando Google sacó Gmail, se dieron cuenta de que necesitaban SQL, WebSQL. Cuando preguntamos a nuestros desarrolladores qué querían sobre este asunto nos comentaron cosas similares. La mayoría de mis aplicaciones son mucho más sencillas.Mozilla ha trabajado con Oracle sobre este aspecto, por ejemplo.
Los desarrolladores quieren tener un “client store”. Tenemos 4 prototipos de indexados en los HTML5Labs en la Last Call, para ser estables y hacer aplicaciones de ellos. Los Client Stores son claves y van a abrir muchas posibilidades.

Genbeta: Para finalizar, una última pregunta no tanto sobre Internet Explorer sino sobre el futuro de Internet. Algunos expertos, cada vez más, apuntan a que el mañana de la web pasa por la navegación “en la nube” y que la era de soportes físicos y discos duros es cosa del pasado. ¿Tú qué opinas sobre este tema?

Paul Cotton: Bueno, yo paso muchísimo tiempo navegando en la nube. Sin duda, para muchos clientes que lo usan en vez de otras opciones es el futuro. Yo apuesto por la “cloud computing” porque realmente puede ahorrar mucho dinero si invertimos en ella, pues solo habrá que pagar al proveedor de la “nube”. Va a ser muy importante próximamente.
Creo que vamos a movernos hacia dispositivos como el iPod Touch, que parecen un teléfono pero no lo son. No son un teléfono pero tienen conexión a Internet. Apple ha creado un nuevo mercado. La gente lo usa muchísimo. Me imagino en un futuro próximo a la gente usando estos aparatos, viendo un vídeo; y haciendo un gesto como deslizar la mano sobre la pantalla y entonces salta a tu TV y lo podrás ver allí. Nadie anticipó esta gran oportunidad.
Esto es una de las cosas que hace tan grande el W3C, es un regalo para todos nosotros y hace públicas cosas de las que se puede beneficiar toda la sociedad.
No podemos siquiera soñar todas las cosas que nos esperan. Hace poco descubrí en el W3C
un grupo de trabajo que iba a convertir los juegos típicos de PC o del estilo Halo a una plataforma como HTML5. Puede que en el futuro cuando le preguntemos a un usuario de este tipo de plataformas portátiles a qué juega más nos responda Angry Birds, pero es posible que nos diga que es uno de estos juegos originalmente nativos de PC.

Hasta aquí la entrevista con Paul. Guillermo y yo tuvimos el lujo de hablar un buen rato con él, por lo que debemos agradecer a la sección de prensa de Microsoft por concertar esta cita con uno esos hombres que marca el futuro de Internet. Hay que decir que fue muy cercano a nosotros y fue una delicia charlar con él.

Nos deja un par de perlas bastante interesantes, tanto sobre el presente como de el futuro de las webs, así que estamos deseando que compartáis vuestras opiniones aquí.

Hace poco, Paul Cotton estuvo en Bilbao con el grupo del W3C, y pudo hacer una escapada a Madrid. Paul Cotton es director del equipo de interoperabilidad de Microsoft, que se encarga de la parte de HTML y tecnología en la nube, y además es miembro del grupo de trabajo del W3C que se encarga de los estándares web.

Nosotros pudimos estar con él unos minutos, y le hicimos preguntas sobre la integración de estándares en Internet Explorer, sobre HTML5 y sobre lo que podríamos tener en el futuro gracias a las nuevas tecnologías. Paul tiene una visión muy clara de la web y de sus tecnologías, y sus respuestas han sido muy interesantes.

Antes de comenzar con las preguntas, queremos agradecer a Paul Cotton habernos cedido un hueco en su apretada agenda para hablar con nosotros, y a Raúl Barrantes y el resto de personas de relaciones públicas de Microsoft por facilitarnos la entrevista. Y ahora sí, vamos con las preguntas.

Genbeta: Hace años veíamos como IE tradicionalmente tenía etiquetas y características propias que lo hacían de todo menos estándar, viendo Webs diseñadas únicamente para IE. ¿Qué impulsó a Microsoft a comenzar a implantar estándares en sus productos?

Paul Cotton: Bueno, creo que tenemos que ver un poco de historia, qué ha ocurrido con el W3C y los estándares. Lo que ocurrió es que el W3C se centró demasiado en XHTML, y esto impulsó a crear el WHATWG, organización que se puso a trabajar con HTML5. Hace unos cinco años, ese grupo decidió devolver HTML5 al W3C, principalmente por la protección de los socios. Eso dio a Microsoft la oportunidad de volver al escenario entrando en el grupo de trabajo de HTML5. Fue una gran oportunidad para Microsoft, y mostramos un montón de interés en todas las tecnologías de HTML5. Hay otro aspecto de los estándares que es muy importante para Microsoft: la establidad de las especificaciones. Si queremos que todo funcione igual independientemente del navegador, necesitamos que la especificación no cambie continuamente, y eso sólo lo podemos conseguir en el W3C trabajando de forma multilateral con el resto de navegadores.

Hay un precio que pagar para poder probar esas tecnologías web antes que nadie. Microsoft espera a la estabilidad de la especificación para implementar las nuevas características.

Genbeta: Ahora mismo, ¿cuáles son las diferencias más significativas en la implementación de HTML5 entre IE y el resto de navegadores?

Paul Cotton: Algunos de los otros navegadores son earlier adopters. No es malo, depende sobre todo de tu audiencia, del tipo de usuarios del navegador. Muchos de los clientes de Microsoft no esperan cambiar la web cuando la especificación cambie. El ejemplo perfecto es WebSockets, que permite una comunicación bidireccional con el servidor. El problema es que no ha sido estable. Algunas versiones rompieron la compatibilidad con las anteriores, obligando a recodificar las páginas. Por eso, la establidad es clave. No voy a decir que ser un early adopter es malo, sólo que depende de la audiencia. Hay un precio que pagar para poder probar esas tecnologías antes que nadie.

Genbeta: Microsoft ha dicho que todavía no va a implementar algunas partes de HTML5, como WebSockets. ¿Qué partes son, y por qué?

Paul Cotton: Por ejemplo, un buen número de las especificaciones de CSS3 no están en IE9. Sin embargo, en la Platform Preview que enseñamos en MIX hay bastantes implementadas. En otros, como WebSockets, esperaremos a que la especifación se estabilice. Nuestros dos criterios para implementar algo en IE son estabilidad y peticiones de clientes. Si no estable o no tenemos muchas peticiones de clientes, no desarrollamos esa implementación.

Genbeta: Ahora todo el mundo habla de los nuevos estándares, de HTML5, CSS3… ¿Qué nos aportan a nosotros estos estándares como usuarios? ¿Qué se puede hacer con ellos que no se pudiese hacer antes?Todos los navegadores principales son multiplataforma. ¿Tiene IE algún plan parecido?

Paul Cotton: Nos concentramos en lo que hacemos mejor. Queremos hacer un navegador que saque lo mejor de la plataforma Windows. Creemos que hay un montón de sitio para otros actores como Mozilla u Opera que quieren llevar el navegador al mayor número de plataformas posibles. El problema de eso es que tienes que ir al mínimo común. Con IE, podemos centrarnos en el entorno que conocemos mejor. El resultado es una experiencia increíble, como por ejemplo con la aceleración de hardware. También nos estamos centrando en Windows Phone, para que sus usuarios tengan una experiencia web perfecta.

Nos concentramos en lo que hacemos mejor. Queremos hacer un navegador que saque lo mejor de la plataforma Windows

Genbeta: Ahora todo el mundo habla de los nuevos estándares, de HTML5, CSS3… ¿Qué nos aportan a nosotros estos estándares como usuarios? ¿Qué se puede hacer con ellos que no se pudiese hacer antes?

Paul Cotton: Creo que una de las cosas más interesantes es WebSockets. Cuando funcione, va a ser un cambio de paradigma. Tendremos capacidades de tiempo real en la web, algo muy interesante. En realidad, la mayoría son cosas simples. Por ejemplo, los nuevos elementos que ayudan a describir el contenido van a hacer la búsqueda muchísimo más potente. También hay APIs muy útiles, como la API File.

Genbeta: Acabamos de ver a Google lanzar una línea de ordenadores alrededor de un navegador convertido en SO. ¿Qué piensas en cuanto a HTML reemplazando todo el SO?

Paul Cotton: Es una estrategia corporativa interesante. Cuantos más ojos lleve a Internet, más se lleva por anuncios. Así que cuantas más cosas se puedan hacer en Internet, mejor para ellos. Productos como Gmail son ideas innnovadoras, en el sentido de que la gente ha intentado llevar a cabo esas ideas antes pero no han tenido éxito. A nosotros nos gusta la competencia, y de hecho estamos compitiendo con la plataforma web de Office. Pero el núcleo de la pregunta es: ¿podemos crear un sistema operativo con HTML5? Es una pregunta difícil. Por ejemplo, en Windows hay unas 20.000 APIs. Eso es porque Windows ofrece una funcionalidad muy rica a través de .NET. Sin embargo, ¿cuántas son realmente necesarias para que un desarrollador pueda crear su programa en la nube? No creo saber la respuesta. También hay otro aspecto: los usuarios no se preocupan de si es una web o una aplicación. Creo que es una zona donde Microsoft y Google van a competir de forma bastante agresiva.

HTML5 podría llegar en 2014. Sin embargo, cuando HTML5 esté hecho, estaremos preparando HTML.Next. Es decir, que HTML nunca va a estar acabado.

Genbeta: HTML5 es todavía un borrador, no un estándar completo del W3C. ¿Cuándo cree que tendremos la versión final?

Paul Cotton: Habéis sacado mi mejor respuesta. Ahora mismo, hay una encuesta que abrimos el domingo 15 para llevar el estado de HTML5 a Last Call, tal y como estaba planeado desde agosto. La encuesta se cierra el domingo 22, y si tiene éxito (que parece que lo tendrá) habría que esperar unos 12 meses para pasar los dos Last Call y estabilizar la especificación. Hay que tener en cuenta también a los nuevos miembros en el W3C, como los fabricantes de televisores o incluso Disney, así que tendremos bastantes comentarios en el primer Last Call y como resultado seguramente salga un segundo Last Call. El último estado es la “llamada a la implementación”. Ahí necesitaremos una suite de tests. Deberíamos tener entre 75.000 y 100.000 tests, así podemos asegurar la compatibilidad entre todos los navegadores. En resumen, HTML5 podría llegar en 2014. Sin embargo, cuando HTML5 esté hecho, estaremos preparando lo que hemos llamado HTML.Next. Es decir, que HTML nunca va a estar acabado.

Hasta aquí la primera parte de la entrevista. Dentro de poco mi compañero Javier os traerá la segunda, con preguntas sobre HTML5 y el W3C, e incluso alguna relacionada con Minority Report.

Si eres de los que se asombra viendo lo que se puede conseguir con las nuevas tecnologías web pero se asusta en cuanto ve interminables líneas de código CSS puede que esto te interese. Desde Applesfera nos llega Hype, una aplicación para Mac OS X con la que podemos crear páginas web con efectos y animaciones de forma completamente visual y sin depender de Flash.

Normalmente, si queremos aplicar una animación usando HTML y CSS, hay que escribir irremediablemente no pocas líneas de código. Hype lo evita con un sencillo sistema que graba las acciones que realicemos en la plantilla de diseño de nuestra web y aplica las transiciones necesarias de forma completamente automática. El resultado es un portal en internet que cumple con los estándares y es visible desde cualquier dispositivo, incluyendo los terminales móviles de Apple con iOS.

Hype está disponible en exclusiva en la Mac App Store, que requiere tener instalada la versión 10.6.6 o superior. Su precio es de 23,99 euros, lo que convierte a la aplicación en una herramienta enfocada a desarrolladores que necesiten crear una página web de forma rápida con un estilo muy visual más propio de si estuviésemos usando Adobe Flash.

Vía | Applesfera
Sitio oficial | Hype
Descarga | Hype en la Mac App Store

Adobe ha lanzado recientemente la versión 5.5 de su Creative Suite, cuya quinta gran versión vio la luz hace ya casi un año. Lo importante en esta versión no son las novedades que puedan incluir las aplicaciones que forman este paquete para diseñadores y profesionales, sino los nuevos enfoques que plantea de cara al futuro.

En primer lugar, las mejoras incluidas se centran muchísimo en potenciar los estándares HTML 5 y CSS3. Ahora podemos exportar libros en formato ePub con un gran contenido multimedia en InDesign, Flash Pro soporta las últimas versiones de Flash Player y Adobe AIR, hay mejoras en el motor de Mercury, Adobe Audition se ejecuta de forma nativa en Mac OS X y Dreamweaver incluye muchas mejoras para ser compatible con los estándares web (sobretodo afinando los efectos que potencian las transiciones CSS3).

Lo más importante es quizás el lanzamiento de Adobe Photoshop Touch SDK, un entorno de desarrollo pensado para las interfaces táctiles con las que cuentan los smartphones y tablets del mercado actual. Gracias a él, todos los programadores que quieran podrán hacer que sus aplicaciones se integren con Photoshop y sus servicios. Un ejemplo de estas aplicaciones son las mismas Nav, Color Lava y Eazel que Adobe ha lanzado para demostrar la potencia de ese SDK: la idea es que mientras el ordenador se encargue de procesar todo el trabajo con su procesador más potente, otros dispositivos como un tablet puedan usarse para manipular el trabajo que estemos haciendo. Por ejemplo, podemos mezclar y crear colores a nuestro gusto desde un iPad con Adobe Color Lava y usarlos a través de la red local en el Photoshop de nuestro ordenador.

Estas tres aplicaciones de Adobe tienen un precio: 2,99 dólares para Color Lava, 4,99 para Eazel y 1,99 para Nav. Se podría decir que sirven como accesorios para aquellos que tienen accesorios como un iPad, al mismo tiempo que Adobe va ampliando fronteras hacia más allá de los ordenadores convencionales. Las aplicaciones no están disponibles (espero que de momento) en la App Store española de iTunes.

Y ya que estamos hablando de precios: con el lanzamiento de Creative Suite 5.5 la compañía ha aprovechado para proponer otra forma de pagar la licencia de estas aplicaciones con un servicio de suscripción. Pongámonos en el ejemplo de una licencia de Photoshop: una licencia tiene un precio de 699 dólares (o 199 dólares si estamos actualizando), pero a partir de ahora podremos pagar 29 dólares al mes contratando una suscripción anual para poder usarlo legalmente. Si no queremos comprometernos durante un año a pagar esa mensualidad, podemos elegir un “alquiler” de una licencia por 49 dólares mensuales.

No está mal para poder probar la aplicación antes de comprarla, aunque quizás para las empresas que quieran alquilar para después comprar no sea muy rentable teniendo en cuenta los precios completos de las licencias (el precio de la Master Collection se va a unos prohibitivos 2600 dólares). Eso sí, si ya teníamos la versión 5 de la suite la actualización a la versión 5.5 es completamente gratuita, ya que se considera una novedad de mitad de ciclo, ciclo que se completará con la llegada al mercado de la Creative Suite 6.

Vía | CNET
Sitio oficial | Adobe Creative Suite 5.5
Más información | Adobe Photoshop Touch SDK

Mozilla acaba de anunciar oficialmente la versión 4 de Firefox en su blog, y como hicimos con Internet Explorer 9 en su día os traemos un análisis a fondo de todas las características de esta nueva versión de Firefox.

Firefox 4 es fruto de mucho tiempo de desarrollo: empezamos a ver los primeros mockups a finales del 2009, y un año y unos meses más tarde tenemos la versión final, con muchas características que se han caído pero con un rediseño total de la interfaz y un navegador muchísimo más moderno. Vamos a ver cuáles son esos cambios

Una interfaz totalmente rediseñada

Lo primero que vemos al abrir Firefox es su nueva interfaz, muchísimo más compacta que en la versión 3.6. Las pestañas ahora son rectangulares y están colocadas en la parte superior. El menú puede eliminarse y se convierte en un botón en la esquina superior izquierda, al estilo de Opera.

Además, se elimina la barra de estado inferior, que sólo aparecerá cuando estemos cargando la página o tengamos el ratón sobre un link, de forma similar a lo que hace Chrome.

Otra novedad importante es la llamada In-Content UI de la que os hablamos hace un tiempo. Finalmente sólo ha sido adoptada en el menú de complementos, mientras que el resto de menús siguen apareciendo en una ventana aparte.

Podríamos resumir la nueva interfaz como una mezcla de interfaces del resto de navegadores. En realidad esto no es nada malo porque, aparte de que todos lo hacen (mirad por ejemplo la barra de pestañas de los navegadores: apenas se distinguen en unos pequeños cambios de forma o de color), Firefox ha conseguido tener una interfaz buena, bonita y funcional, que al final es lo que realmente importa al usuario.

Nuevas formas de gestionar las pestañas

Con Firefox 4 llega un nuevo sistema de gestión de pestañas. Por un lado tenemos las pestañas de aplicación, también llamadas fijas o pinned tabs según el navegador que uséis. Podemos fijarlas pulsando en el botón derecho y después en “Fijar pestaña”. Resultan muy útiles cuando tenemos una pestaña siempre de fondo, como pueda ser la del correo o de alguna red social: siempre están en el mismo sitio y no se cierran si pulsamos “Cerrar todas las demás pestañas”.

También está Panorama (que empezó llamándose Tab Candy) que nos permite gestionar visualmente las pestañas agrupándolas a través de una interfaz visual muy llamativa. Personalmente, aunque es muy bonito y moderno no le encuentro demasiada utilidad: para agrupar pestañas es demasiado engorroso, y el hecho de ponerle nombres a las pestañas tampoco me aporta demasiado. Eso sí, seguro que alguien le puede sacar buen partido, de eso no me cabe ninguna duda.

Lo que sí encuentro útil es la nueva forma que han introducido para cambiar pestañas: en la barra de direcciones. Así, sólo con teclear el nombre de una pestaña en la barra podremos cambiar a ella pulsando intro, como veis en la siguiente imagen:

Firefox: navegación muy segura y privada

Aunque Firefox no es de los navegadores con más fallos de seguridad o privacidad graves, Mozilla se ha seguido preocupando para que Firefox proporcione una navegación privada y segura. Como muestra tenemos la implementación de Do Not Track, que podéis activar en Opciones -> Avanzado -> General y que le dice a los sitios web que no quieres ser rastreado.

También han incluido CSP y HSTS. Detrás de estas siglas se esconden dos sistemas de seguridad que tratan de evitar el clickjacking y ataques XSS, y los ataques man in the middle obligando a establecer conexiones seguras por el otro. Si tenéis curiosidad por saber cómo funcionan podéis mirar los documentos técnicos, en inglés, sobre CSP y HSTS.

Soporte total de HTML5

Aunque estos cambios no los veamos, también son bastante importantes. En la versión 4, los chicos de Mozilla se han preocupado por soportar a la perfección HTML5 y han incluido, entre otras cosas, los códecs de WebM para vídeo HD, los nuevos formularios HTML5, los gráficos 3D a través de WebGL y CSS3.

Han añadido la API de audio, que permite a los desarrolladores de webs leer y manipular los sonidos de las etiquetas audio. También han dado más control a los desarrolladores para manipular el tipo de fuente, y ahora permiten usar gráficos SVG como imágenes normales con el consiguiente aumento de velocidad (los gráficos SVG son muchísimo más ligeros que cualquier otro tipo de imagen) y de calidad.

Firefox 4, rápido como una bala

Una de las cosas que más se criticaban de Firefox era su lentitud y pesadez. Los chicos de Mozilla se han preocupado bastante por corregir esto, y como podéis ver en la imagen de arriba han conseguido unos resultados bastante buenos.

Han mejorado prácticamente todos los aspectos de Firefox para hacerlos más rápidos: XPCOM (complementos), scroll de páginas (ahora es realmente fluido), Javascript y gráficos (aceleración por hardware en Windows, Linux y Mac). La verdad es que el inicio aunque no sea instantáneo es bastante rápido, y en general el navegador va muy bien, sin problemas de rendimiento.

En cuanto al consumo de memoria no se dispara demasiado: ahora mismo consume 175MB con 7 pestañas, mientras que Chrome (por poner un ejemplo) con 8 pestañas pasa de 300MB. En realidad, si tenéis un ordenador moderno con memoria suficiente (yo tengo 2GB) el consumo de RAM ya no debería importaros demasiado, ya que entra en juego el concepto “Unused RAM is wasted RAM”.

Lo que viene a decir esto es que si el navegador consume más RAM es que tiene más elementos “en caché”. Desde esa “caché” puede acceder más rápidamente a los elementos. Si no los tuviese en la RAM tendría primero que acceder a los elementos en el disco, cargarlos en RAM y después usarlos. En resumen, que con un ordenador moderno lo mejor que podéis hacer es olvidaros del consumo de RAM.

Firefox Sync de serie, sincroniza datos entre todos tus Firefox

Otra de las características que trae Firefox es Sync. Aunque ya llevaba tiempo con el nombre de Weave y en forma de extensión, Mozilla lo incluye ahora de serie. Con él podemos sincronizar todos los datos del navegador: contraseñas, preferencias, marcadores, historial y pestañas; aunque se echa de menos la sincronización de extensiones.

Tenemos que crearnos una cuenta de Sync para poder usarlo, aunque esto no es demasiado inconveniente. Para sincronizar en móviles (Android o Firefox Home en iPhone) tendremos que introducir en el navegador del ordenador un código que aparece en el dispositivo y que vincula automáticamente el navegador a la cuenta.

Otros cambios: Consola Web, instalación de extensiones sin reiniciar y multitouch en Windows 7

Además de los cambios más llamativos, también hay algunos cambios menos llamativos para el usuario normal, pero que no dejan de ser importantes. Por ejemplo, ahora hay una nueva consola de errores, la Consola Web, que muestra en tiempo real toda la actividad de una página: registro de peticiones HTTP y errores en Javascript y CSS.

En relación con las extensiones, Firefox permite ahora instalarlas sin reiniciar, además de que han incluido la SDK de Jetpack para hacer el desarrollo más sencillo.

Otro cambio es la inclusión de soporte multitouch en Windows 7, de forma que las páginas pueden aprovechar la entrada con varios dedos, tal y como podéis ver en el vídeo de arriba.

Conclusiones: un buen trabajo, pero todavía le falta algún detalle

El cambio desde Firefox 3.6 es brutal, es un navegador totalmente nuevo. Es rápido, fluido, cómodo, seguro, moderno, potente… Sin embargo, para mí gusto todavía tiene que mejorar algún detalle. Por ejemplo, si sois usuarios de Linux lo veréis a la primera: la interfaz sigue siendo horrible en este sistema, sobre todo en KDE. En GNOME puede tener un pase, aunque sigue habiendo una diferencia gigantesca con la de Windows.

También le falta integrar todos los menús con el InContent-UI: al final resulta más cómodo que los menús tradicionales, y visualmente son más atractivos (al menos en los mockups que nos enseñaron).

Pero a pesar de estos detalles, y como digo arriba, Firefox 4 es un navegador muy bueno que ha conseguido recuperar todo el terreno que le llevaban el resto de navegadores, incluso ganando en algunos aspectos. Os animo a probarlo, si no habíais usado las versiones de desarrollo os vais a llevar una verdadera sorpresa.

Vía | Mozilla Blog
Vídeo | Vimeo
Descarga | Firefox 4

Bonus: ¿Queréis saber cómo van las descargas de Firefox? Mozilla ha desarrollado esta página que muestra las descargas de Firefox 4 en todo el mundo.

Bonus 2: Xallow nos avisa sobre la página de demos de Mozilla, donde podéis ver en funcionamiento (y probar) las nuevas características de Firefox 4.

Los desarrolladores de Opera siguen pegando fuerte y avanzan rápidamente con el desarrollo de su navegador: ya está disponible una versión para desarrolladores de Opera 10.7, con mejoras enfocadas en la compatibilidad con los nuevos estándares HTML5 y CSS3.

Concretamente Opera 10.7 agrega compatibilidad con la propiedad HashChangeEvent de HTML5 y con las propiedades de CSS3 image-fit e image-position, lo cual hará que más bien los desarrolladores web, maquetadores y diseñadores quieran probar esta nueva versión.

De momento Opera 10.7 viene con la advertencia de que es una versión inestable y sólo destinada a pruebas, de modo que no recomendamos que se instale y use como navegador principal. De todos modos, siempre podemos saciar nuestra curiosidad con esta nueva versión que demuestra una vez más que Opera no va en broma en cuanto a su desarrollo.

Vía | Opera Desktop Team