La verdad es que Firefox4 está de lujo, y las demos que ofrece Mozilla son increíbles. De una de ellas he sacado cómo hacer clipping en vídeos usando HTML5 y la posibilidad de incrustar SVG (sólo funciona en Firefox4).
El método es sencillo, tengo un SVG que muestra el contorno y los botones de play y pausa, además tiene un clipPath que se usará para el estilo clip-path del vídeo:
SVG
Vídeo
Javascript
var play = document.getElementById('play');
var pause = document.getElementById('pause');
var video = document.getElementById('video');
play.addEventListener('click', function() {
play.style.display = 'none';
pause.style.display = 'block';
video.play();
}, true);
pause.addEventListener('click', function() {
play.style.display = 'block';
pause.style.display = 'none';
video.pause();
}, true);
video.addEventListener("ended", function() {
play.style.display = 'block';
pause.style.display = 'none';
video.pause();
}, true);
El vídeo es el mismo que el de la demo de Mozilla, he puesto el borde semi-transparente para que se vea el clipping como va.
Interesante tutorial que nos enseña que problemas pueden encontrarse las personas con alguna discapacidad que le obligue a prescindir de Javascript (o usuarios con dispositivos móviles), y cómo solucionarlo.
Los mayores problemas con el que se encuentran las personas que no ejecutan javascript en sus navegadores son en la navegación (menús dinámicos), contenido oculto (accesible mediante Ajax), controles dinámicos (eventos de ratón, drag&drop, …) y confusión (la web está pensada para el uso de Javascript y no usarlo conlleva un contenido inicial deficiente).
Como resumen diría que hay que ofrecer los contenidos sin necesidad de javascript, éste sólo debe ser un apoyo, y que para comprobar si tu web es accesible lo mejor es probarlo inhabilitando el javascript en tu navegador. Creating Accessible JavaScript
Vía / @maxkuri
Algo bastante importante en un proyecto es la configuración y cómo se gestiona. Para facilitar la gestión usaremos dos librerías dotenv y confidence, la primera permite usar ficheros .env en nuestro entorno de desarrollo para simular variables de entorno. La segunda nos ayudará a recuperar las variables de un objeto permitiendo usar filtros, por ejemplo según de las variables de entorno.
Instalaremos los paquetes:
npm i dotenv
npm i confidence
Confidence necesitará un criterio que nos permitirá obtener distintos resultados según su valor. Imaginemos que tenemos el siguiente criterio:
Si queremos acceder al nivel de debug, al ser env igual a development, obtendíamos INFO.
Vale, ¿y cómo lo usamos en el proyecto? Primero creamos una carpeta config, donde crearemos el fichero index.js que tendrá toda la configuración del servidor:
const Confidence = require( 'confidence' );
const Dotenv = require( 'dotenv' );
Dotenv.config( { silent: true } );
// NODE_ENV is used in package.json for running development or production environmentconst criteria = {
env: process.env.NODE_ENV,
};
const config = {
port: 3001,
};
const store = new Confidence.Store( config );
exports.get = function( key ) {
return store.get( key, criteria );
};
exports.meta = function( key ) {
return store.meta( key, criteria );
};
Dotenv simplemente se usa para obtener de las variables de entorno de servidor el valor de NODE_ENV. Por ahora solo tendremos la variable port, pero ya estará preparado para poder añadir otras variables de configuración posteriormente.
Creamos un store de Confidence y exportaremos los métodos get y meta.
Haremos algo parecido para el manifest necesario para Glue, creando el fichero manifest.js dentro del directorio config:
Ya hace tiempo hablamos de un directorio donde podÃamos encontrar 30 cheat sheets, en este caso se trata de 170, que nos ayudarán en nuestro desarrollo web.
Aunque no todas son de desarrollo web, si la mayorÃa. Organizada por categorÃas, podemos encontrar ‘chuletas’ sobre: ActionScript, Ajax, Apache, ASCII, ASP, C#, CSS, CVS, Firefox, Google, HTML, Java, Javascript, LaTeX, microformatos, MySQL, Oracle, Perl, Photoshop/Gimp, PHP, Python, expresiones regulares, Ruby, Linux, blogs, Windows y XMLs.
Yo ya le he dado a imprimir unas cuantas que me van a venir muy bien. Cheat Sheet Round-Up: Ajax, CSS, LaTeX, Ruby
VÃa / Digg
Estando a la espera de que nos cuenten las diferencias entre un mal diseñador y un buen diseñador, que serÃa algo que necesitamos algunos, nos quedamos con un buen artÃculo que nos explica las diferencias entre un buen diseñador y un gran diseñador.
Se trata del tÃpico post que todo el mundo referencia y que uno se da cuenta que se entera de las cosas el último, por eso voy a referenciar donde lo he visto originalmente, donde lo he leido en español y por su puesto el original.
Entre las cosas que más me han gustado destaco lo siguiente:
…los artistas crean problemas, los diseñadores los solucionan. Pero un gran diseñador se adelanta a un problema potencial, tiene visión.
La conclusión a estas ideas nos lleva nuevamente a la razón de ser del trabajo de diseño, que es justamnente lo que diferencia además a un diseñador de un artista: las necesidades y problemas que atiende el diseño suelen ser -por lo general- ajenas al diseñador. El diseñador no es más que un instrumento comunicativo en esencia.
Project Kenay es una especie de SourceForge que ha realizado Sun y que aún está en fase beta. Dispone de pocos proyectos alojados (la mayoría basados en Java y Ruby) pero está empezando y vamos a tener que estar pendiente de este proyecto.
Kenai provee a los proyectos de SVN y Mercurial, foros, listas de correo, wikis, sistemas de bugs y personalización de tu página. Porject Kenai