Desde la salida del Retina Display, se duplicó la densidad de pixeles que utilizábamos para diseñar y construir sitios webs para iPhone. Aunque si seguías utilizando los acostumbrados 480x320px de las pantallas anteriores, se nota bastante el pixel en estos nuevos teléfonos. Pero si trabajas para la nueva resolución de 960x640px, ¿qué haces con los modelos anteriores?
Suele ser común el pensamiento que 1 pixel en CSS es 1 pixel en la pantalla del dispositivo. Cuando entramos al nuevo mundo de la alta definición un pixel en CSS termina siendo múltiples en la pantalla. Un ejemplo es si defino un zoom de 2x, entonces 1 pixel de CSS termina siendo 2×2 cuadrados de pixel en el dispositivo. Y eso es lo que está sucediendo desde el iPhone 4.
Entonces, la pregunta es sencilla: ¿Cómo trabajamos con Retina sin dejar de lado las resoluciones anteriores?
La respuesta viene de la mano del potente Mobile Safari y su capacidad de responder mediante CSS3 media queries. Podemos detectar si el dispositivo duplica la densidad del pixel, y si es así modificar el estilo reemplazando las imágenes por una de doble resolución:
<link rel="stylesheet" type="text/css" href="css/normal.css"> <link rel="stylesheet" type="text/css" href="css/retina.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)" >
El secreto está en que definas las imágenes que querrás se vean de mejor calidad en un iPhone 4+ mediante background-image de CSS, por ejemplo:
normal.css
#logo {
background-image: url('images/logo.png');
background-size: 100px 100px;
background-repeat: no-repeat;
}
retina.css
#logo {
background-image: url('images/logo_hi.png');
}
Te recomiendo apreciar el ejemplo desde tu teléfono móvil, para que realmente veas los resultados:
Como el navegador va a leer sí o sí normal.css, y por gracia del media="only screen and (-webkit-min-device-pixel-ratio: 2) sólo los dispositivos que tengan duplicados su resolución leerán retina.css y sobreescribirán los estilos definidos en esta hoja de estilos por sobre la anterior. La idea es que sólo definas las propiedades que cambien, no es necesario que reescribas todo el código.
Mediante JS
Otra manera es hacerlo mediante JavaScript, la cual encuentro innecesaria pero de todas maneras dejo la opción:
<script type="text/javascript">
if (window.devicePixelRatio >= 2) {
document.write("<link href='css/retina.css' rel='stylesheet' type='text/css' media='screen' />");
} else {
document.write("<link href='normal.css' rel='stylesheet' type='text/css' media='screen' />");
</script>
Links:
]]>
Cuando un navegador comienza a parsear una página, comienza a leer desde el encabezado, claro. Si la respuesta del encabezado del content-type especifica un atributo charset, esos bytes pueden ser interpretados inmediatamente como texto utilizando el encoding determinado. Sin embargo, si una declaración charset no está presente, el browser comienza a escanear los bytes de de respuesta del cuerpo, buscando por algún marcador unicode ó algún elemento dentro del meta http-equiv que especifique el charset. Cuando lo encuentra el parser vuelve a leer el documento para asegurarse que lo anterior sea leído correctamente. Ahora, si una declaración de charset no está definido, el browser está obligado a autodetectar el encoding dependiendo del contenido, lo que puede provocar errores de caracteres o en la página misma.
Luego, son leídos el título, favicon y los estilos (<link>) los que deben estar en concordancia con el charset definido anteriormente.
Finalmente, el orden ideal propuesto por la mayoría de los navegadores modernos es el siguiente:
<doctype>
<html>
<head>
<meta http-equiv content-type charset>
<title>
<link rel="alternate" />
<link rel="shortcut icon" />
<link rel="stylesheet" type="text/css" />
Parece obvio, pero no muchas veces se cumple.
No incluí <script></script> intencionalmente ya que existen escuelas que dicen que es mejor incluirlos abajo del código de tu página, antes del </body>, lo que no valida en el código HTML pero acelera la carga de los elementos del DOM y deja para el final la carga de los scripts. Mejor lo dejo a criterio de cada desarrollador.
Links:
]]>Dado un contenedor que contiene uno o más elementos flotando en su interior, siempre y cuando puedas definir un ancho fijo:
#container {
width: 600px;
display: inline-block;
}
.floto {
float: left;
}
Este método se comporta bien cuando el ancho de los elementos interiores que están flotando es menor que el del padre; las cosas comienzan a complicarse cuando aumentan:
Para contrarrestarlo, define también ancho fijo en los elementos flotantes:
#container {
width: 600px;
display: inline-block;
}
.floto {
width: 280px;
float: left;
}
Nada es perfecto… es un método más.
]]>Para deshabilitar el click derecho del mouse del usuario basta la siguiente simple instrucción jQuery:
$(function(){
$(document).bind("contextmenu",function(e){
return false;
});
});
]]>Para quitarlo, basta declarar en CSS:
textarea {
resize: none;
}
Ver ejemplo
(En Safari-Chrome)
Al declarar algunos valores en propiedades CSS como background-image, usualmente se permite poner o no el valor entre comillas dobles "" ó simples ”. Si escribes el código a mano, no las utilizas. Si usas algún editor, quizas las agrega. Pero ¿se debe o no poner comillas?
Esta pregunta que ha intrigado al hombre por años no tiene una respuesta definitiva. Por lo menos no la he encontrado de manos de la W3C, pero sí el uso de comillas en ciertas declaraciones tiene sentido:
… single quotes (‘), and double quotes (") must come in matching pairs …
Primero, no dice que deben ser utilizadas. Segundo, dice que si las utilizas, deben estar en par (si abres con comilla simple cierra con simple, etc.). Pero:
Inside the quotes, characters are parsed as a string.
Esto es lo importante. Si utilizas las comillas simples o dobles, el valor se pasa como string. Un ejemplo práctico y descuidado: si tienes una imagen con espacios en su nombre:
background: url('back ground.png')
Si utilizas comillas en su declaración la imagen se mostrará:
Si no la utilizas, el browser no encontrará la imagen:
Este comportamiento es independiente del doctype que estés utilizando. Yo las uso.
Link:
]]>$('input').each(function(){
// tomamos el valor actual del input
var currentValue = $(this).val();
// en el focus() comparamos si es el mismo por defecto, y si es asi lo vaciamos
$(this).focus(function(){
if( $(this).val() == currentValue ) {
$(this).val('');
};
});
// en el blur, si el usuario dejo el value vacio, lo volvemos a restablecer
$(this).blur(function(){
if( $(this).val() == '' ) {
$(this).val(currentValue);
};
});
});
]]>En un campo de formulario, cuando lo seleccionas en iPhone/iPad para completarlo, automáticamente te muestra el teclado touch del aparato. Aparte del teclado QUERTY por defecto, existen 3 valores para type="" de <input /> que muestran diferentes tipos de teclados: numéricos, url y de e-mail:
<input type="text" /> (por defecto)
<input type="url" />
<input type="number" />
<input type="email" />
Los browsers que no soporten HTML5 lo obviarán y degradarán como si fuera un campo de tipo texto (type="text").
Se nota como un detalle menor pero seguro tus usuarios lo notarán y te diferenciarás con este tipo de detalles.
]]>Poner en práctica este tema me ha costado mucho tiempo de documentarme, de pruebas y errores. Si te vas a aventurar en este medio, creo importante que tengas claro algunos puntos y otros que se los transparentes al cliente, todo para evitar posteriores decepciones:
Estudia cada dispositivo, sus fortalezas y limitaciones
Desde que salió el iPhone, se abrió una nueva manera de tratar sitios web para móviles. Se pensaba que con el marcado WML y estilos básicos bastaban, pero Apple demostró que se puede hacer mucho más y mejor en tan poco espacio. Google ofrece mucho con su navegador basado en Webkit, Opera soporta XHTML en su Opera Mini. Es importante que sepas cómo y qué te ofrece cada dispositivo, y eso se lo traspasas a tu cliente.
Trata de hacer versiones para iPhone, smartphones y los que sobran
Básicamente iPhone es el que tiene mayores diferencias en la manera de tratar el código fuente, así que es mejor hacer una versión del sitio sólo para este dispositivo. Agrupa los smartphones (Blackberry, Nokia) y crea una versión con buen HTML y estilos sobrios; cuida que el HTML sea sencillo para el resto de los browsers más limitados (Palm, Windows Mobile). Para detectarlos, te recomiendo un sencillo pero útil script en PHP que hace el trabajo por tí.
Ten cuidado con Blackberry (y Nokia)
He tenido grandes decepciones con las versiones del browser de Blackberry y Nokia: suelen comportarse diferente entre modelos inmediatos, y esas diferencias son sustanciales. Lamentablemente, te recomiendo que uses HTML 4 y CSS1 para asegurarte con todos los modelos de estas marcas.
Deja el comportamiento para el servidor
Si debes validar campos de formularios, déjaselo al servidor y no al browser. Al contrario de iPhone, muchos teléfonos traen Javascript deshabilitados por defecto. No esperes que el usuario los haya habilitado manualmente; si puedes, evítalo.
No confies en los simuladores
Una lástima, pero te recomiendo que le agregues a tu lista de amigos, el modelo y versión de teléfono celular que tiene cada uno para que te ayuden a probar tus desarrollos. Sólo así tendrás certeza del correcto funcionamiento que esperan tú y tu cliente.
Ten mucha, pero mucha paciencia
Si crees que por ser sitios menores te será fácil, te decepcionarás: son muchas más las variables que debes tener presente, y probablemente el esfuerzo será mayor. Planifica muy bien con tu cliente lo que él espera ver e interactuar mediante un móvil, aterrízalo con las limitaciones que encuentres y lleguen a un acuerdo razonable para ambos.
Links:
]]>- Nombres (websafe): por 17 colores en inglés : aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, orange, purple, red, silver, teal, white y yellow (actualmente los browsers modernos soportan muchos más).
- Sistema (no lo recomiendo): por colores del sistema operativo que esté utilizando el usuario del sitio: ActiveBorder, AppWorkspace, Background, ButtonFace, ButtonHighlight, ButtonShadow, ButtonText, HighlightText, InactiveBorder, InfoBackground, InfoText, Menu, MenuText, Scrollbar, Window, WindowFrame y WindowText.
- RGB Hexadecimal: quizás el más utilizado, en el cual cada color se mezcla según 16 símbolos (de 0 a 9 y de la A a la F); por ejemplo el rojo es: #FF0000.
- RGB Decimal: se indica qué cantidad de Rojo, Verde y Azul se debe mezclar en una escala de 0 a 256 tonos cada uno; en este caso el rojo seria rgb(255,0,0).
- RGB Porcentual (poco preciso): otra forma de expresar colores en RGB pero en forma porcentual; rojo es rgb(100%,0%,0%).
Pero con CSS3 existe una nueva e interesante manera:
- RGBa: al igual que en la forma RGB Decimal anterior, se agrega un valor al final: el canal alpha de opacidad, en escala de 0 a 1. Lo interesante de este método es que al contrario de opacity{}, la transparencia la verás sólo al color y no a todo el elemento, por lo tanto esta propiedad no se hereda. Su modo de uso es de la siguiente manera:
selector {
background: rgba(255,0,0,0.3);
color: rgba(200,120,60,0.6);
border: 3px solid rgba(10,250,70,0.5);
}
En el siguiente ejemplo verás la diferencia con una opacidad aplicada mediante RGBa y mediante opacity{}.
Por supuesto al ser una propiedad CSS3, en estos momentos sólo es soportada por Safari 3+ y Firefox 3, pero ya comencé a agregar funcionalidades a los sitios en que sólo son vistos si navegas con estos browsers; si usas IE no tienes tan buena experiencia visitándolos y es mi manera de convencer al usuario de que se actualice.
]]>