Author Archives: admin

PS: Cómo hacer Iconos Handy Web 2.0

[Fuente: http://psd.tutsplus.com/tutorials/interface-tutorials/handy-web-20-icons-in-photoshop/]

Cuando estamos trabajando en el diseño de un proyecto Web, muy a menudo necesitamos iconos para referenciar comandos como add, delete o edit. Con la moda del Web 2.0, el uso de botones con efecto 3D se han hecho muy populares. En este tuto, mostraremos cómo crear ese efecto en los botones o iconos que deseemos que tengan profundidad.

Paso 1

Creamos un nuevo documento y seleccionamos la Herram. Elipse (U). No importa que color utilices porque será reemplazado más tarde con los estilos de capa.

Paso 2:

Hacemos doble click en la capa de la elipse y abrimos la caja de dialogo del Layer Style . Seleccionamos el Gradient Overlay y utilizamos un azul y un sombra ligera de azul para los colores del gradiente. Para el estilo utiliza radial. También añadimos un Bevel and Emboss como mostramos a continuacion:

Truco : mueve el radial gradient más a la parte superior del circulo.

Paso 3

Duplicamos la capa del circulo y la cambiamos de tamaño para hacerla ligeramente más pequeña, como muestra la imagen de abajo.

 

Paso 4

Hacemos doble click sobre la nueva caoa para abrir la caja de dialigo Layer Styles. Quitamos la selección de todos los efectos que teniamos de la capa anterior. Ahora seleccionamos Stroke pra el Fill Type select Gradient. Para los colores seleccionamos blanco por ambos extremos del gradiente y cambiamos la opacidad a 0% para el comienzo y 100% para el final.

Paso 5

Seleccionamos la Horizontal Type Tool (T) y creamos una capa de texto. Nos aeguramos que esta capa este en el top. Abrimos el Layer styles y cambiamos el color overlay a white, y seleccionamos Inner Shadow u tilizamos los settings mostrados a continuación:

 

Paso 6

Agrupamos las tres capas y las llamamos Blue Circle.

Paso 7

Seleccionamos la Herram. Poligono y cambiamos algunos settings como mostramos a continuación para crear una Star Badge.Duplicamos la capa y le cambiamos el size como hicimos en el paso 3.

Instead of applying those layer styles to the layer, just copy the style from the previous icon we created and paste it to our new layer. To do that, select the layer you want to copy the layer style of, right-click on the mouse (Macs: Option-Click) and choose Copy Layer Style. Next select the layer you want to add the style to and right-click again and choose Paste Layer Styles.

The only thing you will have to change will be the gradient colors under the Gradient Overlay.

Conclusion

This is one of the easiest ways to create a cool 3D style button. You can eve change some settings like the stroke’s gradient color and create different 3D styles.

 

Creando un menu animado con jQuery

[Fuente: http://buildinternet.com/2009/01/how-to-make-a-smooth-animated-menu-with-jquery/]

Aqui hay una demo de lo que queremos montar

The Finished Product

Introducción  – Una explicación de easing

Lo que hace que el menu que vamos a montar tenga una smooth animation es un cosa llamada “easing“. Según la definición del Adobe Flash developer center:

“El término easing se refiere a aceleración/deceleración gradual durante una animación, lo cual  ayuda a que tus animaciones parezcan más realistas. Easgin crea una apariencia más natural de aceleración o deceleración ajustando gradualmente el rate de cambio”

Gracias al plugin jQuery Easing , podemos utilizar Easing fuera de entornos de Flash y de ActionScript.Descargalo desde la web oficial.

Paso 1 – Configurar la estructura

Antes de empezar a tirar jQuery , tenemos que montar una estructura de menu rápida con XHTML y grabarla en los ficheros de proyecto requeridos. Creamos nuevos documentos para XHTML , CSS y javascript con la siguiente estructura:

Animated Menu Folder

Empezamos poniendo en la header las librerias necesarias y ficheros externos. Hemos elegido cargar jQuery desde el Google CDN hosted, mientras que el plugin de easing lo colocamos en la carpeta “js”. El orden de carga es importante!

[codebox 1]

  1. Copiamos la estructura de menu en el body:
[codebox 2]
  1. Los elementos del menu tienen un class asignado que designará el color del bloque. Dentro de cda bloque de menu hay un título y un subtitulo que son escondidos por defecto.

Paso 2 – Estilo con CSS

Ahora que tenemos la estructura de menu vamos a darle un poco de estilo y para que se organize horizontalmente. El overflow debe ser hidden para todos los elementos de la lista. Esto asegurará que el subtitulo para cada campo no se mostrará hasta que el height se expanda para que se ajuste a él.

[codebox 3]

Paso 4 – Animación con jQuery

Veamos ahora el código de “animated-menu.js”:

[codebox 4]

Hay dos acciones en este código. Cuando el ratón se mueve sobre un elemento del menu , entonces empieza una animación que hace expandir a 150px durante 0.6 segundos. El easing aplicado es ‘easeOutBounce’ que hace que la caja rebote un poco cuando llega al final de la animación. Cuando el ratón es movido fuera se lanza la animación que restaura el height original.

El método stop() se ha encadenado antes de la animación par prevenir al buffer de memoria si la animación entra en un bucle repetido cuando el ratón se mueve alrededor muy rápido.

Hudson para integración continua

What is Hudson?

[Fuente: http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson]

Hudson monitoriza ejecuciones de trabajos repetitivos, tales como la compilación del software de un proyecto o las tareas ejecutads por un cron. Entre otras cosas, Hudson actualmente se enfoca en dos tareas:

  1. Compilar/testear el software de los proyectos continuamente. Tal como lo hace CruiseControl o DamageControl. En resumen Hudson proporciona un sistema de integración continua fácil de utilizar, haciendo más fácil a los programadores integrar cambios en los proyectos, y haciendo más fácil para los usuarios obtener la última versión de la aplicación. El build continuada y automatizado incrementa la productividad.
  2. Monitorear ejecuciones de tareas ejecutadas externamente, tales como cron jobs y procmail jobs, incluso aquellos que son ejecutados en máquinas remotas. Por ejemplo, con cron, todo lo que recibes son emails normales que capturan la salida y es decisión tuya el examinarlos para ver si hay algun problema. Hudson guarda esas salidas y te hace más fácil avisarte cuando algo va mal.

Características

Hudson ofrece las siguientes características:

  1. Easy installation: Just java -jar hudson.war for testing. Use a native package or deploy it in a servlet container for production use. No additional install, no database.
  2. Easy configuration: Hudson can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There’s no need to tweak XML manually anymore, although if you’d like to do so, you can do that, too.
  3. Change set support: Hudson can generate a list of changes made into the build from SCM systems like CVS, Subversion, Git and many others.. This is done in a fairly efficient fashion, to reduce the load on the repository.
  4. Permanent links: Hudson gives you clean readable URLs for most of its pages, including some permalinks like “latest build”/”latest successful build”, so that they can be easily linked from elsewhere.
  5. RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.
  6. After-the-fact tagging: Builds can be tagged long after builds are completed
  7. JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.
  8. Distributed builds: Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers’ desks.
  9. File fingerprinting: Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency.
  10. Plugin Support: Hudson can be extended via 3rd party plugins. You can write plugins to make Hudson support tools/processes that your team uses.

 

Creando una aplicación simple en jQuery Mobile

Cómo utilizar jQuery Mobile

[Fuente: http://devgrow.com/mobile-web-dev-using-jquery-mobile/]

jQuery Mobile es increiblemente fácil de utilizar, tan solo es necesario incluir las librerias js de jQuery Mobile en el header y añadir unos pocos atributos “data” en tu maquetación y ya tienes tu web con jQuery Mobile. Todo el tema de los estilos es manejado por jQuery y los ficheros CSS que hay que incluir, asi que literalmente se puede crear una web con jQuery Mobile en minutos. Vamos a crear una de ejemplo que tendrá varios links internos para utilizar varios efectos de transiciones.

Paso 1. Incluir los ficheros de jQuery Mobile en el Header de tu maqueta

Puedes descargar las librerias o referenciar directamente los ficheros que hay colgados de forma pública (esto se llama CDN hosted links , tiene ventajas como reducir los costes de ancho de banda y hacer tu web más rápida).

 

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0a1/jquery.mobile-1.0a1.min.css" />  
<script type="text/javascript" src="http://code.jquery.com/jquery-1.4.3.min.js"></script>
<script type="text/javascript" src="http://code.jquery.com/mobile/1.0a1/jquery.mobile-1.0a1.min.js"></script>

 

Paso 2. Utilizar el atributo data en el HTML

Veamos un ejemplo que contiene atributos “data” y lo explicamos a continuación:

 

<div data-role="page" data-theme="b">
        <div data-role="header" data-theme="b">
            <h1>My Site</h1>
        </div>
        <div data-role="content">
            <ul data-role="listview" data-inset="true" data-theme="c" data-dividertheme="a">
                <li data-role="list-divider">Transition Effects</li>
                <li><a href="effects.php?id=slide" data-transition="slide">Slide</a></li>
                <li><a href="effects.php?id=slideup" data-transition="slideup">Slide Up</a></li>
                <li><a href="effects.php?id=slidedown" data-transition="slidedown">Slide Down</a></li>
                <li><a href="effects.php?id=pop" data-transition="pop">Pop</a></li>
                <li><a href="effects.php?id=flip" data-transition="flip">Flip</a></li>
                <li><a href="effects.php?id=fade" data-transition="fade">Fade</a></li>
            </ul>
            <br /><br />
            <ul data-role="listview" data-dividertheme="e">
                <li data-role="list-divider">Seamless List (margin-less)</li>
                <li><a href="#" data-transition="slide">Example Item 1</a></li>
                <li><a href="#" data-transition="slide">Example Item 2</a></li>
                <li><a href="#" data-transition="slide">Example Item 3</a></li>
            </ul>
        </div>
        <div data-role="footer" data-position="fixed">
            <h1>© Copyright Info or Site URL</h1>
        </div>
    </div>

 

El elemento “data-role” especifica que DIV o bloque debe ser utilizado para el header, cual para el footer y cual para el contenido, donde todos ellos estarán incluidos en un bloque “page” principal. Veamos en más detalle estos atributos “data” aqui utilizados:

  • data-role –  especifica la naturaleza del elemento envoltorio al que se aplica, puede ser : page,headercontentfooter.Otros valores que aparecen en el ejemplo son para indicar list elements y list dividers: listview para el elemento principal de la lista y list-divider para el list divider. Hay algunos otros valores , como por ejemplo collapsible ej qye crea bloque que se puede mostrar u ocultar.
  • data-position – especifica si el elemento debe ser fixed , es decir fijado en un sitio siempre, en tal caso se pintará en el top (para el header) o en el bottom (para el footer). En el ejemplo de arriba esta puesto en el pie, el efecto que veo que tiene este atributo es que si lo quito el pie se pega al final del contenido , pero si lo pongo entonces el pie se queda pegado al fondo de la ventana del navegador
  • data-inset – especifica si el elemento debe estar dentro de los margenes del contenido o fuera. Se pone a true o false. Lo que veo es que cuando es false (por defecto si no se especifica) el elemento ocupa el 100% de la pantalla y si se pone a true se le quedan unos margenes por ambos lados.
  • data-transition – especifica qué transición utilizar cuando se cargan nuevas páginas, puede tener los valores slideslideupslidedownpopflip or fade
  • data-theme – especifica que theme de diseño para los elementos dentro del contenedor que lo especifica, puede ser abcde
  • data-dividertheme – especifica el theme de diseño para los list dividers utilizando los mismos valores que al data-theme

Paso 3. Añadiendo contenido

Ya estas preparado para añadir el contenido que quieras a los distintos contenedores que tienes en la maquetación. No es estrictamente necesario utilizar un smartphone para probarlo porque los navegadores de internet lo saben interpretar (sobre todo el Google Chrome) , aunque bien es cierto que tener uno puede ayudar a encontrar bugs del jQuery Mobile.

Accesibilidad y precauciones

Ahora mismo, la versión Alpha de jQuery Mobile es compatible con todas las versiones de safari para IOS y para la mayoría de los navegadores de Android. BlackBerry es parcialmente soportado. Para más info ver la compatibility chart.

Un beneficio adicional de jQuery Mobile es que carga las páginas utilizando AJAX automáticamente.


jQuery Mobile: Modelo de navegación con Ajax

Una “page” en jQuery Mobile se compone de un elemento (generalmente un div) con un atributo data-role con el valor ‘page’, que generalmente contiene elementos div con roles de “header”, “content” y “footer”, cada una con su maquetación , formularios y widgets customizados de jQuery Mobile.
El workflow básico en la carga de páginas es como sigue:

  1. Primero, una page es pedida como una petición normal HTTP
  2. Las pages subsecuentes que sean pedidas son inyectadas en el DOM de la pagina anterior.

Por este motivo, el DOM puede tener varias pages dentro de el en un solo momento, cada una de las cuales pueden ser revisitadas cuando son enlazadas con referencia a su atributo “data-url”.

Cuando una url es pedida inicialmente, puede haber una o más pages en la response, pero solo la primera será mostrada. La ventaja de almacenar más de una page es que permite precargar páginas estáticas que son susceptibles de ser muy visitadas.

 

Navegación de páginas conducida por Ajax

Toda la nevegación con jQuery Mobile se basa sobre cambios y actualizaciones a “location.hash”. Cuando se pueda hacer, los cambios de page utilizarán una transición suave entre la page actual y la siguiente, tanto si ya esta presente en el DOM, o es automáticamente descargada via Ajax.

Los valores hash creados por jQuery Mobile son normalizados como full paths relativos a la URL de la primera página real que fue descargada.El hash siempre es mantenido como una URL valida, asi cualquier page de jQuery Mobile puede ser añadida a favoritos o referenciada desde un link. Para recuperar URL que no estan basadas en Hash, simplemente borra el # de la direccón y refresca la pagina.

En general, los cambios de hash son creados cuando quiera que un enlace es clickado en jQuery Mobile. Cuando un link es clickado, jQuery Mobile se asegurará que el link se referencia como una URL local, y asi, prevenirá el comportamiento por defecto del click de ocurrir y pedirá la url referenciada via Ajax en su vez.Cuando la página viene con exito, hará un set del location.hash a la nueva url relativa de la pagina.

 

La función $.mobile.changePage((to, transition, back, changeHash)

Dentro del framework, los cambios de página – tanto para páginas ya en el DOM como para páginas que necesitan ser descargadas via Ajax – utilizan la función $.mobile.changePage(). Esta función contiene toda la lógica para encontrar páginas hacia o desde donde se quiere transicionar , y como manejar varias condiciones de respuesta tales como page not found. Esta función puede ser invocada externamente y acepta los siguientes argumentos : ((to, transition, back, changeHash))

  • To: acepta a una string (tal como la url de un fichero o el id de un elemento local), un array (donde el primer elemento del array es cualquier pagina local desde la que transcionarias, y el segundo elemento es la pagina a la que vas) , o un objeto (con las properties url, type (‘get’ o ‘post’), y data (para parametros serializados)), el ultimo de los cuales es útil para cargar páginas que esperan datos de formulario.
  • The transition argument accepts a string representing a named transition, such as “slide”.
  • The back argument accepts a boolean representing whether the transition should go forward or in reverse.
  • Lastly, the changeHash argument accepts a boolean for whether you’d like the url to be updated upon a successful page change.

La función $.mobile.changePage() se utiliza en muchos sitios con jQuery Mobile. Por ejemplo, cuando un link es clickado, su atributo href es normalizado y entonces $.mobile.changePage() maneja el resto. También cuando los formularios son submitted, jQuery Mobile simplemente recoge unos pocos de los atributos del form, serializa sus datos y una vez mas $.mobile.changePage() es usado para manejar la submission y la respuesta.Además, los links que crean dialogos utilizan $.mobile.changePage() para abrir una page referenciada sin actualizar el hash, lo cual es útil para tener los dialogos fuera del history tracking.

Otro ingrediente clave del modelo de navegación de jQuery Mobile es el elemento ‘base’, el cual es inyectado dentro del head y modificado en cada cambio de página para asegurar que todos los recursos (css, imagenes, js,etc) referenciados en esa page serán pedidos desde un path apropiado. En los navegadores que no soportan actualizaciones dinámicas al elemento base (como Firefox 3.6), jQuery Mobile hace bucle a través de todos los recursos referenciados de la page y pone prefijos en sus href y src atributos con el base path.

Los cambios hash que ocurren independientemente de un click, tal como cuando un usuarios hace click en el boton de Atras, son manejados a través del evento hashchange, el cual es enlazado al objeto window utilizando el Ben Alman’s hashchange special event plugin (included in jQuery Mobile).Cuando ocurre un hash change (y tambien cuando la primera página se carga) , el manejador del evento hashchange envia el location.hash a la función $.mobile.changePage(), el cual de vuelta carga o recupera la pagina referenciada.

Una vez que la página referenciada esta presente en el DOM, la función $.mobile.changePage() aplica una transición entre la pagina actual activa y la nueva página. Las transiciones entre páginas ocurren a través de añadir y borrar classes que aplican animaciones CSS. Por ejemplo, en una transición hacia la izquierda, la página saliente se le dan las clases “slideleft” y “out” , y a la página entrante se le dan las clases “slideleft” e “in”, asi como una clase de “ui-page-active” para marcarla como la nueva pagin activa que esta siendo visionada. Cuando la animación esta completa, las clases “in” y “out” son eliminadas, y la pagina que ha salido pierde el class “ui-page-active”.

 

Explicación para el programador de la gestión de la base url

jQuery Mobile gestiona las peticiones http utilizando una combinación de paths URL absolutos generados y de manipular el atributo href del elemento <base>.La combinación de estas dos aproximaciones nos permite crear URLs que contienen información full path para cargar páginas, y un elemento base para hacer requests directas apropiadamente de recursos que tienen las paginas descargadas (tanto imagenes como hojas de estilo).

 

Paginas auto-generadas y urls sub-hash

Algunos plugins pueden elegir dividir dinamicamente el contenido de una pagina en varias paginas navegables, las cuales con entonces referenciadas como deep links. Por ejemplo el plugin Listview, el cual divide una UL anidada (o OL) en páginas separadas, las cuales tendrán un atributo data-url apropiado para ser enlazados como una página normal de jQuery Mobile. Sin embargo, para enlazar con estas páginas, la página que las genera debe ser primero pedida al servidor. Para hacer esto , las páginas que son auto-generadas por plugins utilizan un estructura data-url especial: <div data-url=”page.html&subpageidentifier”>

Asi, por ejemplo, una página generada con el plugin listview puede tener un atributo data-url como este:

data-url=”artists.html&ui-page=listview-1″

Cuando una página es solicitada, jQuery Mobile extrae lo que hay antes de “&ui-page” en la url para hacer una HTTP request. En el caso del ejemplo de arriba, la URL sería como esto:

http://example.com/artists.html&ui-page=listview-1 …

entonces en este caso jQuery Mobile solicitaría artists.html, despues se generan sus sub-pages, y se crea un div con el atributo data-url=”artists.html&ui-page=listview-1″ que será visualizado como la página activa.

Nota: Observese que el atributo data-url del elemento contiene una full path URL, no solo la parte después de &ui-page. Esto permite a jQuery Mobile utilizar un sencillo mecanismo consistente que hacer corresponder URLs con pages con atributos data-url.

Casos donde la navegación Ajax no será utilizada

Bajo ciertas condiciones, las peticiones http normales serán utilizadas en lugar de las peticiones Ajax. un caso donde esto es cierto es cuando se enlazan con páginas en webs externas. Asi que se puede especificar que se haga una petición normal http con los siguientes atributos:

  • rel=external
  • target (with any value, such as “_blank”)

Haciendo submits de formularios

Los submits de formularios son manejados automáticamente a través del modelo de navegación ya comentado. Para más información visita la sección de formularios.

Limitaciones conocidas

El entorno no estandar creado por el modelo de navegación de páginas de jQuery Mobile introduce algunas condiciones a tener en cuenta:

  • Cuando enlazamos a directorios, sin un nombre del fichero html en la url (por ejemplo href=”typesofcats/”  en vez de href=”typesofcats/index.html”), debemos poner la barra final. Esto es porque jQuery Mobile asume que la sección después del caracter “/” en una url es un nombre de fichero, y se borra para asi guardar una base url con la que referenciará páginas futuras.
  • Cualquier recurso referenciado unívocamente por las pages en una web de jQuery Mobile debe ser colocada dentro del elemento “page” (aquel elemento con un data-role = page). Por ejemplo, los links a estilos y scripts que son particulares de una pagina deben ser  referenciados dentro del propio div. Otra forma mejor es utilizar los eventos de pagina de jQuery Mobile para lanzar scripting especifico cuando ciertas páginas cargan.
    • Nota: cuando se descarga una pagina desde servidor que tiene un atributo data-url especificado en la maquetacion, jQuery Mobile lo utilizará para hacer un hash update. Con esto nos aseguramos que los paths de directorios resuelven con un “/” y por lo tanto serán usados en el base url path para futuras requests.
  • De la misma forma, los recursos que son utilizados de forma general en la web deben ser referenciados en la  <head> section del HTML document, o como mínimo,  fuera del elemento “page” , para prevenir que se ejecuten los mismos scripts más de una vez.
  • La palabra clave “ui-page” utilizada en referencias sub-hash urls puede ser configurada a cualquier valor, de forma que se integre dentro de tu estructura de URL. Lo puedes hacer cambiando la siguiente property jQuery.mobile.subPageUrlKey.

 

jQuery Mobile: Poniendo Javascript a las páginas

Como jQuery Mobile utiliza un sistema de navegación controlado por Ajax, hay una serie de cosas que debes saber cuando manipulas el contenido del HTML con Javascript.

1.Scripts & styles en el head

Cuando un usuario hace click en una web conducida por jQuery Mobile, el comportamiento por defecto del sistema de navegación es utilizar el href del link para hacer una petición de request de Ajax (en vez de de permitir el comportamiento por defecto del navegador de hacer una request de la página completa).Cuando la request Ajax finaliza, el framework recibirá el contenido de texto completo, pero sólo inyectará los contenidos del elemento body de la respuesta (o más especificamente el elemento que tenga “data-role=’page'”, si viene alguno), lo que quiere decir que nada de lo que vaya en el head de la página será utilizado (con la excepción del title, que es recuperado especificamente).

Esto quiere decir que cualquier script y estilo referenciado en el head de la página on tendrá ningún efecto cuando un page es cargada via Ajax, pero se ejecutará si la página es pedida normalmente por HTTP. Cuando se quiere hacer scripting de webs con jQuery Mobile, ambos escenarios deben ser considerados. La razón de que el head sea ignorado cuando se hace la petición Ajax es que el potencial de re-ejecutar el mismo Javascript es muy alto (es muy habitual referenciar los mismos scripts en todas las páginas del site). Debido a la complejidad de intentar trabajar para sobrellevar esta situación, dejamos la tarea de ejecutar scripts especificos de page al programador, y asumimos que los scripts que van en el head son sólo ejecutados una vez por sesión del usuario.

La aproximación más simple cuando se construye una web con jQuery Mobile es referenciar el mismo conjunto de stylesheets y scripts en el head de todas las páginas. Si necesitas cargar scripts específicos para una página en particular, recomendamos enlazar la lógica que necesitemos al evento ‘pagecreate‘ para ejecutar el código necesario cuando una página específica es creada (que puede ser determinado por el atributo id, o por otras formas). Siguiendo esta aproximación aseguraremos que el código se ejecuta si la página es cargada directamente o es invocada por medio de Ajax.

Otra aproximación para page-specific scripting sería incluir scripts al final del elemento body. Si incluyes tu custom scripting de esta forma, ten cuidado que estos scripts se ejecuten cuando la página se cargue por Ajax o por HTTP regular, asi estos scripts son los mismos en todas las páginas y esto puede llevar a problemas. Incluyendo scripts de esta forma, recomendariamos encerrar el contenido de la página en un elemento “data-role=’page'”, y colocar los scripts que son referenciados en todas las páginas fuera de este elemento. Los scripts que son únicos a la página pueden ser colocados dentro de ese elemento, para asegurar que se ejecuten cuando la página es cargada via Ajax.

 

2.En jQuery Mobile tenemos que pagecreate = DOM ready

Una de las primeras cosas que la gente aprende en jQuery es utilizar la función $(document).ready() para ejecutar código DOM-specific tan pronto como el DOM esta listo (lo cual ocurre mucho antes del evento onload). Sin embargo, en las webs y aplicaciones hechas con jQuery Mobile, las pages son pedidas e inyectadas en el mismo DOM según el usuario navega, de forma que los evento DOM ready no son útiles, ya que solo se ejecutan con la primera página. Para ejecutar código cuando quiera que una página es cargada y creada en jQuery Mobile, debes enlazar con el evento pagecreate.

El evento pagecreate es disparado en una página cuando es inicializada, justo después de que ocurre la inicialización. La mayoria de los widgets oficiales de jQuery Mobile se autoinicializan ellos mismos basados en este evento, y por tanto es bueno que tu configures tu código basandose en este evento.

[codebox 1]

Si te gusta manipular los contenidos de una page antes de que se dispare el evento pagecreate y los widgets se autoinicialicen, puedes enlazar con el evento pagebeforecreate:

[codebox 2]

3.Cambiando de página

Si quieres cambiar la página activa actual con Javascript, puedes utilizar el método changePage. Hay muchos métodos y properties que pueden ser configurados en los cambios de pages, vemos aqui dos ejemplos:

[codebox 3]

4.Carga de páginas

Para cargar una página externa, ampliar su contenido e insertarlo en el DOM, podemos utilizar el método loadPage.Hay muchos métodos y propoerties que pueden configurar cuando cargas páginas. Veamos un ejemplo simple:

[codebox 4]

5.Incluyendo maquetación nueva

El plugin page dispara un evento pagecreate , que la mayoria de los widgets lo utilizan para autoinicializarse. Tan pronto como un script plugin de widget es referenciado, automáticamente amplia cualquier instancia de widget que encuentre en la página.

Sin embargo, si generamos una nueva maquetación del lado del cleinte o cargamos el contenido via Ajax y lo inyectamos dentro de una page, puedes disparar el evento create para manejar la autoinicialización de todos los plugins contenidos dentro de la nueva maquetación. Esto puede ser disparado sobre cualquier elemento (incluso el page div en si mismo), diciendote la tarea para inicializar manualmente cada plugin (listview button, select, etc).

Por ejemplo, si un bloque de maqueta HTML (por ejemplo un formulario de login) ha sido cargado via Ajax, entonces se dispara el evento create para automaticamente transformar todos los widgets que contiene (inputs y buttons en este caso) en sus versiones ampliadas. El código para este escenario sería:

[codebox 5]

6.Create vs. refresh: in distinción importante

Vemos que hay una importante diferencia entre el evento create y el método refresh que algunos widgets tienen. El evento create esta hecho para ampliar nueva maquetación ‘cruda’ que contiene uno o más widgets.El método refresh deberia ser utilizado en widgets ya existentes (ya ampliados) que han sido manipulados programaticamente y necesitan que el UI se actualice.

Por ejemplo, si tuvieramos una page donde dinamicamente añadimos una nueva lista no ordenada con el atributo data-role=listview despues de la creación de la página, disparar el evento create sobre un elemento parent de esa lista la transformaría en un widget listview estilizada. Si se van a añadir más elementos de la lista programaticamente, llamar al método refresh del listview actualizará esos nuevo elementos de la lista al estado ampliado y deja los elementos de la lista existentes sin tocar.

7. Hacer scroll a una position dentro de una page

Ya que estamos utilizando la URL hash para conservar el comportamiento del Back button, utilizar page anchors para saltar a una posición dentro de la misma page no es soportada utilizando el anchor link tradicional (#foo). Utilizamos el método silentScroll para hacer scroll a una posición Y en particular sin la necesidad de disparar scroll event listeners. Ejemplo:

[codebox 6]

NOTA: Si bien , basandome en mi propia experiencia , tengo que decir que no funciona este método en los navegadores de los móviles como Iphone y Android. Entonces he utilizado un método más estandar de jQuery que hace lo mismo y funciona en los navagadores de loss dispositivos:

[codebox 7]

8.Enlazando a eventos de mouse y de touch

Una importante consideración en las plataformas móviles es el manejo de los eventos mouse y touch. Estos eventos difieren significativamente entre diferentes plataformas móviles, pero el denominador común es que los eventos de click funcionan en todas partes, pero generalmente después de un retraso también significativo de entre 500-700 ms. Este retraso es necesario para que el navegador puede esperar por el double tap (toque doble), u otros eventos tap extendidos. Para eliminar este retraso, es posible enlazar estos eventos a eventos touch. El problema con esta aproximación es que las plataformas WP7 y BlackBerry no soportan touch. Para sobrellevar este inconveniente, algunas plataformas emiten por duplicado los eventos de touch y de mouse, asi que si enlazamos con los dos tipos de eventos , para una sola interacción se dispararán dos veces.

Nuestra solución es crear un conjunto de eventos virtuales que normalicen los eventos de touch y de mouse. Esto permite a los programadores registrar listeners para los eventos de mouse básicos, tal como mousedown, mousemove, mouseup y click , y el plugin tendrá cuidado de registrar los listeners correctos por nosotros para invocar al listener en el menor tiempo posible para ese dispositivo en concreto. Esto aún retiene el orden de disparo de los eventos como en el entorno del mouse tradicional, debe registrarse multiples manejadores  en el mismo elemento para cada uno de los eventos.

El sistema virtual de mouse expone los siguientes eventos virtuales para que se enlacen con métodos de jQuery:

vmouseovervmousedownvmousemovevmouseupvclick, and vmousecancel

9.Pasar parámetros entre páginas

jQuery Mobile no soporta el paso de parámetros por la request entre pages internas o embebidas. Por ejemplo, si el framework ve un enlace de la siguiente forma “#somePage?someId=1”

jQuery Mobile does not support query parameter passing to internal/embedded pages. For example, if the framework sees a link to “#somePage?someId=1” it interpret that as “#somePage” and navigate to the internal page div with an ID of somePage and apply a data-url of#somePage?someId=1 to that page container. Subsequent calls to other params such as “#somePage?someId=2” will find the same div because jQuery Mobile refers to the data-url on the div which is only set once and will remain at #somePage?someId=1.

There are two plugins that you can add to your project if query parameters are needed between pages. There is a lightweight page params plugin and a more fully featured jQuery Mobile router plugin for use with backbone.js or spine.js.

 

Guía de diseño de webs para móviles

1. Diseñar para dispositivos móviles

1.1. Diferencias entre diseñar para la web y diseñar para dispositivos móviles

Gracias a los avances de estandarización de los lenguajes de desarrollo de páginas web para  dispositivos móviles, las diferencias a la hora de realizar webs para distintos dispositivos se han reducido sensiblemente.

Sin embargo, aunque técnicamente sea muy similar realizar páginas para un móvil (o una PDA) y para un ordenador de sobremesa, hay que considerar otros aspectos a la hora de realizar los diseños para un móvil:

• Tamaño de la pantalla

• Estructura de navegación

• Contenido y forma de escribir

• Accesos rápidos


1.2. Tamaño de la pantalla

La diferencia más evidente a la hora de realizar un sitio web para dispositivos móviles es sin duda, el tamaño de la pantalla. Mientras que en una página web normal, nos movemos con tamaños de pantalla de 800×600, 1024×768 o 1280×1024 píxeles, en dispositivos móviles los tamaños de la pantalla varían desde 128×160 hasta 320×320.

Estos tamaños, obviamente, imponen ciertas restricciones y formas de hacer a la hora de utilizar imágenes, tablas, enlaces… y de situarlos en pantalla. Al igual que ocurre en una web normal, hay que tratar de que nuestra web se vea correctamente en la mayoría de los dispositivos, por eso es recomendable no sobrepasar el tamaño de 200×250 píxeles a la hora de diseñar la web.

Igual que en una web normal, lo realmente importante a la hora de situar los elementos de la web es el ancho de la misma, por lo que, esos 200px serán nuestra principal referencia, aunque dependiendo del perfil de usuario al que nos dirijamos podemos adoptar otros tamaños y, además, siempre podemos utilizar un diseño flexible que se adapte correctamente a los diferentes tamaños de pantalla.

 

1.3. Estructura de navegación

La navegación en un teléfono móvil es sensiblemente diferente a navegar por la web utilizando un ordenador o algún otro dispositivo que disponga de ratón y teclado. Además, cuando estamos navegando utilizando un móvil, las esperas, el no encontrar el contenido deseado o el tener que dar clics de más es especialmente frustrante. Por ello, a la hora de definir la navegación de nuestra página web, hay que realizarse una pregunta fundamental: ¿qué es lo que el usuario viene a buscar a nuestra web? Esa información que el usuario busca, hay que presentársela en el menor lapso de tiempo posible.

Como hemos comentado, navegar desde un dispositivo móvil es más costoso que desde un ordenador. Hay que seguir una serie de consejos a la hora de plantear la navegación:

• Limitar en número de opciones. Más opciones no siempre significa mejor. El usuario puede desorientarse y sentirse frustrado al no encontrar lo que busca y tener que navegar más de lo debido: presentar pocas opciones y de forma clara.

• Evitar los enlaces vacíos. Hay que proporcionar siempre un contenido a todos los enlaces. Pinchar en una categoría para encontrarnos con un listado de subcategorías sin información útil no es recomendable.

• Limitar los enlaces por página a un máximo de 10. Los dispositivos que sólo disponen de teclado numérico (la mayoría de los móviles) nos permiten utilizar las teclas 0-9 como accesos rápidos a los enlaces. Hay que aprovechar esta circunstancia y asignaraccesskey a todos los enlaces de la página, por eso conviene limitarlos a 10.

• Priorizar los enlaces. Los primeros enlaces siempre deben ser los más evidentes, a los que el usuario accede normalmente. No siempre es sencillo saber que enlaces priorizar, hay que realizar pruebas y considerar los pros y contras del orden elegido.

• Proporcionar siempre un acceso al menú principal. Siempre hay que permitir al usuario volver al menú principal sin obligarle a retroceder, de página en página, por el árbol de navegación.

Teniendo en cuenta estas consideraciones, es recomendable elaborar un árbol de navegación en el que representemos las distintas páginas de nuestra web y como se accederá a ellas.

También hay que considerar, que en un dispositivo móvil, los números actúan de enlace, así que es conveniente colocar siempre el número de teléfono de nuestra empresa o negocio para que el usuario lo pueda guardar en su agenda.

 

1.4. Contenido y forma de escribir

Si se tiene una web ya hecha, es normal tener la tentación de hacer un refrito para crear una versión para dispositivos móviles, o quizácambiar simplemente los estilos para ajustarse a los criterios técnicos necesarios. Si pretendemos que nuestra web resulte útil, esto es un error.

Si estamos accediendo a una web desde un dispositivo móvil, un teléfono por ejemplo, esperamos encontrar una información concreta y ajustada; cuando uso un teléfono móvil para navegar por Internet, estoy buscando información útil y que me permita realizar alguna acción con ella. Es impensable poner páginas en las que el usuario tenga que hacer scroll más de una vez, y eso en un dispositivo de 250px de alto, significa ajustar mucho el contenido que hay que presentar y la forma de hacerlo.

Estas limitaciones, imponen un trabajo de análisis previo a la realización de la página web muy importante. Hay que saber perfectamente qué parte de la información va a quedar fuera de nuestra web .mobi y cuál resulta relevante y útil como para ponerla en nuestra versión para los dispositivos móviles. No hay que tratar de ponerlo todo, sólo lo que sea realmente útil para un usuario que vaya a entrar desde su dispositivo móvil. Siempre se pueden añadir referencias a la versión normal de nuestra web en aquellos apartados en los que se considere.

 

1.5. Accesos rápidos

Ya hemos comentado la importancia de los accesos rápidos en dispositivos sin teclado alfanumérico, que son la mayoría de los dispositivos móviles. Lo que en una web normal puede no ser tan importante, aquí se convierte en fundamental. Elaborar un menú limitado a un máximo de 10 elementos para que el usuario pueda acceder a ellos con un sólo clic es indispensable. De igual forma, cada vez que haya un enlace es importante acostumbrarse a asignarle accesskeys del 0-9.

 

1.6. Plantillas: disposición de los elementos

Las limitaciones de las que hemos estado hablando, imponen una estructura de web menos flexible de lo que se estila si estuviéramos viéndola desde una pantalla de ordenador. En un móvil, la navegación debe ser considerada siempre de forma vertical (excepto para aquellos dispositivos de gran resolución de pantalla), por lo que lo común es presentar plantillas como la siguiente:

 

1.7. XHTML Mobile Profile / XHTML Basic

Se ha avanzado mucho en los procesos de estandarización de los protocolos de web móvil desde que había que escribir en WML las páginas web para móvil, lo que ha provocado que escribir código para un dispositivo móvil sea prácticamente igual que escribirlo para una web típica. Si no hay una necesidad de ajustarse a dispositivos antiguos, cualquier móvil actual interpreta correctamente páginas escritas enXHTML-Mobile Profile y que usen Wireless CSS.

XHTML-Mobile profile, es un subconjunto de XHTML y, actualmente, XHTML Basic 1.1 y XHTMLMobile Profile 2.0 son prácticamente idénticos. Por lo tanto, si se sabe XHTML, sólo hay que tener en consideración unas mínimas limitaciones.

Wireless CSS es también un subconjunto de CSS y soporta la mayoría, aunque no todos los atributos de CSS. De nuevo, si mantenemos el CSS lo más simple posible, no tendremos ningún problema de que nuestras páginas se vean correctamente.

Para más información:

• W3C: XHTML Basic 1.1 (http://www.w3.org/TR/xhtml-basic/), CSS-MP

(http://www.w3.org/TR/css-mobile/)

• OMA: XHTML-MP, Wireless CSS© 2011 – Copyright Arsys Internet S.L.

2. XHTML: Recomendaciones

Te mostramos las bases y algunas recomendaciones para la creación de páginas XHTML para dominios .mobi.

• Tipo de codificación de caracteres (encoding)

Si no indica un tipo correcto para la codificación de los caracteres en su página, puede que ésta muestre caracteres extraños al visualizarse en el dispositivo móvil. El tipo de codificación debe aparecer siempre en la primera línea de su página web. Se recomienda usar codificación UTF-8:

<?xml version=”1.0” encoding=”UTF-8” ?>

• Tipo de documento (DOCTYPE)

El tipo de documento indica al navegador cómo visualizar la página (qué reglas deben aplicarse, etc…). Te recomendamos usar el siguiente código:

<!DOCTYPE html PUBLIC “-//WAPFORUM//DTD XHTML Mobile 1.0//EN”

“http://www.wapforum.org/DTD/xhtml-mobile10.dtd”>

• Escribir en lenguaje XHTML sintácticamente correcto

El código de una página web debería estar conforme al tipo de documento indicado (doctype) y seguir las reglas del lenguaje usado (estar bien escrito sintácticamente en XML). Te recomendamos revisar los siguientes apartados:

Todas las etiquetas deben cerrarse con “/>”. Ejemplo: <br /> (también admitido <br></br>).

Las etiquetas deberían estar bien posicionadas, con inicio y fin. Ejemplo: <p><em><strong>Texto</strong></em></p>

Las imágenes deben incorporar siempre el atributo “Alt”. Ejemplo: <img src=”imagen.gif” alt=”Descripción de la imagen”/>

Los textos deben ir dentro de un párrafo (y no directamente en el body). Ejemplo: <body><p>Texto</p></body>

Los atributos deben entrecomillarse. Ejemplo: <img src=”dirección-imagen” alt=”Descripción” />

o Usar siempre minúsculas para las etiquetas y sus atributos. Ejemplo: <p class=”destacado”>Texto destacado</p>© 2011 – Copyright Arsys Internet S.L.

NOTA: Recuerda que existen numerosas herramientas online para validar la sintaxis de tus páginas web.

• Usar títulos de página cortos y significativos

Los títulos son importantes porque favorecen la identificación del contenido de la página y son utilizados por los buscadores para su indexación. Se recomienda usar títulos de página cortos y descriptivos, teniendo en cuenta que el navegador del dispositivo móvil puede truncar su contenido en la mayoría de las ocasiones. Un título con estas características, seguido opcionalmente del nombre de su web, suele ser la opción más adecuada. Ejemplo:

<title>Descripci&oacute;n corta – mi dominio</title>

• Evitar el uso de tablas para la disposición de los elementos o el contenido

Las tablas, en pantallas pequeñas, suelen dar problemas de visualización. Te recomendamos evitar usarlas, ya sea para la disposición de los elementos en la página o como contenido dentro de las mismas. Para el contenido:

  • Haz uso de la etiqueta <dl> (lista de definición) en vez de <table> para mostrar datos.
  • Si no tienes más remedio, usa tablas de pocos elementos (con dos o tres columnas máximo).

Para la disposición de los elementos en la página:

Utiliza la etiqueta <div> para organizar los contenidos de forma lógica y luego darle el estilo que desees para controlar su presentación. Por ejemplo, si queremos mostrar un texto entre una cabecera y un pie de página podríamos indicar algo como:

 

• Menú de navegación en el cuerpo de la página, listas ordenadas y accesskey

Debido a la orientación vertical del diseño, no se recomienda tener un menú fijo de navegación en cada página (a diferencia de lo que ocurre en las páginas web normales). Eliminando el menú fijo de la página, reducimos el scroll y el peso de la misma. Por este motivo, debemos incluir la navegación dentro del cuerpo de la página, mostrando solo los enlaces que sean de mayor importancia.

Para facilitar la navegación mediante el teclado y evitar el scroll, es recomendable el uso de listas ordenadas a las que incorporar un acceso rápido mediante el teclado (a través de las accesskey). Por ello se recomienda no usar más de 10 enlaces por página (para asignar valores del 0 al 9 a cada enlace).

Ejemplo:

[codebox 1]

• Usar enlaces para los teléfonos

Una de las ventajas del uso de un dispositivo móvil es que hay un acceso rápido a la realización de llamadasA través del uso de enlaces para los números de teléfono permitimos al visitante efectuar una llamada de forma directa al teléfono mostrado o almacenarlo en su agenda (para posterior uso). Aunque se puede indicar un texto en el enlace, se recomienda siempre poner directamente el número de teléfono enlazado, para que sea más claro. Ejemplo:

<a href=”tel:+034902115530”>+034 902 11 55 30</a>

• Evitar el uso de formularios

Es evidente, que la inserción de datos en un terminal telefónico puede resultar una labor muy complicada y tediosa. Por este motivo se recomienda no usar formularios en las páginas diseñadas para dispositivos portátiles en la medida de lo posible. Como en otros casos, si no hay más remedio, reduce la inserción de datos al máximo, tratando de hacerlo lo más sencillo posible.

• Reducir al máximo el tamaño de las imágenes (y, en general, de las páginas)

Debido a las reducidas dimensiones de las pantallas de dispositivos móviles, debes reducir el tamaño de las imágenes utilizadas lo máximo posible. Recuerda que aunque el ancho recomendado son 200px, muchos terminales no superan los 120px por lo que si insertas imágenes, haz que tu ancho no supere dicha medida. Y no olvides insertar el atributo “alt” en todas tus imágenes.

3. Referencias

• Dot Mobi: http://pc.mtld.mobi/

• W3C: http://www.w3.org/

• OMA (Open Mobile Alliance): http://www.openmobilealliance.org/

• Patrones de diseño: http://patterns.littlespringsdesign.com

 

Manual de HTML5 en español

Fuente: http://theproc.es/2010/1/29/12236/manual-de-html5-en-espanol—1-de-3

El HTML5 (HyperText Markup Language, versión 5) es la quinta revisión del lenguaje de programación “básico” de la World Wide Web, el HTML. Esta nueva versión pretende remplazar al actual (X)HTML, corrigiendo problemas con los que los desarrolladores web se encuentran, así como rediseñar el código actualizandolo a nuevas necesidades que demanda la web de hoy en día.

Debido a que estos cambios afectaran la forma de desarrollar la web en un futuro inmediato, desde The Process, plantearemos una serie de artículos donde desvelaremos los cambios más importantes.

Actualmente el HTML5 está en un estado BETA (Enero 2010), aunque ya algunas empresas están desarrollando sus sitios webs en esta versión del lenguaje. A diferencia de otras versiones de HTML, los cambios en HTML5 comienzan añadiendo semántica y accesibilidad implícitas, especificando cada detalle y borrando cualquier ambigüedad. Se tiene en cuenta el dinamismo de muchos sitios webs (facebook, twenti, etc), donde su aspecto y funcionalidad son más semejantes a aplicaciones webs que a documentos.

Mejor estructura

Actualmente es abusivo el uso de elementos DIV para estructurar una web en bloques. El HTML5 nos brinda varios elementos que perfeccionan esta estructuración estableciendo qué es cada sección, eliminando así DIV innecesarios. Este cambio en la semántica hace que la estructura de la web sea más coherente y fácil de entender por otras personas y los navegadores podrán darle más importancia a según qué secciones de la web facilitándole además la tarea a los buscadores, así como cualquier otra aplicación que interprete sitios web. Las webs se dividirán en los siguientes elementos:

  • <section></section> – Se utiliza para representar una sección “general” dentro de un documento o aplicación, como un capítulo de un libro. Puede contener subsecciones y si lo acompañamos de h1-h6 podemos estructurar mejor toda la página creando jerarquías del contenido, algo mu favorable para el buen posicionamiento web.
  • <article></article> – El elemento de artículo representa un componente de una página que consiste en una composición autónoma en un documento, página, aplicación, o sitio web con la intención de que pueda ser reutilizado y repetido. Podría utilizarse en los artículos de los foros, una revista o el artículo de periódico, una entrada de un blog, un comentario escrito por un usuario, un widget interactivo o gadget, o cualquier otro artículo independiente de contenido.Cuando los elementos de <article> son anidados, los elementos de <article> interiores representan los artículos que en principio son relacionados con el contenido del artículo externo. Por ejemplo, un artículo de un blog que permite comentarios de usuario, dichos comentarios se podrían representar con <article>.
  • <aside></aside> – Representa una sección de la página que abarca un contenido tangencialmente relacionado con el contenido que lo rodea, por lo que se le puede considerar un contenido independiente. Este elemento puede utilizarse para efectos tipográficos, barras laterales, elementos publicitarios, para grupos de elementos de la navegación, u otro contenido que se considere separado del contenido principal de la página.
  • <header></header> – Elemento <header> representa un grupo de artículos introductorios o de navegación.
  • <nav></nav> – El elemento <nav> representa una sección de una página que es un link a otras páginas o a partes dentro de la página: una sección con links de navegación.No todos los grupos de enlaces en una página tienen que estar en un elemento <nav>, sólo las secciones que consisten en bloques principales de la navegación son apropiadas para ser utilizadas co el elemento <nav>. Puede utilizarse particularmente en el pie de página para tener un menú con un listado de enlaces a varias páginas de un sitio, como el Copyright; home page, política de uso y privacidad. No obstante, el elemento <footer> es plenamente suficiente sin necesidad de tener un elemento <nav>.
  • <footer></footer> – El elemento <footer> representa el pié de una sección, con información acerca de la página/sección que poco tiene que ver con el contenido de la página, como el autor, el copyright o el año.Veamos las Diferencias entre HTML y HTML5

Mejoras en los formularios

El elemento input adquiere gran relevancia al ampliarse los elementos que se permitiran en el “type”.

<input type=”search“> para cajas de búsqueda.

<input type=”number“> para adicionar o restar números mediante botones.

<input type=”range“> para seleccionar un valor entre dos valores predeterminados.

<input type=”color“> seleccionar un color.

<input type=”tel“> números telefónicos.

<input type=”url“> direcciones web.

<input type=”email“> direcciones de email.

<input type=”date“> para seleccionar un día en un calendario.

<input type=”month“> para meses.

<input type=”week“> para semanas.

<input type=”time“> para fechas.

<input type=”datetime“> para una fecha exacta, absoluta y tiempo.

<input type=”datetime-local“> para fechas locales y frecuencia.

Otros elementos muy interesantes

  • <audio> y <video> – Nuevos elementos que permitirán incrustar un contenido multimedia de sonido o de vídeo, respectivamente. Es una de las novedades más importantes e interesantes en este HTML5, ya que permite reproducir y controlas vídeos y audio sin necesidad de plugins como el de Flash.El comportamientos de estos elementos multimedia será como el de cualquier elemento nativo, y permitirá insertar en un video, enlaces o imagenes, por ejemplo. Youtube, ya ha anunciado que deja el Flash y comienza a proyectar con HTML5.
  • <embed> – Se emplea para contenido incrustado que necesita plugins como el Flash. Es un elemento que ya reconocen los navegadores, pero ahora al formar parte de un estándar, no habrá conflicto con <object>.
  • <canvas> – Este es un elemento complejo que permite que se generen gráficos al hacer dibujos en su interior. Es utilizado en Google Maps y en un futuro permitirá a los desarrolladores crear aplicaciones muy interessantes.

Elementos INLINE

HTML5 introduce nuevos elementos “inline” muy útiles para aumentar nuestro existente arsenal de “span, strong, em, abbr, etc”. A partir de ahora a estos elementos ya no se les llamará “inline”, sino “text-level semantics.”

mark

Cuando revisamos un listado de una búsqueda en una web, usualmente vemos el término por el que hemos buscado iluminado o resaltado dentro de cada resultado. Por lo general se marca cada instancia del término de búsqueda con un elemento span, pero span desde un punto de vista semántico, se queda un poco cojo, ya que realmente sirve para poco más que aplicarle una clase específica a un elemento dentro de un estilo ya definido.Se podría utilizar em o strong pero semánticamente no sería correcto ya que no querrías otorgarle una “importancia” al término de búsqueda, simplemente queremos que de alguna manera quede resaltado.Introduzcamos el elemento mark:

<h1>Resultado de búsqueda para 'unicornio'</h1>
<ol>
  <li>
  <a href="http://www.3sellers.com/">Leyendo el Gran   <mark>unicornio</mark> azul.</a>
  </li>
</ol>

El elemento mark no lleva implícito ninguna importancia para el contenido salvo el mostrarlo como algo de interés en el contexto en que esté. Según la especificación, mark denota fragmento de texto de un documento marcado o iluminado con fines de referencia debido a su importancia en otro contexto.

meter

El elemento meter puede ser utilizado para marcar medidas, siempre que esas medidas sean parte de una escala con valores mínimos y máximos.

<meter>9 de 10 gatos</meter>

No es obligatorio escribir el valor máximo si no quiere, para eso se puede utilizar el atributo max.

<meter max="10">9 gatos</meter>

Existe un atributo min correspondiente. También se puede utilizar los atributos high, low, y optimum. Si lo desea, puede incluso ocultar la medición dentro del atribulo value.

<meter low="-273" high="100" min="12" max="30" optimum="21" value="25">Hace bastante calor en esta época del año.</meter>

progress

Mientras el elemento meter es muy bueno para describir algo que ya ha sido medido. El elemento progress te permite marcar un valor que está en proceso de cambio.

Su perfil está <progress>60%</progress> completado.

Otra vez se pueden utilizar los atributos min, max, y value:

<progress min="0" max="100" value="60"></progress>

El elemento progress es más útil cuando se utiliza combinado con DOM Scripting. Se puede utilizar JavaScript para actualizaciones dinámicas del valor, permitiendo al navegador comunicar el cambio al usuario. Muy útil para cargar archivos con Ajax.

Estructura

HTML5 presenta una estructura basada en la experiencia de los desarrolladores de HTML y CSS. Tras haber valorado un millón de páginas y haber tabulado los nombres más comunes que se le asigna a los elementos class, nombres como “header, footer y nav” prevalecieron.

section

El elemento section es usado para agrupar por temas contenido relacionado. Eso suena muy similar al elemento div, que suele utilizarse como contenedor de contenido genérico. La diferencia es que div no tiene sentido en la semántica; no te dice nada sobre el contenido que lleva dentro. El elemento section, por otra parte, se utiliza de forma explícita para agrupar contenido relacionado.

Usted podría sustituir a algunos de sus elementos div con elementos section, pero recuerde siempre preguntarse ¿Está todo el contenido relacionado?

<section>
  <h1>Ave del paraíso</h1>
  <p> Narrativa policíaca y de intriga/Novela negra.</p>
  <p> CAROL JOICE</p>
</section>

header

Especialistas en HTML5 describen al elemento header como un contenedor de “a group of introductory or navigational aids”, que viene siendo algo como: elementos que sirven como introducción o elemento para la navegación. Eso suena razonable. Ese es el tipo de contenido que yo esperaría encontrar en un encabezado, y en inglés la palabra “header” se utiliza a menudo como sinónimo de cabecera (masthead).Existe una diferencia crucial entre el elemento header en HTML5 y el uso aceptado y generalizado de la palabra encabezado o cabecera. Por lo general en una página existe una sola cabecera pero un documento puede tener múltiples encabezados, o lo que sería lo mismo múltiple elementos “header”. Se puede utilizar un elemento header dentro de un elemento section por ejemplo. Las especificaciones describen los elementos section como “a thematic grouping of content, typically with a heading”, o sea, una agrupación temática de contenido, generalmente con un encabezado.

<section>
  <header>
    <h1>Ave del paraíso</h1>
  </header>
  <p>Narrativa policíaca y de intriga/Novela negra.</p>
  <p>CAROL JOICE</p>
</section>

El elemento header aparecerá por lo general en la parte superior de un documento o section, no tiene que ser así obligatoriamente. Ha sido definido por su contenido —introductorio o elemento para la navegación— sea cual sea su posición.

footer

Como el elemento header, footer (pie) suena como su descripción y ubicación. En cambio, el elemento footer deberá contener información sobre sus elementos de contenido: quien lo escribió, información de copyright, enlaces a contenido relacionado, etc.Mientras estamos acostumbrados a tener un pie para todo un documento, HTML5 nos permite también tienen pies dentro de las secciones.

<section>
  <header> 
    <h1>Ave del paraíso</h1>
  </header>
  <p>Narrativa policíaca y de intriga/Novela negra.</p>
  <footer>
    <p>CAROL JOICE</p>
  </footer>
</section>

aside

Así como el header coincide con el concepto de un “tope superior”, el elemento aside (en inglés: a un lado) coincide con el concepto de una “barra lateral”. Cuando digo “barra lateral”, no me estoy refiriendo a la posición. El hecho de que algunos contenidos aparezcan a la izquierda o a la derecha del contenido principal no es razón suficiente para utilizar el elemento aside. Una vez más, es el contenido el que importa, no la posición.El elemento aside se debe utilizar para un contenido que esté relacionado tangencialmente. Si usted tiene un contenido que considera debe estar separado del contenido principal, entonces probablemente sería adecuado utilizar el elemento aside para que contenga esta contenido. Pregúntese si el contenido que hemos colocado dentro de aside puede ser eliminado y esta acción no resta o altera el significado del contenido principal del documento o de la sección.

Por poner un ejemplo del tipo de contenido del que hablamos, podemos mencionar frases entrecomilladas con notable relevancia. (Imagen) Es un contenido directamente relacionado con el contenido principal, pero si se eliminara, este último no perdería su comprensión ni su estructura semántica.Recuerde, sólo porque su diseño visual requiere un cierto contenido que aparezca en una barra lateral, no significa necesariamente que aside es el contenedor que debe contener los elementos correctos.

nav

El elemento nav hace exactamente lo que usted cree. Contiene información de navegación, por lo general una lista de enlaces.Aclaremos un poco eso. El elemento nav está destinado a la información de navegación principal. El hecho de que un grupo de enlaces se agrupan en una lista no es razón suficiente para utilizar el elemento nav. Toda la navegación del sitio, en cambio, casi con toda seguridad pertenece al elemento nav.Muy a menudo, un elemento nav aparecerá dentro de un elemento header. Eso tiene sentido si se considera que el elemento header se puede utilizar para “ayudas a la navegación” o colocar el menú principal.

article

Es correcto pensar en header, footer, nav, y aside como bloques específicos del elemento section. Una sección es un trozo genérico de contenido que está relacionado, mientras que header, footer, nav, y aside son trozos de tipos de contenido específicos relacionado.El elemento article es otro tipo de sección especializada. Se utiliza como contenedor de un tipo de contenido que esté relacionado consigo mismo. ¿Difícil de entender?Pregúntese si se sindicará el contenido en un RSS o Atom feed. Si el contenido todavía tiene sentido en ese contexto, entonces article será probablemente el elemento correcto a utilizar. De hecho, article es un elemento que está diseñado específicamente para sindicación de contenido.Si usted usa el elemento time dentro de un elemento article, tiene la opción de añadir un atributo Booleano pubdate para indicar que contiene la fecha de publicación:

<article>
  <header>
    <h1>Título de la página</h1>
  </header>
  <p>Qué lindo el Sol esta mañana en Calcuta</p>
  <footer>
    El Cambio climático en la India
   <p>Publicado
    <time datetime="005-10-08T15:13" pubdate>
3:13pm 12 de Octubre de 2010
    </time>
por José Pérez</p>
  </footer>
</article>

Si tiene más de un elemento time en un artículo, solamente podrá uno de ellos podrá contener el atributo pubdate.

El elemento article es muy útil para artículos de Bitácoras (Blogs), noticias, comentarios, críticas y artículos de foros.

Lo que es más problemático es que article y section son muy similares. Todo lo que les separa es la palabra o el concepto “relacionado entre sí”. Sería muy fácil si existiera una regla a seguir, pero en este caso todo se basa en la “interpretación”. Se puede tener múltiples article dentro de una etiqueta section, se puede tener múltiples section dentro de un article, se pueden anidar article dentro de article y section dentro de section. Es cuestión de cada uno la selección que semánticamente más se adecue a uno u otro elemento teniendo en cuenta que “todo” el contenido de section debe estar relacionado entre si, y el contenido de article, que ha sido pensado para artículos y puedan ser sindicados.

Convertir de PSD a HTML

En este tutorial mostraremos como maquetar desde un layout PSD de una web hecha en Photoshop. Como ejemplo vamos a utlizar la nueva maqueta de este site.

Queremos maquetar este diseño:

1.- Creación de archivos

Crearemos una nueva carpeta que llamaremos “knowDB”, y dentro de esta carpeta crearemos otra carpeta llamada “images”. Abrimos un editor de texto plano y creamos un nuevo documento y lo grabamos como “styles.css” en el directorio “knowDB”. Creamos de la misma forma otro archivo que se llame “index.html



Abrimos ambos ficheros (styles.css e index.html) en nuestro editor de texto plano. Y colocamos el código de estructura base de estos archivos asi como el link desde el index al estilo css.La forma en la que maquetamos aqui el PSD es desde arriba hacia abajo, asi que empezaremos con las partes principales como el container, el títle y la navigation. La primera cosa que necesitamos es un contenedor o container que sostenga nuestro website, y entonces dentro del container habrá otro contenedor donde irá nuestro fondo. Y entonces ahi irá nuestro title y nuestra barra de navegación. Esto puesto en un borrador html5 es algo como esto:

index.html

[codebox 1]

Observese que para no perdernos en el código HTML marcamos con comentarios donde empieza un div y donde termina ese div.

2.- Importar imagenes desde Photoshop

Antes de empezar a realizar nuestro CSS, necesitamos importar imagenes desde nuestro PSD. En nuestro caso solo tenemos el logo de la imagen, porque no tenemos fondo , es decir nuestro fondo es blanco. Entonces desde Photoshop nos ponemos en la layer del logo , y seleccionamos esa imagen para copiarla en un nuevo archivo y grabarla como archivo .png. (no olvidar que al crear el nuevo archivo se haga con fondo transparente)

NOTA: La linea vertical la haremos con CSS.

3.- Creamos el estilo CSS

Ahora que ya tenemo nuestro conjunto de imagenes podemos añadir estilos CSS. El primer conjunto de estilos que escribiremos será los estilos del body que se repetirán a lo largo de todo nuestro site.

[codebox 2]

Como no queremos ni margenes ni padding alrededor de nuestro site los ponemos a 0. Queremos una familia de font comunes “Arial, Helvetica, sans-serif;” (esto es una pila de varios tipos de letra para cubrir aquellos usuarios que no tengan algun tipo de font instalado en sus sistema); le colocoamos un tamaño de 12 pixeles y el color #797979. En nuestro caso el color del fondo es blanco: #FFFFFF.

Pasamos ahora a definir los estilos de nuestro container y de nuestro fondo:

[codebox 3]

La anchura de nuestro div container la ponemos del ancho que tenga en nuestro archivo PSD (para ello activar las reglas de Photoshop y con la herramienta de seleccion y viendo la ventana de informacion se puede ver en pixeles el tamaño del objeto que queramos). Para este div ponemos tambien el margin a auto de forma que se quede centrado todo la web para todos los tipos de navegadores.

Despues ponemos estilo al div de mifondo, en nuestro caso no tiene efecto porque no tenemos fondo, pero en el caso de que tuvieramos una imagen de fondo es aquí donde se especifica. Ponemos la anchura para que sea la misma que la de nuestro container y queremos que se ajuste a la izquierda y por eso ponemos float:left.

Ponemos ahora estilo a nuestro logo y barra de navegación:

[codebox 4]

En la capa del logo ponemos la misma height y width de la imagen del logo.

En la capa de nav ajustamos la posición para que quede por debajo del logo y en vertical. Será aquí donde irá el árbol de categorias.

Vayamos ahora con el contenido que irá dentro de la etiqueta htmls section

The content div will be like a container for our content box, we just need to float it left and add a width of 511 pixels which is how wide i want it to be. If you view your HTML file in your browser you should have something like this.

CSS Errores típicos de los desarrolladores

[Fuente: http://sixrevisions.com/css/12-common-css-mistakes-web-developers-make/ ]

Dejando a un lado su aspecto exterior de lenguaje fácil, CSS es un sistema complicado, especialmente cuando lo estamos haciendo para una web a nivel profesional. La cantidad de formas diferentes de seleccionar un elemento es inmensa, sin mencionar el número de propiedades que puedes aplicar al elemento (-s) seleccionado (-s) y como le presentación cambia cuando soportas multiples navegadores y layout engines.

Por eso es fácil liarse con el CSS. Veamos algunos errores comunes que cometemos.

1. No utilizar un CSS Reset apropiado

Los navegadores web son unos amigos inconstantes. Sus inconsistencias pueden hacer que cualquier desarrollador quiera tirarse de los pelos. Pero por mucho que queramos al final del dia son los que presentan nuestra web, asi que mejor que nos llevemos bien con ellos.

Uno de las cosas más tontas que hacen los navegadores es proporcionarte un styling por defecto de los elementos HTML.Qué pasa si un webmaster elige no darle estilo a su página? Deberia haber un mecanismo para aquellos que eligen no utilizar CSS.

En cualquier caso, es raro el caso en el que dos navegadores proporcionen un styling identico, asi que la única forma de asegurarte que tus estilos son efectivos es hacer un CSS Reset.

Por CSS Reset entendemos resetear todos los estilos de todos los elementos HTML a un valor base predecible. Lo bueno de esto es que una vez que tu tienes un CSS Reset funcionando, entonces puedes dar estilo  todos los elementos de tú página como si fueran todos del mismo estilo para empezar. Es como crear una página en blanco.

Hay muchos CSS reset codebases en la web que puedes incorporar en tu trabajo. Una forma típica de hacer esto es utilizar un selector universal que haga un reset de margin y padding.

* { margin:0; padding:0; }

 

Aunque esto funciona , no es un reset completo. También necesitamos resetear por ejemplo, borders , underlines y colores de los elementos como list items, links y tables para no caer en inconsistencias entre diferentes navegadores.

Para más info: Resetting Your Styles with CSS Reset.

2.- Selectores sobre-cualificantes

Pasarse en ser especificos cuando seleccionamos elementos para darle estilo no es una buena práctica. Como por ejemplo:

ul#navigation li a { ... }

 

Typically the structure of a primary navigation list is a <ul> (usually with an ID like#nav or #navigation) then a few list items (<li>) inside of it, each with its own <a>tag inside it that links to other pages. This HTML structure is perfectly correct, but the CSS selector is really what I’m worried about.

First things first: There’s no reason for the ul before #navigation as an ID is already the most specific selector. Also, you don’t have to put li in the selector syntax because all the a elements inside the navigation are inside list items, so there’s no reason for that bit of specificity.

Thus, you can condense that selector as:

#navigation a { ... }

This is an overly simplistic example because you might have nested list items that you want to style differently (i.e. #navigation li a is different from #navigation li ul li a); but if you don’t, then there’s no need for the excessive specificity.

I also want to talk about the need for an ID in this situation. Let’s assume for a minute that this navigation list is inside a header div (#header). Let us also assume that you will have no other unordered list in the header besides the navigation list. If that is the case, we can even remove the ID from the unordered list in our HTML markup, and then we can select it in CSS as such:

#header ul a { ... }

Here’s what I want you to take away from this example: Always write your CSS selectors with the very minimum level of specificity necessary for it to work. Including all that extra fluff may make it look more safe and precise, but when it comes to CSS selectors, there are only two levels of specificity: specific, and not specific enough.

3. No utilizar properties abreviadas

Take a look at the following property list:

#selector {
  margin-top: 50px;
  margin-right: 0;
  margin-bottom: 50px;
  margin-left 0;
}

What is wrong with this picture? I hope that alarm bells are ringing in your head as you notice how much we’re repeating ourselves.

Fortunately, there is a solution, and it’s using CSS shorthand properties. The following has the same effect as the above style declaration, but we’ve reduced our code by three lines.

#selector {
  margin: 50px 0;
}

Check out this list of properties that deals with font styles:

font-family: Helvetica;
font-size: 14px;
font-weight: bold;
line-height: 1.5;

We can condense all that into one line:

font: bold 14px/1.5 Helvetica;

We can also do this for background properties. The following:

background-image: url(background.png);
background-repeat: repeat-y;
background-position: center top;

Can be written in shorthand CSS as such:

background: url(background.png) repeat-y center top;

Using shorthand CSS improves efficiency and makes it easier to maintain our code. For more information on CSS shorthand properties, check out this cheatsheet of CSS shorthand properties.

4. Utilizar 0px en vez de 0

Say you want to add a 20px margin to the bottom of an element. You might use something like this:

#selector { margin: 20px 0px 20px 0px; }

Don’t. This is excessive. There’s no need to include the px after 0. While this may seem like I’m nitpicking and that it may not seem like much, when you’re working with a huge file, removing all those superfluous px can reduce the size of your file (which is never a bad thing).

5.- Utilizar Color names en vez de valores hexadecimales

Declaring red for color values is the lazy man’s #FF0000. By saying:

color: red;

You’re essentially saying that the browser should display what it thinks red is. If you’ve learned anything from making stuff function correctly in all browsers — and the hours of frustration you’ve accumulated because of a stupid list-bullet misalignment that can only be seen in IE7 — it’s that you should never let the browser decide how to display your web pages.

Instead, you should go to the effort to find the actual hex value for the color you’re trying to use. That way, you can make sure it’s the same color displayed across all browsers. You can use a color cheatsheet that provides a preview and the hex value of a color.

This may seem trivial, but when it comes to CSS, it’s the tiny things that often lead to the big gotchas.

6. Selectores redundantes

Mi proceso para escribir estilos es empezar con la tipografia, y entonces trabajar sobre la estructura, y finalmente poner estilo de los colores y los fondos. Eso es lo que funciona para mi. Como en cada momento estoy poniendo estilos a varios elementos, un error muy común es teclear accidentalmente una declaración de estilo redundante.

Siempre hacemos un chequeo final después para estar seguros que no repito ningún selector; y si encuentro alguno repetido entonces refactorizo y los fundo.

Puedes mirar una lista de optimizadores CSS que te pueden ayudar:list of CSS optimizers

7. Properties redundantes

Similar al error anterior, a menudo me encuentro teniendo que aplicar las mismas properties a varios selectores.

Similar to the one above, I often find myself having to apply the same properties to multiple selectors. This could be styling an <h5> in the header to look exactly like the<h6> in the footer, making the <pre>‘s and <blockquote>‘s the same size, or any number of things in between.

In the final review of my CSS, I will look to make sure that I haven’t repeated too many properties. For example, if I see two selectors doing the same thing, such as this:


#selector-1 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}
.selector-2 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}


I will combine them, with the selectors separated by a comma (,):


#selector-1, .selector-2 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}


I hope you’re seeing the trend here: Try to be as terse and as efficient as possible. It pays dividends in maintenance time and page-load speed.

8. No proporcionar Fallback Fonts

No todos los equipos tienen todas las fonts instaladas

In a perfect world, every computer would always have every font you would ever want to use installed. Unfortunately, we don’t live in a perfect world. @font-faceaside, web designers are pretty much limited to the few so called web-safe fonts (e.g. Arial, Georgia, serif, etc.).

There is a plus side, though. You can still use fonts like Helvetica that aren’t necessarily installed on every computer. The secret lies in font stacks.

Font stacks are a way for developers to provide fallback fonts for the browser to display if the user doesn’t have the preferred font installed.

For example:

#selector {
  font-family: Helvetica;
}

Can be expanded with fallback fonts as such:

#selector {
  font-family: Helvetica, Arial, sans-serif;
}

Now, if the user doesn’t have Helvetica, they can see your site in Arial, and if that doesn’t work, it’ll just default to any sans-serif font installed.

By defining fallback fonts, you gain more control as to how your web pages are rendered.

9. Espacios en blanco innecesarios

When it comes to trying to reduce your CSS file sizes for performance, every space counts. When you’re developing, it’s OK to format your code in the way that you’re comfortable with. However, there is absolutely no reason not to take out excess characters (a process known as minification) when you actually push your project onto the web where the size of your files really counts.

Too many developers simply don’t minify their files before launching their websites, and I think that’s a huge mistake. Although it may not feel like it makes much of a difference, when you have huge CSS files, it can improve your page response times.

10. No organizar tu CSS de una forma lógica

When you’re writing CSS, do yourself a favor and organize your code. Through comments, you can insure that the next time you come to make a change to a file you’ll still be able to navigate it.

How you choose to organize your styles is completely up to you, whatever works. I personally like to organize my styles by how the HTML that I’m styling is structured. This means that I have comments that distinguish the header, body, sidebar, and footer.

A common CSS-authoring mistake I see is people just writing up their styles as soon as they think of them. The next time you try to change something and can’t find the style declaration, you’ll be silently cursing yourself for not organizing your CSS well enough.

11. Utilizar solo una stylesheet para todo

This one’s subjective, so bear with me while I give you my perspective.

I am of the belief, as are others, that it is better to split stylesheets into a few different ones for big sites for easier maintenance and for better modularity. Maybe I’ll have one for a CSS reset, one for IE-specific fixes, and so on.

By organizing CSS into disparate stylesheets, I’ll know immediately where to find a style I want to change. You can do this by importing all the stylesheets into a stylesheet like so:

@import url("reset.css");
@import url("ie.css");
@import url("typography.css");
@import url("layout.css");

Let me stress, however, that this is what works for me and many other developers. You may prefer to squeeze them all in one file, and that’s okay; there’s nothing wrong with that. But if you’re having a hard time maintaining a single file, try splitting your CSS up.

12. No proporcionar una Stylesheet de Print

In order to style your site on pages that will be printed, all you have to do is utilize and include a print stylesheet.

It’s as easy as:

<link rel="stylesheet" href="print.css" media="print" />

Using a stylesheet for print allows you to hide elements you don’t want printed (such as your navigation menu), reset the background color to white, provide alternative typography for paragraphs so that it’s better suited on a piece of paper, and so forth.

The important thing is that you think about how your page will look when printed. Too many people just don’t think about it, so their sites will simply print the same way you see them on the screen.