Añadir atribulo REL para FancyBox en WordPress


Galeria - Casa Rural Puerta de la Vera

Recientemente he tenido que adaptar une web estática realizada mediante HTML5, CSS3, JS y Jquery (aunque con cierto dinamismo en PHP) para montar una sección dedicada al Blog de la empresa en cuestión (cosas de la indecisión inicial del propietario, que no sabia si lo quería o no a la hora de realizar el estudio previo), es entonces cuando después de adaptar todo el diseño inicial de la web corporativa al blog (no sin ciertos problemillas) me vi en la tesitura de si mantener los códigos Javascripts que ya funcionaban en la web o si usar plugins de WordPress para hacer las mismas funciones. Después de pensarlo me dedique a intentar implementar el código actual a la estructura de WP y sin utilizar plugins ni estilos adicionales e innecesarios.

Una de las funciones a mantener era la de la galería visual Fancybox, la cual utilizo en la mayoria de mis proyectos y que me ha dado tan buen resultado. En wordpress por tanto hay que fijarse como funcionan las galerías fotográficas propias para saber la clase a utilizar para activar Fancybox que en este caso es “.gallery a”:

<div id=”gallery-1″ class=”gallery galleryid-82 gallery-columns-4 gallery-size-thumbnail”>
 <dl class=”gallery-item”>
   <dt class=”gallery-icon”>
    <a title=”Logotipo” href=”../inicio.jpg” rel=”galeria82″>
     <img class=”attachment-thumbnail” width=”190″ height=”97″ title=”Logotipo” alt=”Logotipo” src=”../inicio-190×97.jpg”>
    </a>
   </dt>
 </dl>
 <dl class=”gallery-item”>
 …
 </dl>
</div>

En el extracto vemos que los enlaces “a” no tienen clases definidas asi que usaremos la clase “gallery” del “DIV” padre asi podremos activar Fancybox para este tipo de galerías en el código Javascript encargado de ello:

$(“.gallery a”).fancybox({
 ‘transitionIn’: ‘elastic’,  
 ‘transitionOut’: ‘elastic’,  
 ‘titlePosition’: ‘over’,  
 ‘cyclic’: true,  
 ‘titleFormat’: function(title, currentArray, currentIndex, currentOpts) {  
  return ‘<span id=”fancybox-title-over”>Imagen ‘ + (currentIndex + 1) + ‘ / ‘ + currentArray.length + (title.length ? ‘ &nbsp; ‘ + title : ”) + ‘</span>’;  
 }
});

Con esto ultimo conseguimos que las imágenes se desplieguen con el visor de imágenes de Fancybox, ahora nos queda poder recorrer mediante las flechas o cursores izquierda o derecha las imágenes de dicha galería, para ello Fancybox utiliza el atributo REL de los enlaces para conocer de antemano por que imágenes puede navegar; como esto no nos lo provee Wordpres de forma nativa hay que agregarlo manualmente en el archivo functions.php del tema WP que estemos usando (en este caso mi propio tema), así pues, hay que añadir el siguiente código al final de este archivo:

add_filter(‘wp_get_attachment_link’,’add_gallery_id_rel’);
function add_gallery_id_rel($link){
global $post;
return str_replace(‘<a href’, ‘<a rel=”galeria’. $post->ID .'” href’, $link);
}

Como podemos observar hemos remplazado la cadena original <a href con <a rel=”galeria’. $post->ID.'” href’ con lo que añadimos el atributo rel que contiene “galeria” y a este concatenamos el ID de la entrada que la contiene, con lo que así evitamos que naveguemos por todas las galerías, si es que se muestran varias en la misma pagina.

Fuentes de interés: wiki.jnestudi.com

Anuncios

Recursos gráficos para Webmasters


Recursos Graficos

 

Uno de mis dilemas a la hora de diseñar y crear una web es el de conseguir recursos graficos, tipografias, etc. Es por eso que continuamente estoy buscando dichos recursos (intentando siempre encontrar elementos de libre uso) mediante Google y demas; en una de esas busquedas me encontre con esta fantastica entrada de Bitelia donde se resume y se exponen las web de recursos mas frecuentadas para este fin.

Yo simplemente facilito el enlace, pero a modo de resumen os muestro los servicios mas destacados:

Tipografías

Imágenes

Vectores

Templates

 

Fuente: Bitelia

Imagen: Geniocreativo

Accesibilidad web, ese gran olvidado…


W3C-Accessibility-Standards

De un tiempo a esta parte, he venido concienciandome sobre el enorme problema de accesibilidad web que se viene arrastrando desde los inicios del HTML, y ya sea porque yo ahora estoy en el lado de la minusvalía visual o porque gracias a eso estoy recibiendo información relacionada me parece que es un problema que toda empresa debería tener en cuenta en sus proyectos web a la mas mínima posibilidad de que sean leídos por un colectivo que necesita de adaptaciones para poder navegar con normalidad por Internet.

Después de una presentación de la O.N.C.E. en Madrid sobre redes sociales y accesibilidad web me di cuenta que empresas tan grandes y tan “cool” como puede ser Facebook u otras de la misma índole, no tienen programada sus aplicaciones web teniendo en cuenta los estándares de cumplimiento y accesibilidad que deberían ser norma sobre todo en una web donde millones de personas con algún tipo de discapacidad visual pueden acceder e intentar sentirse al mismo nivel que todas las demás personas…

Pero claro, es de entender que no lo hagan porque les costaría lo suyo tener que adaptar algo que se desarrollo desde un principio sin pensar en la accesibilidad. En cambio si se hubiera tenido en cuenta desde un comienzo no creo que fuera muy complejo ni caro pues es simplemente seguir unas normas a la hora de generar el código HTML o XHTML.

 

En relación a todo esto, me encontré un articulo de la gente de genbetadev.com que me ha parecido muy instructivo y que debería ser tenido en cuenta por muchas empresas, si es que estas valoran que ese esfuerzo de escribir bien no tiene porque tener un sobre coste al finalizar el proyecto, aquí les dejo un extracto que define bien esta problemática:

Hasta ahora nos hemos centrado únicamente en hacer un documento que todos los navegadores entiendan igual de bien, pero desde un punto de vista humano es más importante conseguir que sean las personas las que puedan acceder de una misma manera al contenido, independientemente de cualquier tipo de incapacidad que puedan tener. Por eso, al hacer una página válida habremos dado el primer paso para llegar a la accesibilidad, pero aún faltarán otros tantos.

Dado que la inaccesibilidad de una página sólo puede medirse por las dificultades que una persona tenga para navegar por ella, no existe un método automático de medirla, sino unas directivas a seguir para al menos intentar conseguirla. Del mismo modo, no hay una verificación de que una página es accesible, pero sí un compromiso por parte del creador de que la página intenta ser accesible en uno de estos tres niveles:

  • Nivel A: Un desarrollador web debe satisfacer estos requisitos. De modo contrario, para uno o más grupos de usuarios sería imposible acceder a la información del documento.
  • Nivel AA: Un desarrollador web debería satisfacer estos requisitos. De modo contrario, para uno o más grupos de usuarios sería difícil acceder a la información del documento.
  • Nivel AAA: Un desarrollador web podría satisfacer estos requisitos. De modo contrario, uno o más grupos de usuarios encontraría algunas dificultades a la hora de acceder a la información del documento.

Dentro del articulo de Genbeta Dev (ver enlace mas abajo) podrás obtener mucha mas información para llevar a cabo la adaptación de tu web a los estándares de accesibilidad que creas convenientes, yo estoy seguro que si es una web que interese a nuestro colectivo, esta sera un éxito y se te agradecerá tenernos en cuenta. Aunque no solo a nosotros nos atañe.

 

Fuente: Genbeta Dev

Validación del W3C: validator.w3.org

Más información: Guía de accesibilidad web

Humanos al poder


Humans TXT

Recientemente me encontrado con la necesidad de tener que preguntar al propietario (que no autor) de alguna web si insertabamos un enlace al pie la URL de mi web o correo electronico para certificar la autoria de la web en cuestión. Si seguimos la lógica, no debería tomar ningún problema por parte del cliente así que editamos el código y lo agregamos como una imagen de tu logo o con un simple enlace… pero no, hay empresas o clientes que deciden que “ahí abajo” no quieren que se vea ningún enlace externo al contenido de su site, y esto, por unas razones u otras es así en muchas ocasiones.

Hoy me encontré con esta estupenda iniciativa de humanstxt.org que pretende que de una manera no intrusiva (poner enlaces o logos externos en la web) podamos certificar la autoría de la web, a parte de otros datos interesantes como el equipo de trabajo que ha participado en la construcción de la web y que tecnologías asociadas se mueven entorno a esta. Por tanto se pretende que sigan un estándar para que se extiendan globalmente y de este modo los “grandes” (google, bing, yahoo y demas) empiecen a tenerlo en cuenta en sus indexaciones.

La forma de llevarlo a cabo es mediante un archivo de texto plano llamado humans.txt (recordando de esta manera a robots.txt que la web tiene su lado humano), este archivo se aloja en la raíz de la web y dentro del código y en la sección HEAD se añade al META AUTHOR una referencia al archivo. Así de simple.

Si quieres conocer el estándar que se propone visita este enlace.

Fuente: Humanstxt.org

El cambio a HTML5 y otros menesteres


Hay veces que con la carga de trabajo no da ni tiempo a intentar innovar, o al menos intentar probar nuevas tecnologías… me pasaba a mi en mi antiguo empleo, una empresa pequeña a la que eso del I+D+i no llegaba ni por asomo y que siempre debíamos innovar a la fuerza, es decir, si un cliente nos pedía hacer algún proyecto en concreto en ocasiones nos ponía sobre la mesa que tecnologías debíamos utilizar para sacar adelante el proyecto, por lo tanto la pregunta normalmente era: ¿esta tecnología la sabéis implementar y desarrollar, no? a lo cual nosotros respondíamos: si, no hay problema (cuando a lo mejor ni nos suena lo nos esta diciendo)… Pero bueno, normalmente es ponerse una semanita al tajo e intentar dominar al menos la base de dichas “nuevas tecnologías” y después aplicarlas al proyecto en cuestión.

A lo mejor os preguntáis porque os cuento esto, pues porque ahora dispongo de “mucho tiempo libre” (lease: paro) y como en este mundo estar parado significa anticuarse, estoy haciendo cábalas y buscando que es lo próximo, el estándar a seguir en cuanto a la web en este caso. Pues nada, si eres un poquito informático o aficionado al tema sabrás que el lenguaje estándar HTML5 ya esta en la calle y muy probablemente para desbancar a Flash y a otros (librerías JavaScript y herramientas de estilo no creo que desaparezcan puesto que siempre añaden funcionalidad aunque HTML5 nos provee de buenos recursos propios junto a CSS3), como sabemos, y si no lo sabes te lo cuento, HTML siempre ha pecado de ser muy simple y ser muy simple a veces viene bien pero la mayoría de las veces y mas ahora en este tiempo de Web 2.0, interacción, multimedia, aplicaciones web y todo un enjambre de nuevos usos en la web hacia que hubiese que añadir librerías o módulos adicionales a nuestras paginas bien para mejorarlas visualmente, hacerlas mas funcionales de cara al usuario final o lo no menos importante: adaptarlas a cada tipo de navegador puesto que cada marca contiene interpretes de su padre y su madre por lo que muchas veces había que estar probando en todos los navegadores si la pagina se veía bien o no y en caso negativo adaptarla a ellos (cosa que me ha llevado horas y horas). Pues bien el W3C ha tomado cartas en el asunto porque esto se estaba desmadrando demasiado pienso yo, y se quiere que todos los navegadores sean compatibles e interpreten del mismo modo HTML5 y CSS3 en el caso de los estilos, y ya que estaban se ha mejorado añadiendo mas funcionalidades al codigo HTML5 respecto al anticuado HTML.

En el siguiente listado os muestro las nuevas funcionalidades:

  • Incorpora etiquetas (canvas 2D y 3D, audio, video) con codecs para mostrar los contenidos multimedia. Actualmente hay una lucha entre imponer codecs libres (WebM + VP8) o privativos (H.264/MPEG-4 AVC).
  • Etiquetas para manejar grandes conjuntos de datos: Datagrid, Details, Menu y Command. Permiten generar tablas dinámicas que pueden filtrar, ordenar y ocultar contenido en cliente.
  • Mejoras en los formularios. Nuevos tipos de datos (eMail, number, url, datetime …) y facilidades para validar el contenido sin Javascript.
  • Visores: MathML (fórmulas matemáticas) y SVG (gráficos vectoriales). En general se deja abierto a poder interpretar otros lenguajes XML.
  • Drag & Drop. Nueva funcionalidad para arrastrar objetos como imágenes.

Como se puede observar estas funcionalidades se podian aplicar con ayuda de terceros, ahora es el propio HTML5 quien nos las provee. También se han eliminado antiguos TAGs obsoletos y se han añadido otros mas orientados a la Web 3.0.

Una de las mejoras que mas me llama la atención es el almacenamiento persistente en local en el cual se almacena una pequeña base de datos en el equipo cliente, algo similar a las cookies pero a lo bestia, esta API se basa en SQLite por lo que se maneja con lenguaje SQL.

Estaremos atentos al avance de todo esto… y si es posible haremos algún curso para ponernos al día.

Fuente: Wikipedia, HTML5Rocks