Eliminar el botón de los campos password de IE10

Internet Explorer 10Hace sólo unos días veíamos cómo eliminar y personalizar los botones que Internet Explorer 10 añade a nuestros cuadros de edición estándar, pero nos dejábamos por detrás un caso especial: los controles de edición de contraseñas, o sea, los <input type="password"> de toda la vida.

En esta ocasión, IE10 muestra por cortesía un pequeño icono con forma de ojo, que permite visualizar el contenido del campo mientras lo mantenemos pulsado:

Botón de visualizar contraseñas en IE10
Si por cualquier razón queremos eliminar este botón, debemos utilizar una técnica similar a la que vimos en el post anterior, esta vez utilizando el pseudoselector -ms-reveal, así:

1
2
3
input::-ms-reveal {
    display: none;
}

Y por supuesto, podríamos utilizar también este enfoque para personalizarlo y adaptarlo mejor al look de nuestro sitio web:

1
2
3
4
input::-ms-reveal {
    color: white;
    background-color: red;
}

Con lo que tendríamos un resultado:

image

Publicado en: Variable not found.

Eliminar el botón de limpiado de controles de IE10

Internet Explorer 10Va un truquillo rápido. Los que ya habéis saltado a Internet Explorer 10 seguro habréis notado el pequeño botón que este navegador añade a los cuadros de edición estándar cuando obtienen el foco, y que permite limpiar rápidamente su contenido:

Botón de limpiar campo de IE10
Pues bien, hay veces que a nivel de diseño no nos interesa que se muestre la pequeña “X” en los controles, su posición entra en conflicto con otro elemento visual, o simplemente no queremos aportar esta funcionalidad,  por lo que es posible desactivar esta característica de los <input> usando CSS:

1
2
3
input::-ms-clear{
    display: none;
}

Tan sencillo como eso.

Pero seguro que te estás preguntando, ¿y en vez de eliminarla puedo personalizarla? Pues un poco también 😉 Observad el siguiente código:

1
2
3
4
5
input::-ms-clear{
    background-color: red;
    color: white;
    border: 1px solid #808080;
}

En tiempo de ejecución, esa discreta e insípida “X” se habría convertido en algo bastante más contundente 😉

image

Publicado en: Variable not found.

¿Añadir una barra al final de las URL?

ASP.NET MVCHace poco veíamos que el nuevo sistema de routing usado por proyectos MVC 4 permitía una cierta configuración del formato de URL generadas por la aplicación al usar helpers como Url.Action() o Html.ActionLink(), y cómo usando una simple línea de código podíamos hacer que las rutas se generaran usando sólo minúsculas.

Pues bien, al igual que en ese caso, en los proyectos que usen la última versión del ensamblado System.Web.Routing, por ejemplo si compilamos aplicaciones Webforms, MVC 3 o 4 para .NET 4.5, también es posible hacer que las URLs generadas acaben con una barra inclinada estableciendo a true la propiedad AppendTrailingSlash :

1
2
3
4
5
6
7
8
9
10
11
12
public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
 
    routes.AppendTrailingSlash = true;
 
    routes.MapRoute(
        name: "Default",
        url: "{controller}/{action}/{id}",
        defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
    );
}

La siguiente tabla muestra algunos ejemplos de cómo afecta el valor de esta propiedad a la hora de generar una ruta:

Instrucción AppendTrailingSlash
true false
Url.Action("About", "Home") /Home/About/ /Home/About
Url.Action("Edit", "Product", new {id = 1}) /Product/Edit/1/ /Product/Edit/1
Url.Action("Edit", "Product", new {id = 1, x=2}) /Product/Edit/1/?x=2 /Product/Edit/1?x=2

Pero, ¿por qué tendríamos que añadir una barra al final de las URL?

Es cierto que, siguiendo las tradiciones y buenas costumbres de siempre, una URL debería acabar en una barra si no apunta a un archivo con objeto de facilitar la vida al servidor. Una petición a la dirección servidor.com/algo es ambigua porque el servidor, a priori, no puede conocer si el recurso solicitado “algo” es un archivo o un directorio; si, en cambio, la petición se realiza hacia servidor.com/algo/ queda más claro que lo que se pretende es obtener el contenido de una carpeta, y en teoría podría agilizarse el proceso de búsqueda del recurso.

No he encontrado tampoco directrices que indiquen claramente en qué afecta la aparición de esa terminación en la respuesta que debe enviar el servidor. Podemos encontrar servidores que ante una petición como servidor.com/algo retornan el mismo recurso que si la URL incluyera la barra final; en otros, en cambio, se opta por retornar una redirección hacia servidor.com/algo/ (con la barra) con objeto de indicar al cliente que “esa dirección es la buena” y evitar contenidos duplicados (el mismo contenido accesible desde distintas URL). Esto último podéis comprobarlo creando una aplicación web cualquiera y accediendo a localhost:xxx/content mientras trazáis las peticiones con Fiddler o las developer tools.

En aplicaciones ASP.NET en las se usa el sistema de routing, donde no existe el concepto “directorio” como tal, el uso de estas barras no tienen demasiado sentido. Por ejemplo, en MVC las peticiones se mapean contra acciones en un controlador; en la práctica, da igual si una URL acaba o no con una barra, puesto que será procesada por la misma acción y retornará el mismo resultado.

Por tanto, con este tipo de sistemas probablemente la elección se trate más de una cuestión de gustos que otra cosa. Simplemente va de decidir un estilo y ceñirse a él en toda la aplicación; y si lo que elegimos es acabar las URL con barras, ya sabemos que el sistema de routing de ASP.NET lo soporta de serie 🙂

Por mi parte, hasta ahora nunca he usado las barritas en las URL y, salvo que encuentre algún buen motivo, creo que seguiré sin hacerlo.

Y vosotros, ¿qué opináis del tema? ¿Barra sí o barra no? (Y no me refiero a las de los bares ;-P)

Publicado en: Variable not found.