Contenido

Variables CSS, ¿como está el tema?

18 jun

+ 1

Hace ya 4 años que se vienen hablando de la inclusión de variables en nuestros CSS, pero el tema parece que está bastante parado. Al parecer la W3C en abril publicó un borrador en el que introducia una propuesta de como deberían funcionar las estas variables en nuestros CSS’s.


// Definición
:root {
  var-my-color: #fad;
}

// Uso
.thing {
  color: var(my-color);
}

Desde WebKit hace ya tiempo que podemos usarlas usando el prefijo (-webkit-).


// Definición
:root {
  -webkit-var-my-color: #fad;
}

// Uso
.thing {
  color: -webkit-var(my-color);
}

Este mes de Junio, la W3C se marca un nuevo borrador en el que prescinde de la función var() cambiándola por $ para llamar a nuestra variable.


// Definición
:root {
  var-my-color: #fad;
}

// Uso
.thing {
  color: $my-color;
}

Vamos, que la capacidad de que nuestros CSS’s dispongan de variables está más o menos igual que siempre y no parece que se vaya a solventar en un futuro cercano, por el momento deberemos seguir usando herramientas como LESS.js o SASS para disponer de esta capacidad y alguna más.

Via

Detecta si estás online con HTML5

26 may

+ 2

Una de las nueva capacidades de la programación web es la capacidad de hacer que nuestras aplicaciones web puedan trabajar en modo offline, pero esto, nos obliga a controlar en todo momento si disponemos de conexión para volcar los cambios producidos, actualizar ciertos datos,…

navigator.onLine

El objeto navigator se modifica y añade esta nueva variable con el estado en formato boolean para conocer el estado de la conexión del usuario.

if(navigator.onLine){
alert('Online');
} else {
alert('Offline')
}

Así, podemos condicionar ciertas tareas que tendrán que realizarse exclusivamente en el navegador del usuario y otras que se encargarán de trabajar directamente con el servidor de aplicaciones.

Compatibilidad

Actualmente está disponible en la mayoría de navegadores modernos, al parecer, incluso IE7 dispone de esta capacidad.

Protocolo relativo y olvídate de los problemas entre HTTP y HTTPS

24 may

+ 9

El señor Tim Berners-Lee, considerado el padre de la web, comentaba hace unos años que si se hubiera tenido que pensar en ese momento rehacer internet hubiera eliminado las (//) de las URL’s que ahora conocemos. Probablemente en algún universo paralelo haya civilizaciones más avanzadas debido al tiempo ahorrado en ponerla :D

Hemos de reconocer que están ahí y que aunque actualmente los navegadores actuales las incluyen automáticamente, las URL’s no serían lo mismo aunque probablemente nuestros trabajos como desarrolladores web serían más sencillos :D

Si has tenido que trabajar con URL’s seguras y no seguras en aplicaciones que las compartan sabrás, ahora mismo, de que problema te quiero hablar. Exacto, del problema de gestión del protocolo de las URL’s en nuestro código.

Protocolo HTTP y HTTPS

El protocolo HTTP, el que todos conocemos nos permite conectarnos a URL’s de internet desde un cliente remoto, y las peticiones HTTPS, funcionan exactamente igual pero usando un certificado SSL para validar que la conexión entre el cliente y el servidor está encriptada.

Para más info, Wikipedia :D

Los que hemos desarrollado aplicaciones en la que ha de haber partes seguras y parte que pueden no serlo, sabrán que cuando estás en HTTPS, todas las peticiones que lanza el cliente deben ser HTTPS. Sino lo son, el navegador nos suele avisar con un mensaje de que en un entorno seguro se está accediendo a contenido no seguro.

b_yui_https_warning
(Ver Imagen)

Esto ha provocado, durante mucho tiempo, tener que usar variables con el protocolo para detectarlo en todo momento y así adaptar el HTML resultante al protocolo seguro o no seguro de toda la página.

<?php
	$protocolo = strpos(strtolower($_SERVER['SERVER_PROTOCOL']),'https') === FALSE ? 'http' : 'https'
?>
<html>
	<head>
		<link rel="stylesheet" href="<?=$protocolo?>://midominio/micss.css" />
	</head>
	<body>
		<a href="<?=$protocolo?>://midominio/minuevoenlace">Me voy</a>
	</body>
</html>

Aunque hay técnicas más depuradas, para ilustrar el ejemplo nos vale, y ya podemos ver el trabajo que tenemos que hacer para controlar los protocolos de nuestras rutas. A simple vista ya podemos hacernos una idea de lo problemático que resulta atajar este problema en una aplicación medianamente compleja.

El protocolo relativo

Pues si ya has llegado por aquí, y no sabes que es el protocolo relativo, se te va a quedar una cara de tonto como la que se me quedó a mi hace unos días.

El protocolo relativo, es la capacidad que tienen los navegador web de definir automáticamente el protocolo de los elementos de una página en función del protocolo de entrada, osea que él navegador solo se encargaría automáticamente de gestionar esto por nosotros O.O!. Pero, ¿como!!?

Ya en 2010, Paul Irish publicaba ya alguna cosilla sobre el tema, aunque por aquel entonces, a mi por lo menos, se me pasó. Y el sistema es bastante lógico, ya que simplemente tendremos que usar una doble barra (//) y ya está  O.O!

Veamos un ejemplo:

<html>
	<head>
		<link rel="stylesheet" href="//midominio/micss.css" />
	</head>
	<body>
		<a href="//midominio/minuevoenlace">Me voy</a>
	</body>
</html>

Sencillo, límpio y lo más importante funciona!

¿Pero esto de donde viene?

Pues, aquí viene lo realmente sorprendente. Esto está definido el estándar RFC-1808 Sección 2.1, publicado en Junio del 1995 y en la RFC-3986 Sección 4.2 de Enero de ese mismo año. Osea, que hace casi 17 años que está definido! O.O!

¿Que navegadores lo interpretan?

Pues, teniendo en cuenta que hace 17 años que está vigente todos los navegadores actuales permiten usar esta nomenclatura, aunque aún debe de quedar algún IE4 o 5 que parecen no haber llegado a tiempo de implementarlo.

Actualización:Nacho Plaza me recuerda que esto mismo ya lo estuvimos hablando hace 2 años… me estoy haciendo mayor. Gracias Nacho!

wysihtml5, interesante editor HTML5 dependiente

23 may

+ 0

Ya conocemos perfectamente los editor WYSIWYG que nos permiten escribir código HTML más cómodamente y sobretodo podemos verlo en tiempo real, lo que produjo en su momento que tuvieran una gran acojida para diferentes aplicaciones.

En la era HTML5, WYSIHTML5 nos permite hacer exactamente lo mismo, pero en lenguaje HTML5, no es que nos devuelva HTML5 sinó que gracias a elementos HTML5 hacemos que este script permita ofrecer funcionalidades más fácilmente.

Veamos un ejemplo:

Cargamos el JS y las reglas de configuración:


<script src="/path-to-wysihtml5/parser_rules/advanced.js"></script>
<script src="/path-to-wysihtml5/dist/wysihtml5_0.3.0.min.js"></script>

Ver reglas disponibles por defecto o un ejemplo del advanced.js.

Creamos un contenedor

El contenedor deberá ser un textarea si queremos que el contenido sea usado para guardarlo, procesarlo o lo que se crea conveniente.


<form><textarea id="wysihtml5-textarea" placeholder="Enter your text ..." autofocus></textarea></form>

Creamos una toolbar con las opciones

Aquí es donde está lo interesante, ya que la toolbar no se autogenera gracias al Javascript sinó que es el javascript que en función de los elementos que se encuentra añade unas funcionalidades u otras.


<div id="wysihtml5-toolbar" style="display: none;">
  <a data-wysihtml5-command="bold">bold</a>
  <a data-wysihtml5-command="italic">italic</a>
  
  <!-- Some wysihtml5 commands require extra parameters -->
  <a data-wysihtml5-command="foreColor" data-wysihtml5-command-value="red">red</a>
  <a data-wysihtml5-command="foreColor" data-wysihtml5-command-value="green">green</a>
  <a data-wysihtml5-command="foreColor" data-wysihtml5-command-value="blue">blue</a>
  
  <!-- Some wysihtml5 commands like 'createLink' require extra paramaters specified by the user (eg. href) -->
  <a data-wysihtml5-command="createLink">insert link</a>
  <div data-wysihtml5-dialog="createLink" style="display: none;">
    <label>
      Link:
      <input data-wysihtml5-dialog-field="href" value="http://" class="text">
    </label>
    <a data-wysihtml5-dialog-action="save">OK</a> <a data-wysihtml5-dialog-action="cancel">Cancel</a>
  </div>
</div>

Indicamos que elemento será el contenedor, que elemento hará de toolbar y que reglas se han de usar para mapear funcionalides contra elementos.


<script>
var editor = new wysihtml5.Editor("wysihtml5-textarea", { // id of textarea element
  toolbar:      "wysihtml5-toolbar", // id of toolbar element
  parserRules:  wysihtml5ParserRules // defined in parser rules set 
});
</script>

Compatibilidad

Como era de esperar

  • Firefox 3.5+
  • Chrome
  • IE 8+
  • Safari 4+
  • Safari on iOS 5+
  • Opera 11+

Me gusta, sobretodo por la forma en la que está programado, haciendo que el Javascript sea HTML dependiente y no viceversa.

Google Chrome se convierte en el navegador más usado de Internet

21 may

+ 5

Sorprendente la evolución de Google Chrome, que en casi 4 años se ha convertir en el navegador más usado de Internet. Desbancando a Internet Explorer en una escalada épica.

Captura de pantalla 2012-05-21 a la(s) 22.35.05
(Ver Imagen)

Está claro que ponerle Google delante a cualquier producto ayuda, ya que esta versión de WebKit ha conseguido lo que Mozilla lleva soñando muchos años y nunca se ha acercado, ni por asomo, a Internet Explorer.

Lamentablemente creo que esto, hoy por hoy, no cambia nada, la mayoría de empresas tienen versiones de Internet Explorer que vieron extinguirse a los dinosaurios y hace que las aplicaciones actuales no evolucionen como nos gustaría que lo hicieran. En fin, estamos ante un hito importante, pero por el momento únicamente es solo eso, un hito.

Via

Actualización:

Hernan Roig me pasa un link, ya que al parecer hay problemas, los gerentes de Internet Explorer se niegan a aceptar estos datos y alegan el uso del sistema “prerendering” de Google Chrome que por detrás del usuario precarga ciertas rutas posibles para que el usuario no tenga que esperar tanto para su carga. En cierta medida, estos resultados estarían falseados si tenemos en cuenta esta capacidad del navegador, pero yo me pregunto… ¿el navegador no está pensado para mejorar la experiencia de usuario al navegar en la web? Creo que la gente de Microsoft debería empezar a hacer las cosas pensando así y menos en los números.

Gracias Hernan.

cssSandpaper, unifica transformaciones CSS3 en todos los navegadores

15 may

+ 0

cssSandpaper es otra librería javascript que pretende hacernos la vida más fácil haciendo que dispongamos de transformaciones CSS3 en nuestros navegadores de forma estandarizada, omitiendo las versiones personalizadas de cada navegador e incluso dotando a Internet Explorer de ellas.

-prefix-free, dí adios a los prefijos CSS

11 may

+ 5

Ayer vimos la cantidad de líneas de código que debemos incluir en nuestros CSS’s para disponer de ciertas funcionalidades en los diferentes navegadores, no es algo nuevo, hace ya tiempo nos quejábamos de ello. Y parece que a medida que van saliendo más y más propuestas por parte de los diferentes navegadores estos prefijos se están haciendo más y más populares.

El problema, radica en que dentro de X años esos prefijos dejarán de ser necesarios por que por lo general adoptan una nomenclatura estándar, lo que nos obligará a recorrer todos nuestros CSS’s para adaptarlos a los atributos del momento.

Para solventar prácticamente por completo ese problema aparece prefix-free, un librería Javascript que se encarga de gestionar estos prefijos por nosotros dejándonos a nosotros la nomenclatura estándar y él adaptándose al navegador que está visitando nuestra aplicación web.


// Nuestro CSS
border-radius: 1em; // Para cuando se cumplan los estandares.

// Resultado
-moz-border-radius: 1em; // Mozilla 
-ms-border-radius: 1em; // Internet Explorer 8 (No soportado) 
-webkit-border-radius: 1em; // WebKit y Safari 

Como podemos ver el cambio es significativo, y únicamente hemos de añadir un fichero JS a la carga de nuestra aplicación web.

<script src="js/prefixfree.min.js"></script>

Compatibilidad

Actualmente está disponible para los principales navegadores, IE9+ Opera 10+, Firefox 3.5+, Safari 4+ y Chrome para escritorio y Mobile Safari, Android browser, Chrome y Opera Mobile para móviles.

Problemas detectados.

En CristaLAB comentaban que nos funcionan en:

  • CSS’s cargados mediante @include.
  • ficheros CSS’s locales en Chrome y Opera.
  • Estilos inline
  • y CSS’s de diferentes dominios

Aún así, el trabajo que nos ahorramos a largo plazo es realmente interesante para tenerlo en cuenta.

Diagnosticando errores javascript más fácilmente con Error.stack

11 may

+ 2

Hoy, IEBlog publica un artículo muy interesante sobre el tratamiento de errores en IE10 sobre Windows 8. Al parecer, este último incluye soporte para un nuevo atributo al objeto Error(), el Error.stack, que activado desde las Web Developer Toolbars de IE10 nos ayudará a detectar los errores de forma más rápida.

Error.stack en IE10
(Ver Imagen)

Como podemos ver, nos ofrece una información detallada del error, al puro estilo Java mostrando toda la traza del error producido. Por lo tanto, nuestros try/catch vendrán cargados con todo lo necesario para conocer la causa de nuestros problemas, además podremos limitar el nivel de profundidad de dicha traza mediante el atributo stackTraceLimit disponible de igual modo en el objeto Error(). Una funcionalidad muy interesante que seguro nos ayudará a solventar los problemas que nos encontremos en IE10 … que seguro que los encontramos :D

Usando la Javascript Fullscreen API

9 may

+ 11

Si conoces Facebook, conocerás el nuevo sistema de visualizado de imágenes que permite, entre otras opciones, ver la imagen a pantalla completa, pero cuando decimos pantalla completa, es a pantalla completa, usando toda la pantalla, no usando el tamaño del elemento Window como lo usábamos antes.

¿Como es posible?

Pues debido a la implementación de la Javascript Fullscreen API :D.
Una implementación, introducida por Apple en el Safari 5.0 para los tags <video /> y que fue bien acogida en la comunidad de desarrolladores, lo que hizo que Mozilla se añadiera con una propuesta más firme en la que se extendía su uso a cualquier elemento del DOM. Y para consolidar esta buena idea, la W3C metió mano y definió la primera propuesta para estandarizar esta funcionalidad.

¿Como lo usamos?

Después de comprobar que el navegador del usuario dispone de dicha funcionalidad (que por ahora son Google Chrome 15+, Safari 5.1+ y Firefox 10+) ejecutamos la llamada RequestFullScreen() que nos cambiará a modo pantalla completa.

var docElm = document.documentElement;
if (docElm.requestFullscreen) {
    docElm.requestFullscreen();
}
else if (docElm.mozRequestFullScreen) {
    docElm.mozRequestFullScreen();
}
else if (docElm.webkitRequestFullScreen) {
    docElm.webkitRequestFullScreen();
}

Una vez ya en pantalla completa, el navegador no solicitará si deseamos permitir que el dominio sobre el que usamos dicha funcionalidad debe tener permitido el uso de la Fullscreen API.

Para detectar el estado de nuestra pantalla completa disponemos del evento fullscreenchange que nos permitirá detectar un cambio sobre esta funcionalidad. Pudiendo conocer en todo momento si estamos en modo normal o modo pantalla completa.


document.addEventListener("fullscreenchange", function () {
    fullscreenState.innerHTML = (document.fullscreen)? "" : "not ";
}, false);

document.addEventListener("mozfullscreenchange", function () {
    fullscreenState.innerHTML = (document.mozFullScreen)? "" : "not ";
}, false);

document.addEventListener("webkitfullscreenchange", function () {
    fullscreenState.innerHTML = (document.webkitIsFullScreen)? "" : "not ";
}, false);

Y además, disponemos de una pseudo-clase CSS que nos permite condicionar ciertos aspectos de nuestra pantalla completa.


html:-moz-full-screen {
    background: red;
}

html:-webkit-full-screen {
    background: red;
}

html:fullscreen {
    background: red;
}

Personalmente, creo que es una funcionalidad muy interesante y me ha llamado mucho la atención que se haya movido tan rápido y que podamos usarla con tantos navegadores en tan poco tiempo. Aunque al parecer, Microsoft aún no tiene claro si lo va a implementar debido a que Windows 8 ya está pensado para trabajar con Internet Explorer 10 en modo pantalla completa siempre… otra vez :(

Más Info

Detectando inserciones DOM con Javascript y animaciones CSS

8 may

+ 3

Ayer, David Walsh nos mostraba una técnica para detectar elementos insertados en nuestro DOM mediante animaciones CSS. Para ello usaremos javascript, pero no el elemento “deprecated” DOMNodeInserted de la DOM Event Reference.

Veamos el código

<ul id="parentElement"></ul>
<style type="text/css">
/* Definimos las animaciones */

/* La estándar */
@keyframes nodeInserted {
from { clip: rect(1px, auto, auto, auto); }
to { clip: rect(0px, auto, auto, auto); }
}

/* La de Firefox ¬¬ */
@-moz-keyframes nodeInserted {
from { clip: rect(1px, auto, auto, auto); }
to { clip: rect(0px, auto, auto, auto); }
}

/* La de WebKit ¬¬! */
@-webkit-keyframes nodeInserted {
from { clip: rect(1px, auto, auto, auto); }
to { clip: rect(0px, auto, auto, auto); }
}

/* La de IE ¬¬!! */
@-ms-keyframes nodeInserted {
from { clip: rect(1px, auto, auto, auto); }
to { clip: rect(0px, auto, auto, auto); }
}

/* La de Opera ¬¬!!!*/
@-o-keyframes nodeInserted {
from { clip: rect(1px, auto, auto, auto); }
to { clip: rect(0px, auto, auto, auto); }
}

/*
Definimos las duraciones
para toooodos los navegadores
*/
#parentElement > li {
	animation-duration: 0.001s;
	-o-animation-duration: 0.001s;
	-ms-animation-duration: 0.001s;
	-moz-animation-duration: 0.001s;
	-webkit-animation-duration: 0.001s;

	animation-name: nodeInserted;
	-o-animation-name: nodeInserted;
	-ms-animation-name: nodeInserted;
	-moz-animation-name: nodeInserted;
	-webkit-animation-name: nodeInserted;
}

</style>
<script type="text/javascript">
	var insertListener = function(event){	
		// Detectamos el nombre de la animación lanzada
		if (event.animationName == "nodeInserted") {
			console.warn("Another node has been inserted! ", event, event.target);
			}
		}

// Asociamos los la anterior funcionalidad al evento "animationstart"
document.addEventListener("animationstart", insertListener, false); // standard + firefox
document.addEventListener("MSAnimationStart", insertListener, false); // IE
document.addEventListener("webkitAnimationStart", insertListener, false); // Chrome + Safari
</script>

Como podemos ver en el código, la técnica usada pasa por definir las animaciones CSS (en todos y cada uno de los navegadores, bufff! ) a las que se les asigna un nombre, después, usando la gestión de eventos asociamos (otra vez para los diferentes navegadores ¬¬) la función insetListener() que se encargará de comprobar que al accionar el evento animationstart se esté accionando la animación previamente definida. A nivel académico, me parece realmente interesante, aunque quizás un poco laborioso para implementar en el día a día.