Uninstallme

Desarrollo front-end, estándares web, accesibilidad y más

Coda Dark Theme para Textmate

Por kcmr, el 18 de julio de 2010 en Mac, Programas

Etiquetas: ,

Hay que ver para lo que da una tarde de domingo! Hoy me ha dado por crear un tema para Textmate, casi igual, al tema oscuro por defecto de Coda.

Funciona bien en el coloreado de sintaxis de HTML y CSS. La sintaxis de Javascript y PHP es bastante mejorable (lo dejo para otra tarde de domingo)

Coloreado de sintaxis HTML

Coloreado de sintaxis HTML en Textmate

Coloreado de sintaxis CSS

Coloreado de sintaxis CSS en Textmate

Descargar Coda Dark Theme para Textmate

Sin comentarios

Cuestionando los diseños elásticos

Por kcmr, el 17 de julio de 2010 en Accesibilidad, CSS, Usabilidad

Until user agents…

Quienes suelan consultar las WCAG (Web Content Accessibility Guidelines), tendrán esta frase grabada en la memoria: Hasta que los agentes de usuario permitan…. Pues bien, estoy segura de que con la lenta agonía de Explorer 6, muchos nos habremos preguntado hasta qué punto tiene sentido seguir utilizando unidades relativas para los tamaños de fuente, ya que el resto de navegadores no tiene problemas para escalar fuentes cuando su tamaño ha sido expresado en píxeles. ¿Correcto? Pues no.

Internet Explorer no escala las fuentes en píxeles

Hace relativamente poco tiempo descubrí algo que desconocía por completo: ninguna versión de Internet Explorer escala las fuentes cuyo tamaño ha sido expresado en píxeles:

Es fácil no darse cuenta de este detalle porque cuando utilizamos la combinación de teclas Ctrl + o Ctrl – en Explorer (versiones superiores a la 6), activamos el zoom de página con resultados aparentemente similares a los que obtendríamos aumentando el tamaño de fuente, por lo tanto, sigue teniendo sentido utilizar unidades relativas para los tamaños de fuente.

Zoom de página y escalado de texto

Ahora bien, ¿hasta qué punto es correcto utilizar unidades relativas para todo? La mayoría de navegadores actuales, <ironia>excepto Explorer 6</ironia>, nos proporcionan inteligentemente dos formas de zoom: zoom de página completa o ampliar sólo texto.

Escalado de texto en Firefox

Escalado de texto en Firefox

Google Chrome y Opera sólo proporcionan zoom de página completa. Parece que a algunos usuarios de Chrome están algo descontentos: Need a text-only Zoom.

Teniendo en cuenta que la resolución mayoritaria, en portátiles y ordenadores de sobremesa, sigue siendo de 1024, y que las páginas se diseñan para esta resolución, en el momento en que hacemos zoom de página completa aparecen las molestas barras de scroll horizontales.

Si nuestro diseño es elástico, es decir, los tamaños de bloques contenedores se expresan en emes, estamos rompiendo la capacidad del navegador de ampliar sólo texto o hacer zoom de página, ya que al ampliar sólo texto aumentarán también los tamaños de bloques con las consecuentes barras de scroll horizontales, y si hay algo cierto, es que a nadie le gusta el scroll horizontal.

“Low-vision users don’t like horizontal scrolling.” I’ve not done extensive research in this area myself, so it’s hard to counter-argue. Besides, it’s safe to say nobody — good vision or not — likes horizontal scrolling.

We found during usability testing for a site with a large proportion of users with vision problems that most of them preferred to use text zoom instead of page zoom because page zoom almost always means horizontal scrolling.

¿La mejor elección de diseño?

Quizá el diseño perfecto sea el híbrido líquido-elástico (vaya nombrecito), pero es difícil de llevar a cabo y no está libre de problemas. Opera y Webkit (Safari / Google Chrome) comparten un bug: ignoran los decimales en porcentajes. (Demo del bug). Explorer tampoco se lleva especialmente bien con los porcentajes.

CSS 3 nos brinda nuevas posibilidades que nos permiten adaptar el diseño en función de la resolución de pantalla, las Media Queries, opción que podemos usar ya para los navegadores que pueden beneficiarse de ello, especialmente para iPhone y otros dispositivos móviles.

Mi elección

Personalmente, llevo una temporada utilizando la opción de expresar los tamaños de bloques en píxeles y los de fuentes en emes, siendo consciente de que el uso de píxeles está penalizadísimo, tanto por revisores automáticos de accesibilidad como humanos, e incluso diría que mal visto entre maquetadores, pero las “normas” siempre hay que cuestionárselas para llegar a mejoras. Como ejemplo, muchas de las pautas que se cuestionaban de las WCAG 1 en las Samuray Errata, se han modificado en las WCAG 2.

Qué dicen las WCAG

En las WCAG no se dicta una opción concreta a utilizar en cuanto a tipo de diseño, simplemente se ofrecen unas pautas y una serie de técnicas para ayudarnos a conseguirlas. Algunas de estas técnicas:

Using percentage values in CSS for container size

The objective of this technique is to make it possible for users who need to increase the size of text in order to read it will not have to scroll horizontally in order to read a line of text.

Using relative measurements to set column widths so that lines can average 80 characters or less when the browser is resized

The purpose of this technique is to ensure that CSS is used in a way that allows users to view content in such a way that line length can average 80 characters or less. [...] This technique also allows for column width to grow wider as font sizes increase, which will reduce the possibility of clipping as the text size increases..

En ningún momento se propone la técnica de usar unidades absolutas para contenedores, sino más bien todo lo contrario. Si no me equivoco, tampoco se prohibe o desaconseja expresamente el uso de píxeles para contenedores, simplemente se insiste en que el texto pueda escalarse sin que aparezca cortado y a ser posible, sin que sea necesario utilizar el scroll horizontal para leer una línea completa.

Conclusión

Ahí están los problemas de los diseños elásticos y algunas de las recomendaciones para cumplir con las pautas de accesibilidad para que cada uno elija la opción más apropiada, teniendo siempre en cuenta el púbico objetivo de una web y las capacidades de los navegadores más usados en cada momento.

Más información

2 Comentarios

Dejo aquí una pequeña ayuda para los que nos peleamos con los themes de Magento. Es un bookmarklet para Firefox y Safari o Google Chrome que simplemente sirve para ocultar y volver a mostrar las rutas de plantilla de Magento, que son tan útiles como molestas.

Las rutas de plantilla tienen que estar activadas desde la administración.

Para usarlo arrastra este link a la barra de marcadores: Rutas de plantilla.

Sin comentarios

Crear un plugin con jQuery

Por kcmr, el 6 de junio de 2010 en Javascript, jQuery

Etiquetas:

Quienes suelan leer este blog sabrán que soy de Mootools, pero empecé con jQuery. Donde trabajaba entonces todo el mundo usaba Prototype, así que me pasé pronto a este framework y mi jQuery se quedó olvidado hasta tal punto de que cada vez que intento tocar un script en jQuery las paso canutas, acostumbrada a la forma de hacer las cosas en Mootools y Prototype, que es bastante parecida.

La verdad es que a juzgar por las veces que se nombra jQuery en blogs y la cantidad de plugins disponibles para esta librería, diría que es la más popular y la preferida de muchos, así que me voy a obligar a ponerme las pilas.

Captura de la comparación del volumen de búsqueda en Google entre jQuery y Mootools (Fuente: Google Trends)

Una de las cosas que no me gustaba de jQuery, en comparación con Mootools o Prototype, es que no se pueden crear “clases”. Las clases permiten de una forma fácil crear scripts reutilizables que incluso se pueden extender. A decir verdad, nunca he tenido la necesidad de extender una clase.

En jQuery se pueden crear plugins, esto es añadir un método de nuestra propia cosecha a jQuery, para utilizar sobre los elementos que queramos y con las opciones que pasemos como parámetro, como si fuera un método más de jQuery.

Podríamos crear un método llamado miPlugin() que se utilizaría así:


$('#id').miPlugin({
	opcion: 'valor',
	opcion2: 'valor2'
});

Como estoy un poco cruda en cuanto a los métodos de jQuery, voy a usar un ejemplo bastante tonto a fin de ilustrar la forma de crear un plugin. El plugin se limita a cambiar los colores de primer plano y fondo del objeto clicado y reemplazar o añadir un texto.

En primer lugar tenemos que evitar que pueda entrar en conflicto con otras librerías, para lo que meteremos nuestro plugin dentro de una función anónima. De paso también evitamos tener variables globales.


(function($){
 … código
})(jQuery);

Extendemos jQuery añadiéndole nuestro método.


$.fn.miPlugin = function(options){
}

He pasado como parámetro options, que será un objeto con todas las opciones personalizables que sobrescribirán a las opciones por defecto del plugin. Esas opciones por defecto están dentro de un objeto que hemos llamado defaults.


var defaults = {
	colorFondo: 'red',
	colorTexto: 'white',
	texto: 'Hola, me has clicado'
	animar: true
}

Necesitamos extender estas opciones por defecto con las opciones que se pasen como parámetro.


var options = $.extend(defaults, options);

De esta forma, nos referiremos a las opciones en el código del plugin mediante options.nombreOpcion

Por último inicializamos la función y escribimos el código necesario.


return this.each(function(){
	$(this).bind('click', init);
});

Todo junto:


(function($){
	$.fn.miPlugin = function(options){
		var defaults = {
			colorFondo: 'red',
			colorTexto: 'white',
			texto: 'Hola, me has clicado',
			animar: true
		};
		var options = $.extend(defaults, options);
		return this.each(function(){
			$(this).bind('click', init);
		});
		function init(ev){
			ev.preventDefault();
			$(this).css({
				background: options.colorFondo,
				color: options.colorTexto
			}).text(options.texto);
			if(options.animar){
				$(this).css('display', 'block').animate({
					'width': 300
				});
			}
		};
	}
})(jQuery);

Ya podemos usar nuestro método sobre el elemento que queramos. Ejemplos:

Con las opciones predeterminadas:

$('a').miPlugin();
Cambiando los colores de fondo y primer plano:

$('a').miPlugin({
	colorFondo: 'black',
	colorTexto: 'red'
});
Sin animación final:

$('a').miPlugin({animar: false});

Pues hasta aquí mi pequeña contribución para los “jQuerianos”. Probablemente nada nuevo para los más experimentados, pero ha sido un gran descubrimiento para mí y he querido compartirlo. Espero ir publicando más cosillas próximamente (sin tener que justificarme)

Demo del ejemplo

Más información

4 Comentarios

Optimización de CSS e imágenes

Por kcmr, el 2 de junio de 2010 en CSS, HTML

Etiquetas:

Dejo una presentación muy interesante sobre optimización de imágenes y CSS. Los temas que se tratan son:

Escritura efectiva de CSS
Se explican unos sencillos consejos para evitar el uso de selectores “poco eficientes”.
Algunos enlaces relacionados con el tema:
Prácticas a evitar
AlphaImageLoader, archivos .htc
Reducción de peticiones HTTP
Uso de sprites, técnicas de CSS 3, imágenes codificadas en base 64, etc
Mi punto preferido: uso de PNG 8

Este formato menospreciado, muchas veces en favor del clásico GIF, suele dar mejores resultados que este además de pesar menos, sin olvidar que admite transparencia alpha que degrada “correctamente” en Internet Explorer 6. Eso sí, Photoshop no permite exportar PNG 8 con transparencia alpha, Fireworks sí.

Otros cuantos enlaces relacionados con el tema de la optimización de PNG:

2 Comentarios

Una de las primeras preguntas que me hice cuando empecé a usar Mac, hace ya casi un año, fue “¿dónde está la tecla de imprimir pantalla?”

Después descubrí todas las opciones para hacer capturas de pantalla en Mac y me olvidé para siempre de la tecla. Este mismo proceso se va repitiendo con todo en las primeras semanas de switcher. Sin embargo había una cosa que me molestaba, y es que las imágenes de capturas se guardaran en el escritorio por defecto en lugar de hacerlo en la carpeta de descargas que, personalmente, me resulta más cómodo ya que uso un plugin para mantener el escritorio limpio y despejado.

Recientemente encontré unos cuantos truquillos para cambiar el comportamiento por defecto de las capturas de pantalla, entre ellos, el comando a ejecutar para cambiar la carpeta por defecto en la que se guardan las capturas:


defaults write com.apple.screencapture location "Carpeta deseada"
killall SystemUIServer

Otros de los comandos sirven para cambiar el formato de archivo, el nombre o incluso desactivar la sombra en las ventanas.

Sin comentarios

El uso del pseudoprotocolo (href="javascript:nombreFuncion();") en enlaces es una mala práctica de acuerdo con las normas del Javascript no intrusivo. Los enlaces deben tener una url válida que funcione sin Javascript. Por ejemplo, un enlace que abre una popup debe tener una url en su atributo href, de manera que sin Javascript siga siendo un enlace válido.

Pero no todos los enlaces que ejecutan alguna función Javascript tienen que tener una url en su atributo href. Algunos sirven para realizar acciones dentro de la propia página, como puede ser mostrar / ocultar una capa, pasar a la imagen siguiente en un carrusel, etc.

En estos casos, lo correcto es crear esos enlaces con Javascript, ya que sólo con Javascript habilitado tienen sentido (no deben estar previamente en el código HTML), y asignarles como atributo href una almohadilla (#) o dejarlo vacío.

En algún blog que no consigo encontrar proponían usar para este tipo de enlaces el pseudoprotocolo javascript: u otro que consideremos más apropiado (inventado), como podría ser imagen:.

De esta forma, estos enlaces proporcionan información acerca de su función al hacer rollover sobre ellos o cuando tienen el foco. Esta información suele aparecer en la barra de estado del navegador. También es útil para usuarios de lectores de pantalla que puedan tenerlos configurados para no leer el atributo title.

Atributo href del enlace mostrado en la barra de estado de Firefox

Atributo href del enlace mostrado en la barra de estado de Firefox

Habrá quien se preguntará si es correcto asignar este tipo de funciones a enlaces en lugar de a otros elementos HTML. La respuesta es que sí, ya que los enlaces pueden tener de forma natural el foco y ser activados cuando se utiliza el teclado para navegar y moverse por la página.

Sin comentarios

En Cool Z están buscando un diseñador web con las ideas muy claras en cuanto a arquitectura de la información y usabilidad, que se mantenga al día de las nuevas tendencias de diseño, internetero, sensibilizado con la accesibilidad, conocedor de los estándares web (HTML, CSS) y las posibilidades de las librerías Javascript.

Los interesados pueden enviar URL’s de trabajos en los que hayan participado a través del formulario de contacto o bien recomendar a alguien que encaje con la descripción.

Más detalles de la oferta para diseñador web en el Blog de Cool Z.

Sin comentarios

Cada vez son más los sitios que usan @font-face y por fin parece que el abanico de fuentes disponibles en páginas web deja de estar limitado a Arial, Verdana, Georgia y poco más. De todos los métodos que se han usado durante años para utilizar fuentes que no son de sistema, @font-face es sin duda el más accesible, pero ¡cómo no!, la cosa no podía ser tan fácil. Una vez más es Internet Explorer el que tenía que causar algún problema.

Cuando el suavizado de fuentes mediante ClearType está habilitado en Windows o el suavizado de fuentes está desactivado por completo, Internet Explorer muestra algunas fuentes embebidas mediante @font-face con un aspecto pixelado. Si el tamaño de fuente es pequeño se empeora la legibilidad.

Suavizado de texto desactivado

Suavizado de texto mediante ClearType

Este problema no ocurre cuando está activado el suavizado estándar.

Suavizado de texto estándar de Windows

Este efecto pixelado se puede corregir mediante una técnica algo sucia. Consiste en la utilización de un filtro CSS para desactivar el suavizado de texto. Funciona porque Internet Explorer no aplica el suavizado de texto mediante ClearType a los elementos con filtros CSS propietarios.

Código CSS:


.suavizado{ filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=hIEfix.png,sizingMethod=crop);
min-height: 0;
color: green;}

Utilizando este filtro el resultado es el que se puede ver en las siguientes capturas:

Suavizado de texto desactivado. Texto verde con filtro CSS

Suavizado mediante ClearType. Texto verde con filtro CSS.

Sin embargo esta técnica tiene otro problema, y es que al hacer zoom para aumentar el tamaño de fuente, aparecen bordes negros alrededor de la fuente que nuevamente dificultan su legibilidad. Eso sí, sobre fondo negro no se aprecia este fallo, pero sobre fondo blanco nos encontramos con este aspecto:

Zoom sobre texto con filtro CSS. Legibilidad empeorada.

Si decidimos utilizar esta técnica sería recomendable ofrecer también un método para desactivarla a petición del usuario, por ejemplo mediante la adición o eliminación de una clase CSS a los elementos afectados.

Quizá con Internet Explorer 9 tengamos más suerte.

Más información en Smoother @font-face embedding in IE 7 & 8

Actualización 22 de marzo de 2010

Parece que el problema que comentaba de los bordes negros al hacer zoom se soluciona simplemente añadiendo un color de fondo al texto. Por otra parte, tal y como dice Paul Irish en este comentario, el filtro utilizado (AlphaImageLoader) provoca un consumo excesivo de memoria, por lo que es mejor usar otro filtro.

Resumiendo, el código CSS encargado de suavizar la fuente embebida quedaría así (Utilizo min-height: 0 en lugar de zoom: 1 como proponen en el post de referencia)


.suavizado{filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=100); min-height: 0; background: #000;}

Con esta sucia pero eficaz técnica conseguimos un suavizado perfecto en Internet Explorer (versiones superiores a la 6) independientemente del método de suavizado de texto que se esté usando en el Sistema Operativo.

3 Comentarios

LESS: variables y operaciones en CSS

Por kcmr, el 9 de febrero de 2010 en CSS, Utilidades

LESS es una extensión de CSS escrita en Ruby que permite utilizar variables, operaciones, reglas anidadas y mezclas con paso de parámetros que se comportan como funciones.

De todas sus posibilidades, las dos que me resultan más interesantes y que voy a comentar son el uso de variables y las operaciones.

Instalación de LESS

En Mac OS X, que ya tiene instalado ruby y ruby-gems, es tan sencillo como escribir esta línea en la consola:


$ sudo gem install less

En Windows y Linux hay que instalar primero ruby y ruby-gems.

Una vez instalado podemos utilizar LESS escribiendo nuestro CSS en un archivo .less tal y como lo haríamos con un archivo .css, con la diferencia de que es necesario compilarlo.

Compilación de LESS

Para compilar un archivo .less escribimos lo siguiente en la consola:


lessc style.less style.css

Si no se especifica el archivo de destino, se creará uno con el mismo nombre pero con la extensión .css. Es decir, la siguiente línea generaría un archivo style.css


lessc style.less

Compilación automática

Afortunadamente, no es necesario compilar el archivo manualmente cada vez que hacemos cambios, ya que es posible detectar los cambios en el archivo .less y compilar automáticamente. Para hacer esto utilizamos la instrucción –watch sobre el archivo que queremos compilar:


lessc style.less --watch

Uso de variables y operaciones

Sobre las ventajas del uso de variables en CSS sobran las explicaciones. A todos nos gustaría poder definir unas variables para colores de enlaces, texto, encabezados, fondos, etc. y poder usarlas cuando sea necesario sin tener que rebuscarlas en la CSS. También a la hora de hacer un cambio global resulta mucho más cómodo cambiar solamente el valor de una variable que todas las coincidencias. (Sí, conozco el buscar y reemplazar).

Para mí, el uso de variables no es su punto más fuerte, ya que se pueden usar varibles en CSS mediante PHP u otro lenguaje o incluso creando atajos de teclado personalizados en tu editor de texto, de manera que cada vez que tecleas, por ejemplo, colorLink seguido de tabulador, se escribe un color hexadecimal definido previamente. Esta última opción se puede usar con Coda (Mac).

Lo que más me ha gustado de LESS es la posibilidad de realizar operaciones, algo que ahorra bastante trabajo cuando se utilizan diseños elásticos.

Operaciones CSS en diseños elásticos

En los diseños elásticos, una unidad es relativa al elemento al que se refiere. Por ejemplo, si tenemos un encabezado de 20px de tamaño de fuente, con un margen inferior de 7px, esos 7px deben calcularse respecto a los 20 del encabezado, de manera que tenemos que hacer una división (7 / 20).


h2{font-size: 2em; margin-bottom: .35em;}

Con LESS podemos escribir esta división en la CSS.


h2{font-size: 2em; margin-bottom: 7 / 20em;}

Se añade el em al 20 para conservar la unidad de medida. De otra forma el resultado sería 0.35 en vez de 0.35em;

Además de ahorrarnos la operación, ya sea mediante calculadora o cabeza (siempre supone un esfuerzo), podemos ver inmediatamente qué unidad en píxeles estamos manejando en cada momento, es decir, nos ahorramos la multiplicación correspondiente o la ojeada al Firebug.

Inconvenientes de LESS

Agrupación de selectores

Si escribimos algo como h2 a, h3 a, h4 a{font-weight: normal;} el resultado al compilar es
h2 a{font-weight: normal;}
h3 a{font-weight: normal;}
h4 a{font-weight: normal;}

Saltos de línea

Al compilar, cada declaración se escribe en una línea dando lugar a archivos más pesados.

@import y @media

Simplemente, no funcionan. Las variables en LESS van precedidas del signo arroba.

Transformación de colores en formato hexadecimal a palabras clave.

#fff se convierte en white.

Estos inconvenientes se pueden solucionar con la ayuda de alguna herramienta de compresión como Clean CSS, que permite agrupar selectores, eliminar saltos de línea, utilizar las formas cortas de códigos de color, etc.

Otra herramienta útil es MinifyMe, una aplicación en Adobe AIR que se limita a eliminar comentarios y dejar todo el código en una sola línea. También sirve para comprimir Javascript.

Más información sobre uso e instalación en la documentación oficial de LESS

1 Comentario