Contenido

Zen Coding, una nueva forma de crear HTML con Javascript

5 May

+ 26

Zen Coding es un plugin para casi todos los editores webs disponibles que nos permitirá generar HTML/XML/XSL de una forma mucho más rápida que de cualquier otra. Aunque no es nuevo, lo descubro ahora gracias a Marcel que por mail me lo ha recomendado y aún me estoy dando golpes en la cabeza por no haberlo descubierto antes, es realmente cómodo y rápido.

¿En que consiste?

Zend Coding intenta ayudarnos a escribir HTML haciendo que no sea necesario abrir y cerrar tags tecleando todos los carácteres para ellos usaremos un sistema similar al siguiente:

div#page>div.logo+ul#navigation>li*5>a

Como vemos, recuerda mucho al nuevo selector DOM de MooTools 1.3 Beta. Mediante esa sintaxis podemos ver este código nos generará el siguiente HTML:

<div id="page">
 <div class="logo"></div>
 <ul id="navigation">
 <li><a href=""></a></li>
 <li><a href=""></a></li>
 <li><a href=""></a></li>
 <li><a href=""></a></li>
 <li><a href=""></a></li>
 </ul>
</div>

¿Rápido verdad? Pruebalo tu mismo.

Elige el plugin para tu editor preferido

El proyecto alojado en Google Code además dispone de una gran cantidad de plugins, al menos uno para cualquier editor web que se te pueda ocurrir. Así que elige el que quieras y ponte a desarrollar más rápido que nunca 😀

Prepara tu página para el iPad

3 Abr

+ 14

Bueno, parece que poco a poco los dispositivos táctiles comienzan a invadirnos. Algo que era de esperar, después de la aceptación que tanto el iPhone como dispositivos Android están teniendo en el mercado móvil. Poco a poco estas herramientas empezarán a estar sobre los sofás de cualquier geek.

Por este motivo no parece descabellado revisar un poco nuestro código para que nuestras páginas se adapten a la nueva resolución de pantalla que el iPad usará.

¿Que necesitamos saber?

Apple, como ya hizo con su iPhone, nos ha facilitado una serie de recomendaciones e información referente al iPad para que los desarrolladores web no tengamos muchos problemas en la adaptación.

Viewport

Si para la versión de tu web para el iPhone indicaste un viewport con un valor fijo en pixels tendrás que cambiarlo ya que la nueva versión dispone de una variable que indica el tamaño del dispositivo y nos evita tener que intuirlo o detectarlo nosotros mismos.

// Antes
<meta name="viewport" content="width=320" /> <!--- WRONG //--->

// Ahora
<meta name="viewport" content="width=device-width" />

Solucionando posiciones fixed CSS

El conocido position:fixed; no funciona de igual forma en Safari, iPhone e iPad por ese motivo debemos tener especial cuidado al usarlo.

En Safari (sobre OSX y Windows) siempre mantiene el elemento fixed en pantalla, sobre iPhone e iPad esto no ocurre ya que el usuario puede ampliar o reducir la página haciendo que el elemento salga del foco visible. El posicionamiento fijo usa el visor como bloque de contención para estos elementos fixed.

En Safari, al redimensionar la pantalla todo se redimensiona, en el iPhone/iPad no podemos reducir la pantalla, únicamente podemos atacar al contenido y este si puede crecer o decrecer.

User Agent

El nuevo User-Agent que tendremos que conocer será el siguiente:

Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10

¿Como testear con Safari en nuestro sobremesa?

Usando el anterior User-Agent, podemos especificarle a Safari que nos identifique con si de un iPad se tratara. Simplemente tendremos que acceder al menú Desarrollo  (sino lo tenemos, lo activamos desde Preferencias > Advanzado > «Mostrar el menú Desarrollo en la barra de menús») e indicamos el user-agent del iPad en Desarrollo > Agente de usuario > Otra…

safari-ipad
(Ver Imagen)

Resultado

Usando esta configuración en Safari podemos disfrutar de la versión iPad en nuestro gMail, por ahora solo en Safari, no he probado con ningún plugin que cambie el User-Agent de Firefox.

gmail-ipad
(Ver Imagen)

Ya no hay excusas 😀

Flash vs HTML5, pongámoslos a prueba

22 Mar

+ 75

Se habla mucho de que HTML5 va a matar a Flash, y que las nuevas tecnologías que se están integrando en los nuevos estándares ofrecen versiones compatibles muy superiores a lo que ahora podemos conseguir con flash.

Pero la gente de Man in Blue, no se contentó con solo leer lo que otros opinaban, así que se han puesto manos a la obra para realizar un benchmark entre los diferentes lenguajes disponibles.

flash-vs-html5
(Ver Imagen)

En el ejemplo ha usado una aplicación que genera partículas aleatorias y las mueve por la página caóticamente haciendo trabajar el procesador de nuestra máquina.

Podemos verla funcionando en:

Los resultados

graph_win_ie
(Ver Imagen)
graph_win_chrome
(Ver Imagen)
graph_osx_safari
(Ver Imagen)
graph_osx_ff
(Ver Imagen)

Como podemos ver en las gráficas, la superioridad de Flash está latente en todos los navegadores. Da igual el número de partículas que se usen, los resultados, actualmente, son muy superiores a los conseguidos con las otras alternativas.

«Han ganado esta batalla, pero aún no han ganado la guerra«, con esta frase expreso lo que siento al ver estos resultados. Flash está ahí, y poco a poco esto debería de ir cambiando. Tendremos que estar atentos 😀

El src de una imágen puede cargarse tu página

1 Dic

+ 4

Nicholas C.Zakas publica un artículo que muestra que cada navegador interpreta los estándares web como quiere. En este caso nos pone un ejemplo:

<img src="" />

y el mismo en Javascript

var img = new Image();
img.src = "";

En los ejemplos vemos que creamos un tag <img /> (en Javascript un objeto Image()) al que no le indicamos la ruta de la imagen.

Estudiando el resultado en los diferentes navegadores, ha descubierto que partiendo de la URL http://www.ejemplo.com/bla/ejemplo.html se diferencian dos resultados:

  • Internet Explorer: Realiza una única petición al directorio en el que está alojada la página.
  • Firefox, Safari y Chrome: Realizan una petición a la misma página que hace la petición.
  • Opera: No hace nada.

El caso que nos preocupa sería el provocado por Firefox, Safari y Chrome, ya que al volver a cargar la página que está ejecutando la petición cargará otra nueva versión de la página que provocará el mismo problema al volver a ejecutar la petición de nuevo y así hasta que el servidor aguante. A mayor número de visitas mayor número de peticiones.

Este problema que parece muy concreto puede darse fácilmente con una construcción php tan simple como esta:

<img src="$imageUrl" >

Aunque Nicholas nos propone una solución en PHP que mediante htaccess redirigimos todas las imágenes por una página PHP que comprueba que el referrer sea diferente al de la página.

<?php
    //Works for IE only when using path URLs and not file URLs

    //get the referrer
    $referrer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '';

    //current URL (assuming HTTP and default port)
    $url = "http://" . $_SERVER['HTTP_HOST']  . $_SERVER['REQUEST_URI'];

    //make sure they're not the same
    if ($referrer == $url){
        exit;
    }
?>

Esta solución, aunque no es muy apropiada ya que nos va a ejecutar este código por cada imagen que usemos en nuestra página, nos permite salir del paso mientras los navegadores se van actualizando, cosa que ya están haciendo.

NimbleKit, aplicaciones nativa para iPhone con HTML y JS

27 May

+ 3

NimbleKit es una extensión de Xcode con el que podremos desarrollar aplicaciones para el iPhone/iPod Touch pero sin necesidad de saber Object C. Se trata de intentar hacer que los desarrolladores web tengamos posibilidad de realizar estas aplicaciones e incluso subirlas al App Store de Apple. Todo ello, desarrolllando como lo venimos haciendo, usando tecnologías como HTML y Javascript.

road-map
(Ver Imagen)

Dispone de una serie de funciones que activarán los elementos nativos del dispositivo. Además de …

  • Control completo de la apariencia de la aplicación
  • Posibilidad de reproducir sonido en streaming
  • Controlar la vibración
  • Soporte de la Agenda
  • Acceso a ficheros
  • Acceso a Internet

actuR.com, optimizador de código

20 May

+ 7

Carlos Sanches me avisa via email sobre la nueva aplicación en la que ha estado trabajando. acutR.com, un optimizador de código que nos permite desde optimizar código HTML hasta minimizar nuestro código CSS. Muy recomendable para ahorrarnos esos minutos de depuración 😀

De Photoshop a XHTML/CSS paso a paso

13 May

+ 5

Una de las tareas que los maquetadores hacemos más a menudo es convertir un diseño en Photoshop a una página xHTML con su CSS. Esta tarea aunque parece simplemente hacer 4 cortes tiene su miga y este tutorial es la muestra de ello.

Introducción a los W3C Widgets

22 Abr

+ 3

Hace 3 años que vimos las primeras noticias sobre el borraror de la W3C sobre los Widgets. Y ya entonces vimos que el tema prometía. QuirksBlog nos muestra una introducción sobre como usar estos Widgets.

¿Que es un widget?

Esencialmente un Widget es un conjunto de HTML/CSS/Javascript locales. Decimos locales, por que una vez que, por ejemplo, un movil descarga un widget debe ser capaz de usarlo localmente, al quedar instalado en él.

Aunque actualmente la utilización de widgets es muy límitada, lectores de RSS, relojes,… no hay razones teóricas de que no puedan ser capaces de crear aplicaciones basadas en Javascript realmente complejas, por ejemplo una Hoja de Cálculo.

La belleza de este modelo, es que aunque una aplicación requisiera 200kb de Javascript, más una serie de librerías, el usuario únicamente tendrá que descargarlo una sola vez. Después de la descarga, la aplicación se instala y las próximas veces se ejecutará en local sin necesidad de descargar nada.

En caso de requerir cualquier dato externo al widget, dispone de una interface que nos permite realizar peticiones Ajax y cargar el contenido en el momento que lo necesitamos.

Los W3C Widgets nacen como estandarización a los ya existentes creados para dispositivos como el iPhone, móviles Android, … que usan sistemas propietarios y únicamente adaptables a sus dispositivos. Con W3C Widgets se intenta crear un sistema que permita la interoperatividad de estos widgets en diferentes dispositivos sin necesidad de tener que modificar una sola línea de código del widget. Y todo ello aprovechando las técnicas HTML/CSS/Javascript que los desarrolladores conocemos.

En fin, los W3C Widgets apuntan como el futuro de la web movil. Son fáciles de crear, usan estándares abiertos y se ajustan al mínimo consumo de la red.

Información técnica

Los Widgets no son más que sitios web comprimidos. Creamos un fichero HTML, le añadimos los estilos necesarios en ficheros CSS y la funcionalidad viene dada en ficheros Javascript. Todo ello comprimir en un fichero zip, al que le cambiaremos la extensión a .wgt y listo. ¿Sencillo verdad?

Actualmente la especificación está continua como Working Draft (Borrador) modificado últimamente el día 5 de Febrero de 2009. Aunque el proceso está siendo tan lento como la W3C ya están las bases muy bien definidas.
Continua —>

JSHTML, contenido HTML generado con Javascript no obstructivo

16 Abr

+ 4

JSHTML, es una propuesta de James Padolsey para generar HTML mediante Javascript de una forma dinámica y no obstructiva.

<div id="content">
    <!-- JSHTML {{
        <ul id="controls">
            <li><a href="#add">Add content</a></li>
            <li><a href="#print">Print this</a></li>
        </ul>
    }} -->
    <p>Lorem ipsum dolor...</p>
</div>
// Javascript
JSHTML.parse();

De esta forma conseguimos ocultar el contenido del comentario a los usuarios que no disponen de Javascript. Sin provocar que la aplicación deje de funcionar.

Se trata de un <noscript /> inverso desarrollado en Javascript. Que seguro que alguna utilidad encontraremos para él 😀

Podéis ver un ejemplo aquí y revisar el código que se encarga de convertir el comentario en HTML.

12 principios para mantener tu código limpio

13 Nov

+ 18

Durante la evolución de un proyecto tendemos, sin darnos cuenta, a ensuciar nuestro código. Ya sea aplicando parches a los fallos encontrados o añadiendo nuevas funcionalidades no pensadas previamente. Por ese motivo conocer algunos principios básicos nos pueden ayudar a crear un código que se mantenga en el tiempo igual que el primer día.

1) Doctype STRICT

Si ya tienes algo de soltura deberías apostar por STRICT para definir en el doctype de tu web. De esta forma estarás asegurándote un poco más de tiempo con un doctype válido.

2) Cuidado con el carácter & (&amp;) y demás carácteres especiales

Los carácteres especiales en el texto deben ir siempre codificados según el estandard, así conseguimos que nuestro código sea limpio y evitamos producir errores innecesarios y fáciles de solventar en el validador de la W3C.

3) Indentación, Indentación … indentación

Por encima de la eficiencia del código, la mayoría de proyectos deben ser claros y fáciles de interpretar por cualquiera. Piensa que no sabes si dentro de 3 meses o 5 años, vas a tener que volver a tocar el código. Así que dedícate un tiempo para indentar el código y dejarlo claro.

4) Separa el contenido de la funcionalidad y el diseño

No me cansaré de decir que la separación de capas es algo primordial, al igual que la identación ayuda a la comprensión del código, la separación de las diferentes capas ayuda a conocer donde está ubicada cada parte de la web. Sin contar que conseguir idependizarlas, lo que nos permite modificar cualquiera de ellas afectando a las demás sin necesidad de modificar las demás.

5) Usa los tags correctamente

Conocer las propiedades de los tags HTML permitirá que hagamos un código más semántico y sobretodo estandar. Es importante usar los tags correctamente ya que aunque el navegador permita mostrar el contenido como nosotros queremos mostrarlo, la estructura correcta nos ayudaría en terminos de SEO…

6) Elimina elementos innecesarios

Por desgracia al pasar del diseño en tablas al diseño con divs, podemos caer en una etapa de «divitis» que nos hace usar div’s para todo. No debemos usar elementos innecesarios para conseguir lo mismo que conseguiríamos con menos elementos. Este punto hace refecia directa al punto 5.

7) Piensa bien los nombres que usas

En muchos casos tendemos a usar nombres poco descriptivos a demasiado descriptivos. Este ejemplo muestra ua muestra clara de lo que quiero decir:

cleancode-7

8 ) Deja la tipografía a los CSS

Debemos pensar que el diseño lo controla el CSS, y por ello todo lo relacionado con él debe ir reflejado en los ficheros CSS. Por ejemplo, el texto en mayusculas podemos solventarlo con text-transform: uppercase;

9) Class/ID en el <body />

Una forma de conseguir mayor flexibilidad en nuestros CSS es usar id/class en nuestros elementos <body />. De esta forma podemos variar el diseño de ciertos elementos dependiendo dle tipo de body que especifiquemos.

10) Validación

La validación de nuestro código es más que poner un icono en la parte inferior. La validación nos ayuda a completar unos aspectos básicos que los diseños web deben cumplir. No implica que un desarrollo esté mejor o peor hecho, sinó que nos ayuda a conguir un mínimo imprescindible para diferenciarnos del código generado por un programa (Frontpage,…).

11) Aplícale lógica a la estructura

Hemos de pensar que el código se ha de leer de arriba hacia abajo y que siguiendo esta premisa debemos generar una estructura colocando elementos seguidos unos a otros de una forma lógica. Hemos de pensar 2 veces si colocamos un elemento en esa posición o lo ponemos en otra.

cleancode-11

12) Haz lo que puedas

El esfuerzo se nota y aunque no sea a la primera, ni a la segunda, llega un momento en el que ese esfuerzo se acaba recompensando. Simplemente hemos de ser pacientes y esperar a que ese momento llegue.