Posts Tagged ‘estandares’

Dom vs innerHTML: ¿Cuál es más rápido?

Tuesday, October 7th, 2008

Gracias a un enlace que recomienda en su blog Olga Carreras, me entero de un interesante estudio de rendimiento (Benchmarking) que hacen en Quirksmode para averiguar qué métodos son más rápidos para generar grandes cantidades de contenido.

El resultado es bastante espectacular: innerHTML es bastante más rápido en todos los navegadores.

Hay que tener encuenta que innerHTML no es un método estándar, no está desarrollado ni estandarizado por la W3C, sino que fué diseñado e implementado por primera vez por Microsoft en su Internet Explorer.

Pero  entiendo el dilema de un programador que use grandes cantidades de datos y quiera que su aplicación vaya rápido ¿Debe pasarse el estándar por el forro?…

Yo sigo maquetando con Dreamweaver ¿Y tú?

Saturday, September 27th, 2008

Aprovechando la inminente salida de la nueva generación de aplicaciones de Adobe quiero tocar este tema que siempre suscita cierta controversia cuando hablamos entre desarrolladores web.

No escribo este post para defender a Dreamweaver como la mejor herramienta para maquetar. Ni siquiera sé si lo és, ni me importa demasiado. Lo que es evidente es que desde que comencé en esto de la maquetación trabajo con él (tras un efímero comienzo con Adobe Golive) y que he ido probando otras herramientas a lo largo de estos años pero al final siempre vuelvo a los brazos de Dreamweaver.

Y aclaro también que mi defensa es como herramienta para maquetación, no para programación. Posiblemente un programador PHP se encuentre mucho más cómodo en un sistema que le permite explorar sus clases, debuguear su código dentro de lo posible y que le ayude un poco más a la hora de programar… desde luego para ese tipo de trabajo Aptana parece una alternativa más seria.

Personalmente uso Dreamweaver para el desarrollo de las maquetas desde 0. En ese momento en que me pasan el diseño y tengo que convertirlo a código abro dreamweaver y me pongo a trabajar. Una vez que he maquetado mis plantillas dejo de usarlo.

A partir de ese momento, para debuguear, corregir o hacer cambios que me propongan los designers… uso otras herramientas: concretamente la combinación Transmit + Bbedit + Firefox / firebug es mi opción básica en Mac y trabajando en Windows Filezilla con Notepad++; por supuesto siempre está la opción básica y salvavidas de trabajar directamente en el servidor con Vi.

¿Por qué me encuentro cómodo maquetando con Dreamweaver?

Su maravillosa integración con el gestor de FTP: el gestor en sí no es de lo mejor y es frecuente que se atasque… pero a mi me gustra trabajar en local, guardar y subir al servidor. Una vez configurado el sitio remoto la combinación de teclas Cmd + Mayus + U (o Ctrl en windows) me resulta bestialmente cómoda… y el hecho de que me avise de que “hay una versión más reciente en el servidor” del archivo que estoy editando me da una gran seguridad.

La vista mixta diseño / código me resulta esencial. Eso de poder seleccionar un elemento en la vista diseño y que me lo marque en código me ayuda muchísimo. La vista diseño integrada es algo que no he visto en ningún otro editor; normalmente el resto se limitan a incorporar un navegador para previsualizar, pero no se puede interactuar con él.

El editor de código, que no es el mejor, pero  es muy aceptable tanto para HTML como para CSS gracias. Con el sistema de sugerencias para atributos y propiedades y el cierre automático de etiquetas me basta. Aunque echo muchísimo de menos, y me revienta, su incapacidad para detectar  dónde se cierra una etiqueta, llave o paréntesis al seleccionarla. Eso casi me hace pasarme a Aptana.

Son 3 tonterías, lo sé, pero a mi me hacen mi trabajo mucho más facil. Dreamweaver tiene mil funcionalidades más que no uso para nada pero esos detalles unidos a un interfaz de usuario en general muy muy cómoda en casi todos sus aspectos hacen que me sienta bien trabajando con él.

Finalizando

Este post no es para recomendar Dreamweaver a los maquetadores, sobre todo porque hay alternativas gratuitas que son muy buenas; para mi la mejor posibilidad, con diferencia, es Aptana. Es simplemente la exposición de un hecho que estoy seguro que muchos maquetadores comparten.

Un disclaimer: vaya a pensarse alguién que tengo que ver algo con Adobe, ojalá, pero no; tampoco patrocinan este post ;)

PD: a lo mejor algún día hablo de porqué uso Fireworks y no Photoshop :)

PD2: verás como aparece por aquí la clásica y estéril discusión “Yo programo con notepad”… Dreamweaver es para débiles y lamers.

¿HTML5 para el 2022?

Saturday, September 13th, 2008

Nueva polémica alrededor el futuro del estandar HTML. No quiero ser sensacionalista aunque el titular lo parezca y me gustaría empezar asegurando que el HTML5 o al menos buena parte de este estándar se estará usando fluidamente bastante antes de esa fecha. De hecho algunas especificaciones ya se usan.

Hace unos días mal leía una entrevista una entrevista a Ian Hickson, editor responsable del desarrollo del nuevo estándar HTML5, en TechRepublic. Y digo “mal leía” porque entre que leo a toda ostia, me salto cosas y que la entrevista en era, lógicamente, en inglés, había ciertas cosas que no entendí bien.

En la primera pregunta que responde Ian es relativa al timeline del HTML5, vamos que para cuándo lo tendremos. En su respuesta habla del 2022 como fecha para publicar al propuesta de recomendación final. Ahí está mi gran error, al leer eso no tuve ninguna duda de que era una broma… no le hice ni puto caso al tema vamos. Pues resulta que parece que hablaba en serio.

Pero como siempre estas cosas hay que leerlas con atención y saber interpretarlas, cosa a veces muy difícil en lo referente a la w3c. Los estándares de esta organización pasan por bastantes fases y además de componen de multitud de módulos. Lo que estará en 2022 será la recomendación final, es decir, totalmente terminado. Pero no es necesario que esté totalmente terminado para ser implementado. De hecho hay ya elementos como canvas, embed o video que ya los soportan varios navegadores (por lo que sé Opera es el más adelandado a este respecto)

Todo esto ha generado, evidentemente, una importante polémica:

  • Entrevista a Ian Hickson: donde hace el polémico timeline
  • Jeff Croft se cabrea
  • WATHWG responde: quita importancia a la polémica y asegura que puede ser que todo este 100% finalizado en 2022 pero para esa fecha habrá incluso módulos de HTML6. Dependerá de los navegadores cuándo empecemos a usar el 5

Y ciertamente estoy de acuerdo con esto último. El tema depende principalmente de los desarrolladores de navegadores, a los que recientemente se ha incorporado Google y soy optimista respecto a la rápida adopción de muchos módulos del estandar por los fabricantes. Mi optimismo se debe a dos razones principales: en primer lugar la aparición de otros navegadores en el mercado que compiten con el de Microsoft (aunque no en igualdad de condiciones) que ha llevado a la segunda guerra de los navegadores. Por otro lado el importante giro que Microsoft dio a Internet Explorer a partir de sacar su versión 7, momento en que empiezan a respetar y tomarse en serio los estándares de la w3c.

La cosa va lenta pero poco a poco vamos como partes de CSS3 y HTML5 van siendo incorporados a los nuevos navegadores e, insisto, no habrá que esperar hasta el 2022.

CSS3, los fondos y bordes del futuro

Thursday, September 11th, 2008

El grupo de trabajo encargado del estandar CSS publican un nuevo borrador de trabajo relativo a los bordes y fondos (backgrounds and borders) CSS3.

Algunos aspectos muy novedosos respecto a los fondos (background)

Vamos a poder poner varias imágenes de fondo en nuestras cajas, puediendo especificar, para cada una de ella, propiedades distintas. Así...

CSS:
  1. background-image: url(flower.png), url(ball.png), url(grass.png);
  2. background-position: center center, 20% 80%, top left;
  3. background-origin: border-box, content-box;

Me gusta también la propiedad "Background-origin", que nos permitirá decidir desde qué punto de nuestra caja se sitúa el fondo, los posibles valores serán:

  • padding-box: posición numérica o porcentual desde el padding de la caja
  • border-box: posición numérica o porcentual desde el borde de la caja
  • content-box: posición numérica o porcentual desde el contenido de la caja

Sombras en las cajas
La propiedad "box-shadow" aplicará una o varias sombras a nuestra caja. Se utilizan cuatro valores numérico:

El primero define el eje horizontal de la sombra, un valor positivo lo aplicaría al lado derecho de la caja, si es negativo lo aplica en el lado izquierdo.

El segundo define el eje vertical donde los valores positivos o negativos aplicarían la sombra arriba o abajo de la caja respectivamente.

El tercer valor hace referencia al difuminado de la caja (blur)

El cuarto valor es el que menos consigo entender, se denomina "spread radius", pero soy incapaz de traducirlo.

CSS:
  1. span {border: thin solid; box-shadow: 0.2em 0.2em #CCC}

Se vería así:

Por último, si a en la propiedad box-shadow especificamos el valor "inset" (es posible que cambie a "inner") las sombras se aplicarán al interior de la caja.

box-shadow.png

Creo que este tipo de cosas nos darán bastante más juego al diseñar nuestras futuras web ¿No os parece?

Actualización: gracias a Omega y Matías sabemos que el Spread radius hace referenica al grado de dispersión o dureza de la sombra.

Sombras en Firefox 3.1

Tuesday, September 2nd, 2008

Se acaba de anunciar que Geckgo 1.9.1, en el que se basa Firefox 3.1, soportará 3 nuevas propiedades CSS3:

  • -moz-box-shadow: dibuja sombras sobre una caja (ej.: -moz-box-shadow: 10px 10px 5px #888, 10px 10px 30px rgba(0,0,0,0.4); )
  • text-shadow: pone sombra a un texto (ej.: 0 0 24px blue, 0 0 4px blue, 1px 1px 2px #333; )
  • -moz-column-rule: permite dibujar una línea de separación entre columnas (en el caso de que estemos usando los columns de css3). Su sintaxis es la misma que la de la propiedad border de css2 (ancho,tipo,color)

Por cierto, en esta página se pueden ver, si usas Safari u Opera, como quedan estas propiedades relacionadas con las sombras.

¡Aprovecha el verano! Aprende sobre los estándares web con Opera.

Thursday, July 31st, 2008

Supporting the Opera Web Standards Curriculum: Learn to build a better Web with Opera

Hace ya unos días que Opera anunció y publicó un interesante proyecto relativo a la formación en estándares web: Opera Web Standards Curriculum. Se trata de un completísimo "curso" para enseñarnos sobre desarrollo web basado en estándares. El curso, por supuesto, está en inglés (idioma que ha que saber al menos leer si uno se dedica a esto profesionalmente).

Hasta el momento han publicado 23 artículos (y prometen 30 más de aquí a septiembre) organizados en apartados como:

  • Introducción al mundo de los estándares web
  • Conceptos sobre diseño web
  • Bases del HTML
  • El núcleo o cuerpo del HTML

Los artículos son obras de gente como Chris Mills o Roger Johansson; gente que sabe mucho sobre desarrollo web estándar y son realmente claros y didácticos.

Un material inestimable para desarrolladores, estudiantes, profesores y para la web en general que Opera nos ofrece de forma completamente gratuita para que usemos como queramos.