Amo Firebug, odio Dreamweaver

11 octubre 2007 - Software | Navegadores

Firebug

Mi vida online se divide en antes y después de Firebug. Es la herramienta definitiva, impresionante. Con firebug montar HTML + CSS se convierte en un coser y cantar donde ni siquiera importa tener ordenado el código, Firebug te dice todo sobre tus estilos: cómo afectan a un elemento, en qué orden, qué está haciendo que abulte lo que abulta... Firebug es impresionante. (sólo le falta ser editor de código, pero todo se andará.)

Del otro lado tenemos Dreamweaver. Yo siempre he usado DW, aunque lo que estaba de moda para ser un "codemaster" es utilizar un editor a pelo o un block de notas, la comodidad de tener el gestor de sites en el editor y el autocompletador de etiquetas me hacían decantarme por DW. Pero llevo unos meses que me tiene harto. El puñetero DW se queda atrapado cada vez que tengo más de un archivo abierto, es cambiar un valor en un CSS y DW tarda como 10 segundos en reaccionar cuando volvemos del navegador para continuar los cambios. Es una patata, es una castaña y, además, ahora es Adobe, con lo que pinta que poco a poco se irá convirtiendo en algo peor (odio a Adobe sí, se han cargado Freehand y cada versión de Fireworks que sacan es más castañera y Photoshopera que la anterior).

Total, que con Firebug ya sólo necesito un editor de código pelón y con FTP pelado. en Mac lo tengo claro: Smultron - Textmate - Coda (los tres me molan), pero en Windows, ni idea. ¿Quién me sugiere uno?

icono de del.icio.usmás... Comentarios [12]

Formularios basados en retículas CSS

30 julio 2007 - Software |

Esta técnica describe cómo montar formularios básándose en una retícula usando CSS en lugar de tablas. No es la técnica definitiva pero, por ahora, es la mejor conclusión a la que he llegado.

formulario

La idea es definir la anchura de los campos del formulario basándonos en la etiqueta <label>. Esta etiqueta se utiliza para mostrar el nombre de cada campo y puede codificarse de dos maneras:

Una de ellas es aplicándole el parámetro for para relacionar cada label con el input/select/textarea que le corresponda.

<label for="nombre">Nombre:</label><input type="text" name="nombre />

La otra manera, que es la que utilizaremos aquí, es englobar el input/select/textarea dentro de una etiqueta <label>, de modo que ya no es encesario emplear el parámetro for para establecer la relación:

<label>Nombre:<input type="text" name="nombre /></label>

La maqueta basada en retícula supone, antes de nada, establecer la retícula. Para el ejempo usaré pixels, aunque puede hacerse también con porcentajes o con ems.

Vamos a maquetar un formulario de 300px de ancho basado en una retícula de 3 columnas, así que cada columna tendrá 90pixels de ancho y 10px de margen derecho.

Sobre esta retícula, podemos tener campos que ocupen 1, 2 ó 3 columnas, resultados campos de:

  • ancho1 (100) = 90px + 10px de margen
  • ancho2 (200)= 190 +10px de margen
  • ancho3 (300)= 290 +10px de margen

Bueno, ya tenemos las premisas para empezar a construir nuestro CSS.

Primero, al formulario le daremos el ancho de la retícula que nos hemos propuesto: 300px, aunque puede tener más si nos conviene para la estética, añadir padding..: realmente el formulario no influirá en la retícula, lo ponemos así por un cuestión formal.

.formulario 
{padding:0; width:300px;overflow:hidden;}

Ahora, pondremos los labels a flotar para que se vayan apilando uno a continuación del otro. Les daremos un margen derecho de, por ejemplo, 10px para separar las columnas de la retícula del formulario. Además de esto, para que el apilamiento funcione bien, forzaremos la altura de los labels ya que los select y los inputs no pintan igual en IE, de modo que los bloques de labels, al tener distinta altura, no se apilarían bien. Le damos un poco más de lo que pensamos que tendrá de altura un label (un em para el texto, otro em para el input/select y otro em para que exista margen vertical entre cada renglón de campos).

.formulario label
{float:left; margin-right:10px; height:3em}
.ancho1 {width:90px;}
.ancho2 {width:190px;}
.ancho3 {width:290px;}

Sólo falta decirle a los inputs y selects que ocupen todo el ancho de su contenedor, ya que son realmente los labels los que están fijando la anchura de cada campo.


.formulario input, .formulario select, .formulario textarea 
{width:100%;}

Si decoramos los campos con un borde por CSS, debemos reducir un poco el ancho ya que IE sumará al 100% los pixeles del border desbaratándolo todo.


.formulario input, .formulario select, .formulario textarea
{border:1px solid blue; width:99%;}

Ahora sólo nos falta el botón de enviar. Para que haga juego con nuestros labels apilados, lo flotamos a la izquierda y le damos margen superior de 1em para compensar que el botón no lleva el texto de un <label> por encima.


.formulario button
{float:left; margin-top:1em;}

Total, nos quedaría algo así:

CSS


.formulario
{padding:0; width:300px;overflow:hidden;}
.formulario label
{float:left; margin-right:10px; height:3em}
.formulario input, .formulario select, .formulario textarea
{border:1px solid blue; width:99%;}
.ancho1 {width:90px;}
.ancho2 {width:190px;}
.ancho3 {width:290px;}
.formulario button
{float:left; margin-top:1em;}

XHTML


<form class="formulario" action="#">
<label class="ancho1">
Tratamiento:
<select name="tratamiento">
<option value="1">Señor</option>
<option value="2">Señora</option>
<option value="3">Señorita</option>
</label>
<label class="ancho2">Nombre:<input type="text" name="nombre"/>
<label class="ancho3">Apellidos:<input type="text" name="nombre"/>
<label class="ancho1">Edad:
<select name="edad">
<option value="niño">0-15 años</option>
<option value="joven">15-35 años</option>
<option value="maduro">35-60 años</option>
<option value="viejo">60 o más</option>
</select>
</label>
<button type="submit">Enviar</button>
</form>

Y este sería el resultado (añádase algún detalle CSS para dejarlo curioso):

icono de del.icio.usmás... Ésto aún está un poco verde ¡Se admiten sugerencias! [4]

input type="search": ¿Validamos o pintamos?

20 junio 2006 - Software |

Llevaba tiempo puteado porque con Safari el buscador de tocomocho no se veía redondito como yo quería, hasta que pasando por sofanaranja me encontré un buscador 100% macos. ¡Qué cabrón, lo tiene redondito (el buscador)!

detalle capturas de pantalla buscador con Safari y con Firefox

Me faltó tiempo para darle a "ver código fuente" y allí estaba, el input del buscador no era type="text", era type="search". Acto seguido, copiazo y pegado en tocomocho y voilá, ¡ya tenía el buscador redondeado en Safari!

La parte mala del asunto es que type="search" no valida y, aunque degrada sin problemas, me pone muy nervioso pasar el validador y que me saque un fallo. (puedo oir vuestras voces implacables: qué capullo tocomocho, que no le valida la página....)

También ví en el blog de Ale que está usando el parámetro placeholder para indicar -sólo en Safari- el texto que debe aparecer en el input cuando este no tiene el foco sobre él. Más de lo mismo: no valida pero degrada. Safari reconoce este parámetro y se pasa por el forro el resto, al igual que hace con el CSS que afecte al input (salvo en el ancho).

Y ahora ¿qué hacemos? ¿usamos type="search" y placeholder="buscar en tocomocho" o validamos?

Personalmente creo que no hay que ser más papistas que el Papa, y que lo importante de usar un validador -más allá de obsesiones y manías -es saber que no estamos pasándonos por el forro los estándares en general. Yo no tengo reparos en usar en mis CSS -moz-border-radius, por ejemplo, para redondear esquinas de cosas en Firefox y no creo que por ello se termine el mundo. Pero si alguien me ofrece argumentos de peso para dejar de redondear mis inputs de búsqueda en Safari estoy dispuesto, al menos, a leerlos y tenerlos en cuenta.

icono de del.icio.usmás... Qué ¿validamos o pintamos? [5]

Tu blog en pelotas por un día

4 abril 2006 - Diseño |

5 de abril tu web sin CSS: algunos sites se ven francamente mejor así, pero esa es otra historia…

La idea se le ha ocurrido a Dustin. No sé si es un motivo sincero o una estratagema de tantas para rascar tráfico hacia su blog, pero bueno, si quiere tráfico, démosle tráfico: ¡pan y circo, pan y circo!

A mi me parece un poco como el día sin coches, pero en fin, como esto no deja de ser un juego, juguemos.

Propongo los siguientes días:

  • Día sin tag clouds.
  • Día sin technorati tags.
  • Día sin “mis fotos de flickr”
  • Día sin buscadores de google hasta en la sopa.
  • Día sin “archives” kilométricos en la home.
  • Día sin la frase “Me entero de X vía Y, (gracias Z por el enlace)”.
  • Día sin contadores de visitas.
  • Día sin estadísticas de Alexa.
  • Día sin dedicarse exclusivamente a enlazar gilipolleces de youtube.

icono de del.icio.usmás... Y tú ¿qué día "geek" propondrías? [5]

« Anterior


Esta web no ha sido hecha con un Mac, no se ha programado con RnR y no pertenece a 9rules,
aun así, puede que te interese.

Construído con ayuda de Textpattern 4.0.7.

©© 2006 Jorge Hernández Condiciones de uso - Publicidad | XHTML - CSS | RSS - Atom