Acordaremos todos, que los carteles o avisos de "Optimizado para..." (que normalmente estaban seguidos de "Internet Explorer" o una resolución como "1024x768, o ambos) no tienen sentido al montar la web mediante estándares. Su razón de ser es mantener la línea y se vea todo igual (o similar y requiera ciertos ajustes) en todos (o la mayoría de navegadores). 
Este cartel se viene arrastrando desde los tiempos de la primera guerra de navegadores (esa de Internet Explorer vs Netscape) donde cada navegador creaba las etiquetas que le parecía, ensuciando el estándar, y haciendo que las páginas optimizadas (aquí sí) para uno no se vieran en el otro.

Dicho esto, está claro que el "Optimizado para..." hay que desterrarlo para la Historia. No tiene sentido su uso y hay que trabajar los estilos para que un website se vea bien en la  mayoría de navegadores.

Todo esto viene porque en cierto lugar con un cartelito de éstos, que rezaba: Optimizado para Safari. Se modernizan los enemigos del crossbrowsing. (Y no lo digo por Safari, que respeta mucho el estándar) sino por el que cuelga estos carteles obsoletos en sus páginas.

Lo cierto es que, a día de hoy, ni el uno (HTML5) ni el otro (CSS3) son estándares de facto. Para que cualquiera de estas tecnologías o ambas se conviertan en estándares de facto es necesario que todos los elementos que las componen sean recomendaciones y no borradores de trabajo. Las recomendaciones están plenamente desarrolladas, y no se estiman ya cambios en ellas; mientras que, en los borradores de trabajo, se pueden añadir y eliminar funcionalidades por parte del w3c que los está desarrollando.

A fecha de hoy 25 de Febrero de 2013, tenemos como borradores y recomendaciones, de ambas tecnologías, las siguientes:

HTML5

En este caso nos encontramos con que el html5 es, en sí mismo, un borrador. Os dejo la especificación actual; pero tened en cuenta que pueden haber cambios:
http://www.w3.org/html/wg/drafts/html/master/

CSS3

La página siguiente contiene todos los módulos CSS recomendados, candidatos y en borrador de trabajo. Así como los obsoletos y descontinuados:
http://www.w3.org/Style/CSS/current-work

Recomendaciones (estándar)
Color level 3: http://www.w3.org/TR/css3-color/
Selectors level 3: http://www.w3.org/TR/selectors/

Candidatos y borradores (aún no son estándar)
En cualquier otro caso, hay que tener en cuenta  las propiedades CSS3 que queramos utilizar y comprobar en qué estado se encuentran.
Si se encuentran en estado candidate, seguramente se conviertan pronto en recomendación; pero si son borradores habrá que seguir su avance pues éste puede ser descontinuado en un momento dado o tardar aún en convertirse en recomendación.

Navegadores

Para añadir más complejidad al asunto, los distintos navegadores ofrecen distinto grado de compatibilidad con etiquetas y propiedades HTML5 y CSS3: unas son compatibles en unas, otras no... Hay que tener esto en cuenta a la hora de desarrollar nuestras aplicaciones y según los requisitos de las mismas.

En el caso extremo, están los navegadores obsoletos que no son compatibles con HTML5 y CSS3. Como recomendación: hay que procurar utilizar un navegador actualizado; puesto que existen mejoras tanto de seguridad,  como de usabilidad, compatibilidad con nuevas tecnologías, etc... Con lo cual no es nunca mala idea mantener el navegador actualizado.  Si bien es cierto que, en diversos entornos con aplicaciones desarrolladas a medida, este escenario se complica; mi recomendación es ir pensando en la actualización de los sistemas y aplicaciones que hayan sido desarrolladas, teniendo siempre en mente utilizar los estándares del w3c y no desarrollar nuncar para un sólo navegador en concreto.

Existen librerías JS que crean un artificio de compatibilidad en los navegadores (vamos a decir "viejos" o no compatibles) con las etiquetas y propiedades más usadas de HTML5 y CSS3, creando una especie de retrocompatibilidad de HTML5 y CSS3. Siempre será mejor esta opción que dejar sin acceso a nuestros sitios creados con la última tecnología a aquellos navegadores que no la soporten o lo hagan muy parcialmente.

Al crear hojas de estilo mediante SASS, necesitamos añadir nuestros estilos y código SASS en archivos de extensión SCSS. Ocurre que, por defecto, el editor Dreamweaver de Adobe abra los ficheros SCSS como texto plano; perdiendo el coloreado típico de CSS en Dreamweaver: selectores, propiedades y valores.

Esto dificulta la edición de dichos ficheros SCSS, sobre todo si estáis acostumbrados a los colores del código CSS.

Para añadir la extensión SCSS en Dreamweaver y que la detecte como hoja de estilos (CSS) hay que hacer lo siguiente:

(Ver leyenda al final del post)

WinXP

Debemos editar tres ficheros e indicar allí el cambio para que DW identifique los ficheros SCSS como CSS:

1º En "Documents and Settings":

El primer fichero a editar se encuentra en la típica carpeta de WinXP: "Documents and Settings". Rutas de ejemplo donde puede estar ubicado son:

C:/Documents and Settings/TU_USUARIO/Adobe/Dreamweaver CSx/%lang%/Configuration/Extensions.txt

ó la siguiente, según versión de Dreamweaver:

C:/Documents and Settings/TU_USUARIO/Datos de Programa/Adobe/Dreamweaver X/Configuration/Extensions.txt

En última instancia, si no lo encuentras en estas rutas, puedes intentar una búsqueda   en la carpeta  "Documents and Settings" del fichero "Extensions.txt"  mediante WinXP.

Localizado el fichero, abrirlo y sustituir "CSS:Style Sheets" por "CSS,SCSS:Style Sheets".

2º En la carpeta de instalación de Dreamweaver:

El siguiente fichero a editar está en la carpeta de instalación de Dreamweaver, por lo tanto la ubicación puede variar de un equipo a otro, según dónde lo hayáis instalado.

C:/Archivos de Programa/Adobe/Adobe Dreamweaver X/configuration/Extensions.txt

De nuevo, abrimos Extensions.txt una vez localizado y hacemos el mismo cambio que en el fichero anterior: abrir y sustituir "CSS:Style Sheets" por "CSS,SCSS:Style Sheets".

3º En la carpeta de instalación de Dreamweaver, fichero xml de tipos:

Por último, editamos el fichero MMDocumentTypes.xml donde se definen los tipos de Dreamweaver, el cual se encuentra en la carpeta de instalación del punto anterior, en:

...\configuration\DocumentTypes\MMDocumentTypes.xml

Abrir el fichero y sustituir winfileextension="css" por "winfileextension="css,scss".

4º Reiniciar Dreamweaver y listo

El último paso es fundamental, cierra el Dreamweaver (si no lo habías cerrado aún) y ábrelo de nuevo para que reconozca, por fin, los ficheros SCSS como CSS.

Win Vista / 7

El proceso para Windows Vista y 7 ha de ser idéntico, si bien aquí "Documents and Settings" no existe. Por lo tanto debéis usar la ruta típica de WinVista/7:

1º C:\Users\TU_USUARIO\AppData\Roaming\Adobe\Dreamweaver CSX\%lang%\Configuration\Extensions.txt abrirlo y sustituir "CSS:Style Sheets" por "CSS,SCSS:Style Sheets".

2º C:\Program Files\Adobe\Adobe Dreamweaver X\configuration\Extensions.txt abrirlo y sustituir "CSS:Style Sheets" por "CSS,SCSS:Style Sheets".

3º ...\configuration\DocumentTypes\MMDocumentTypes.xml Abrir el fichero y sustituir winfileextension="css" por "winfileextension="css,scss".

4º Reiniciar Dreamweaver

Leyenda

TU_USUARIO => Debes sustituirlo por tu usuario activo de WinXP.
\Datos de Programa\ => Ésta es una carpeta oculta. Debes tener configurado WinXP para que muestre los ficheros y carpetas ocultos.
Dreamweaver CSx o Dreamweaver X => x se refiere a la versión que tengas instalada, en mi caso "Dreamweaver 9".
%lang% => se refiere a un idioma. Si existe esta carpeta en vuestro sistema será del tipo es_ES.

Despedida y cierre

Y nada más, con esto ya deberías poder hacer que el Dreamweaver os detecte las SCSS como CSS.

Lógicamente, SASS permite cierta sintaxis no existente en CSS por lo que el coloreado de SCSS no es perfecto en Dreamweaver. Sin embargo, puede ayudar visualmente a la hora de desarrollar.

Espero que os haya sido de ayuda.

Hasta la próxima!

En las últimas versiones de los navegadores habrás podido comprobar que en las áreas de texto (etiqueta html: textarea) de los formularios aparece un control en su esquina inferior derecha que permite pulsar y arrastrar con el ratón para modifcar su tamaño.

Éste comportamiento, en general, es completamente indeseado pues normalmente existe un diseño al que ceñirse y redimensionar elementos internos puede llegar a romper la maquetación. Todo depende del diseño y cómo esté maquetado; pero personalmente nunca se me presento la necesidad de tener un textarea redimensionable.

Podemos utilizar la propiedad CSS3 resize y evitar o definir este comportamiento. La propiedad resize define si un elemento es redimensionable o no, y en caso de serlo en qué ejes.

CSS3

Evitar textarea redimensionable

Como hemos visto, para evitar la redimensión de un textarea (o de todos) simplemente debemos dar la propiedad resize:none; al selector CSS apropiado.

Dado un contenedor con un ancho determinado (ya sea en píxeles, porcentaje o relativo a fuente) y un alto también determinado podemos definir la propiedad CSS overflow para definir el comportamiento de dicho contenedor cuando su contenido supere esas dimensiones que tiene:

CSS2.1

CSS3

Para CSS3 tenemos estos mismos valores pero la propiedad podemos aplicarla indistintamente al ancho o al alto de la siguiente manera:

Funcionamiento y Crossbrowsing

La propiedad overflow determina el comportamiento frente al desbordamiento pero este comportamiento está directamente ligado a las propiedades width y height del contenedor. En general pienso que funcionan bastante bien y son muy útiles.

La propiedad CSS2.1 overflow funciona bien en los principales navegadores mientras que las propiedades CSS3 lo harán sólo en los navegadores compatibles con CSS3. En cualquier caso,  nunca está de más una revisión en los distintos navegadores objetivo, a fin de  detectar comportamientos distintos entre navegadores de estas propiedades y aprender a atajarlos; pues básicamente se basan en jugar con las propiedades CSS width, height y overflow del contenedor.

La nueva red social es más de lo mismo aunque con la marca de Google: como la mayor parte de productos de Google su aspecto es sobrio y sencillo, lo cual suele esconder no obstante gran potencia y posibilidades. Veremos cómo cumple Google+ con el tiempo pero hasta ahora ha tenido gran repercusión pese al poco tiempo que lleva operativo.

En estilorama* aún no utilizamos esta red social aunque esperamos comenzar pronto. Nos veremos por allí!

Bien, antes de comentar estrictamente qué es hotlinking necesito indicaros que un siitio web, cuando está online operativo, está consumiendo el ancho de banda del alojamiento/servidor contratado (en orden de MB o GB).

• Cada usuario que accede a cada página del sitio genera un tráfico a descontar del ancho de banda contratado.
• Al cargar una página, ésta se compondrá en base a otros ficheros internos de la página con programación etc. Cada fichero genera una petición y más trafico.

Ejemplo: Vamos a suponer que una página cualquiera de un sitio web pesa 0,3MB. Supongamos también que todas las páginas de ese sitio pesan lo mismo, y que hay unas 200 páginas diferentes.  Por otra parte, gracias a las estadísticas del servidor, sabemos que el último mes han solicitado cada página 20 usuarios diferentes, todos los días. Vamos a hallar el tráfico consumido en ese mes:

20 usuarios X 200 url X 0,3 MB X 30 días = 36000MB = 35GB aprox.
Esto es un cálculo ejemplo. En un caso real cada url pesa diferente, cada día hay un nº diferente de usuarios, etc.

Como vemos, hay muchos parámetros multiplicándose entre sí para hallar el tráfico mensual. Esto implica que cualquier cambio a mayor en el número de usuarios, número de urls del sitio o peso de la página, etc tiene un impacto negativo en el ancho de banda. Consumiremos más y si pasamos el umbral tendremos que contratar más ancho de banda para el servidor.

Esto hay que controlarlo y preverlo antes de que ocurra; pero hay otra manera de gastar ancho de banda de TU servidor y es que alguien haga HOTLINKING desde su página a su página.

¿En qué consiste el HOTLINKING?

Es muy sencillo. Se trata de "coger" código, imágenes, etc desde una página web A y mostrarlos en una página B; accediendo a los mismos directamente por código y consumiendo ancho de banda de la página A.

Página A: www.midominio.com
En esta página existe una imagen llamada "www.midominio.com/imagenes/logo.jpg" que pesa 13KB. La página tiene poco tráfico en general y sólo 0,5GB de transferencia contratada. Actualmente lleva consumidos 100MB este mes y estamos a día 28.

Página B: www.sudominio.com
Esta es una gran página con muchos visitantes y ha publicado el logotipo de la página A, en un banner contratado por la página A en la página B. Este mes podemos suponer unas 700 cargas de página al día con el banner de página A activo.

El problema es que no subieron el logotipo de A al servidor de la página B y lo vincularon desde el servidor B; sino que han utilizado directamente la dirección desde el servidor A: www.midominio.com/imagenes/logo.jpg.

Esto implica que con cada carga en página B se consumirán 10KB del alojamiento o servidor de la página A.

Haciendo cálculos:

Página A: 0,5GB = 512MB - 100MB = 412MB pendientes de gasto de ancho de banda. Utilizado el 19,5% del ancho de banda disponible en página A.

Página B: 13KB (peso logotipo) x 700 (páginas en las que aparece y se cargan al día) x 27 (días) = 240MB aprox. Esto incremente el uso de ancho de banda en página A hasta el 66%.

Lo que quiere decir que cogerte una imagen de tu servidor, directamente, puede incrementar el tráfico de tu página de manera desproporcionada. Y sólo es una imagen.

Conclusiones

El hotlinking recibido es una actividad "peligrosa" para los administradores de sistemas web. Hay que controlar minuciosamente el ancho de banda consumido y los logs del servidor para ver por dónde van los tiros en caso de aparecer alguna irregularidad. (Ej: aumento de tráfico sin aumento de visitas)

El hotlinking realizado es una mala práctica. Elimina esos enlaces y pon los ficheros en tu propio servidor.

Saludos a tod@s

Feliz cumpleaños FTP!!

Por ejemplo, imaginad el siguiente texto original publicado cierto día y que permanece así algún tiempo, siendo leído::

Ayer me encontre con el gran monstruo de macarrones volador

Tras algún mensaje del usuario (o como sea) nos percatamos de que hay un error en las palabras utilizadas en la frase y es que la frase correcta es la siguiente:

Ayer me encontré con el gran monstruo de spaguetti volador.

Alguien que esté atento a ese contenido verá que un día era una cosa, otro día fue otra... El texto es cambiante y hace sospechar al visitante más observador.

Bien, para que esto  no ocurra hay que especificar claramente qué es el texto borrado (etiqueta DEL) y cuál es el texto añadido (etiqueta INS). Ambas etiquetas son elementos de línea.

Ayer me encontré con el gran monstruo de macarrones spaguetti volador.

Puede haber los siguientes casos:

1. Eliminar una parte: se marca con la etiqueta DEL  y listo. En el texto aparecerá tachado pero sólo es una representación gráfica: su significado real es que ese texto se elimina.
2. Añadir una parte: se marca lo nuevo con la etiqueta INS. Indica una inserción de texto nuevo en cierto contenido. El texto aparecerá subrayado pero sólo es una representación gráfica.
3. Modificar un texto: se debe marcar la parte desechada con DEL y la parte nueva con INS. Fácil, ¿no?

Espero que os sea de utilidad.

Saludos a tod@s

Desde luego esta maravilla hay que probarla. Dejaré para más adelante un post analítico sobre el navegador en sí, de momento os dejo el enlace de descarga para que podáis ir conociéndolo por vosotros mismos: Descargar firefox 4 desde la web del autor.

Saludos!

En épocas rebeldes para los estándares web, había cierta tendencia hacia el poupurri de html presentacional y de contenido. Aparentemente no pasaba nada puesto que mientras se viera correcto en la pantalla, valía.

Evidentemente, esto producía mucho ruido: más peso en el html, mala o nula utilización de estilos, dificultad de mantenimiento por lo que fue necesario crear ciertas reglas que ahora llamamos estándares web: xhtml, css, xml, xslt, etc... Acompañadas por otras regla menos técnica: el marcado semántico, que no es otra cosa que marcar en el documento cada elemento con la etiqueta creada para su fin; tal como se representaría en un documento de texto tradicional, con su jerarquía de títulos, párrafos, subrayados, etc...

Etiqueta strong

La etiqueta strong, es un elemento de línea. Viene a sustituir al elemento B obsoleto, que significaba "negrita". El significado en html "Negrita",  "Cursiva" o "120px" es: ninguno, puesto que son propiedades de presentación. Por lo que esos detalles se los dejamos a las hojas de estilo CSS.

Realmente, una negrita en el texto viene a resaltar la atención. La regla básica es marcar como resaltado (o destacado) las partes más importantes de cada párrafo o grupo de párrafos, según se precise. Hay que tener en cuenta marcar partes realmente importantes y no marcar por marcar.

Etiqueta em

La etiqueta em significa énfasis, es similar y complementaria a la etiqueta strong. Viene a sustituir el elemento I (es una i mayúscula), que significaba "itálica" o "cursiva".  Sirve para dar énfasis a una parte del texto.

Es misión del creador de contenidos marcar correctamente lo que corresponda como strong y em; si bien es cierto que, en última instancia, queda a su criterio :)

Saludos!

El hecho que llevábamos esperando desde 2005 (incluso alguno seguro que más) ha tenido lugar. Incluso han creado un contador indicando el tiempo que le queda a IE6 por el mundo. Su intención es dejar a IE6 con una cuota del 1%. Todos sabemos que el caso ideal (en este caso 0%) es difícil de obtener en la práctica; pero desde aquí queremos apoyar la iniciativa ahora tomada por Microsoft, ya comenzada por Google y otras grandes empresas hace un año.

IE6 fue durante bastante tiempo un verdadero coñazo para desarrolladores y maquetadores web puesto que tenía mucha habilidad para:

• Mostrar innumerables bugs a diversos niveles del desarrollo de la interfaz obligándote a estar investigando el código escrito y en Google, e intentar darles esquinazo a dichos errores.
• Utilizar y representar los elementos y las propiedades CSS, un tanto a su modo. Incluso con alguna de ellas no estándar.
• Consola de javascript más sosa vista en la historia. Me parece que sus herederos siguen la misma tendencia. Hay que tirar de alguna toolbar que te dé algo más de operatividad.
• ¡¡Nulo soporte de PNG!! Bastante grave esto, puesto que obliga a poner un código JS para evadirlo.
• También era algo quisquilloso el IE6 al interpretar código JS: como tener que utilizar alguna función en concreto específica de IE.
• No permitía instalación de extensiones al estilo de los navegadores web modernos.
• Fueron culpables de los carteles: Web optimizada para IE a una resolucón de 1024x768, y similares.

Desde luego nos quitamos un buen ladrillo de encima.

La única virtud que le saco no es tal para los mortales comunes sino para la propia Microsoft que consiguió invadir todos los hogares que le fue posible con IE6, ya que se instalaba sí o sí con el Windows XP, allá por 2001, creo recordar que fue.

Desde luego la expansión fue fulminante, un éxito empresarial... Ahora bien, fue una malísima noticia para los estándares web y para los desarrolladores que desde entonces y hasta ahora tuvieron que pegarse con IE6, casi a diario. Hasta que empezaron a nacer el resto de navegadores web, con sus virtudes y defectos, pero apoyando en su mayoría los estándares web.

Gracias a los estándares web disponemos de mayor interoperabilidad entre plataformas: puedo subir este artículo desde Firefox, Chrome, IE, Opera, Safari, Lynx... Eso si lo hago desde el PC, o quizás desde Linux o Mac; pero nada me impediría utilizar la Blackberry, un iPhone, un Nokia, etc... para hacerlo. Esa es una de las grandes cosas de los estándares web.

Contador Microsoft: ie6Countdown

Parece ser que basan el cambio en reducir el ranking de sitios de baja calidad con poco valor para el usuario o que copia contenidos de otros sitios web, o que éstos no son últiles. Es una manera de recompensar a los sitios que crean contenidos originales y de calidad.

Quienes se van a ver afectados, ya para este año, son los que se dedican a vender campañas de posicionamiento. Ya que normalmente se aprovechaban de todos los trucos SEO existentes para posicionar las diversas páginas de tu sitio y puede que ahora ya no funcione alguno que otro e incluso puede que hayas perdido los resultados obtenidos hasta ahora. Habrá que estar atento; seguramente si tienes contratado el servicio con un buen SEO ya estará estudiando el tema y buscando soluciones. Sin embargo, si tenéis contratado el servicio de posicinamiento con alguna empresa de dudosa capacidad... seguramente estéis perdiendo visitas. Andad con ojo.

En estilorama* no nos dedicamos directamente a SEO aunque sí dejamos el código optimizado para SEO (o cualquier otro campo del entorno web ) porque utilizamos los  estándares web y creemos que dar contenidos buenos y originales es fundamental para que la web cumpla al 100% y sea visible para los buscadores sin recurrir a trucos que puedan ser penalizados en el futuro.

Hoy voy a comentar acerca de este emulador (compatible con Windows, Linux y Mac) de iPhone e iPad, que me ha salvado la vida en un proyecto para el cual el iPhone era dispositivo objetivo. Lamentablemente no dispongo de iPhone ni de la mayoría de teléfonos y gadgets con tecnología de navegación web; como supongo que os pase a alguno de vosotros también.

Mediante este sencillo emulador llamado iBBDemo podrás comprobar cómo se ven en iPhone e iPad las webs, ya sean versión móvil o pc, que estáis preparando en XHTML+CSS válidos.

Para instalarlo sólo debéis acceder a la página del autor y seguir las instrucciones. Es muy sencillo (Nota: instala el complemento AIR y es obligatorio para su funcionamiento).

Cabe destacar que el emulador cumplió su cometido con gran efectividad (que de eso se trata): pude comprobar la correcta visualización de las diversas páginas en iPhone y hacer las correcciones oportunas.

Ahora me queda comprobar con el cliente (que sí tiene un iPhone tangible) que todo esté correcto. Crucemos dedos :)

De momento:

Un gran emulador de iPhone e iPad y muy útil para el maquetador web.

Bien, esto implica que habrá que migrar hacia la versión IPv6 próximamente. Evidentemente, a quienes más les urge es a las grandes empresas del medio (Google, Facebook, Yahoo, proveedores,  etc) y el día 8 de Junio será el World IPv6 Day, durante el cual los grandes de internet pondrán a prueba sus servicios durante 24h sobre IPv6.

De cara al usuario, quedará esperar a ver qué va pasando pero puede que el tema no sea tan sencillo como apretar el botón: quizás haya que actualizar el firmware de ciertos routers de los que tenemos en las oficinas y en nuestras casas... En fin, ya veremos, de momento internet está a punto de conseguir un nuevo techo de IPs bastante más holgado que el IPv4 (si todo va bien, que es de esperar que sí).

Y ya veremos también para cuánto tiempo darán las previsiones de IPs disponbles con el nuevo IPv6, ya que todo depende de cómo siga creciendo la red en nº de usuarios, sitios web, dispositivos...  y bueno, creo que este dato es un sistema caótico y como tal, es muy difícil de adivinar con certeza su valor en un momento dado...

En fin, investigaremos más según se acerque la fecha del World IPv6 Day.

Saludos!

Conceptos

Internet: podemos decir que internet es una red de máquinas distribuida, basada en un conjunto de protocolos flexibles diseñados para operar entre diversos sistemas.

HTTP: es el protocolo de transferencia de información diseñado para trabajar con hipertexto (HTML, xHTML, etc) así como con otros tipos arbitrarios (imágenes, scripts, etc).

HTML: como ya sabemos, es un lenguaje de marcado utilizado pra describir documentos en hipertexto.

Web: entonces ¿qué es el web propiamente dicha? Pues el web sería el conjunto Internet+HTTP+HTML. Originariamente fue ideado como un universo de información global en el que las personas pudiesen comunicarse entre sí y con las máquinas.

Uno de los mayores logros del Web ha sido terminar con un mundo de sistemas de información incompatibles gracias a su independencia de plataforma (en este sentido caben mencionar los estándares web).

Cronología (I)

1945. Vanevar Bush publica el artículo "As we may think" en el que describe una máquina llamada Memex capaz de seguir referencias cruzadas en microfilms, utilizando tecnologías de células fotoeléctricas y fotografía instantánea. Con ello pretendia mecanizar las asociaciones que realizamos al pensar.

1965. Surge el término hipertexto, definido por Ted Nelson. Éste propone XANADU como repositorio literario.

1968. El paso siguiente fue el prototipo NLS (oNLine System) de Englebart, sistema de de colaboración que ya usaba ordenadores digitales y permitía usar email de hipertexto, compartir información, utilizar ratón y mucho más. Desarrollan el Augmentation Research Center.

Hipertexto y Web

HIPERTEXTO: es un cuerpo de material escrito o pictórico interconectado en una forma compleja que no puede ser representado convenientemente en papel.

La Web nace como solución a problemas de compartición de información en un entorno heterogéneo:

• Múltiples plataformas de hardware
• Diferentes sistemas operativos incompatibles
• Formatos de codificación distintos (lenguaje)

La disponibilidad de gran cantidad de información, imposible de compartir, también aceleró el desarrollo de la Web.

Requisitos del Web

- Un sistema general de información debería permitir realizar asociaciones aleatorias entre objetos arbitrarios, no como ocurre en la mayoría de Sistemas Gestores de Bases de Datos (SGBD).
- Al enlazar dos sistemas diferentes habría que evitar complejas operaciones de combinación de enlaces.
- La información debe estar disponible para toda plataforma.

Desde luego, se planteó todo un reto y un gran avance hacia las tecnologías TIC modernas. Hasta aquí el 1er capítulo de la breve historia de internet.

Si bien no nos es muy útil la aplicación del metro en sí, lo que es realmente espectacular del asunto es la api de GoogleMaps y la variedad de aplicaciones y utilidades que permite crear sobre la misma. Dejo pendiente para otra ocasión una recopilación de aplicaciones curiosas que se apoyan sobre GoogleMaps; es un tema interesante y seguro que tiene mucho jugo.

Visitar: Mapa en directo del metro de Londres

Me despido hasta otra ocasión!

El proceso de reconocimiento de caracteres es muy complejo y en este caso, lógicamente, no alcanza el 100% de precisión; por lo que podemos encontrar errores de interpretación que se traducirán en errores de texto en el documento final. En cualquier caso, es una funcionalidad avanzada que es bienvenida y esperamos sea mejorada con el tiempo.

Saludos!

El caso es que el teclado de las Blackberrys no trae la ñ entre sus teclas, ni en los caracteres especiales, donde sí aparece el símbolo ~ (poniéndote los dientes largos y distante de hallar la solución). Yo mismo estuve algún tiempo trampeando los emails y sms evitando escribir uno de los caracteres más específicos de nuestra lengua.

Pues muy mal hecho porque la solución era bien sencilla: simplemente pulsa la tecla N y a continuación y sin soltarla, seleccionar arriba o abajo en el trackball para moveremos por los distintos caracteres de esa tecla.

De la misma manera puedes sacar todos los caracteres especiales de cada una de las teclas del teclado de tu Blackberry. Bastante sencillo.

Saludos!

Hoy os voy a relatar una experiencia que tuve la semana pasada relacionada con el DNIe, trámites online y navegadores web. Los más técnicos pensarán que hay muchos más elementos relacionados; pero para esta historia corta no será necesario entrar en tanto detalle.

Como introducción al, ya conocido por todos, DNIe: su utilización para la realización de trámites burocráticos online es algo realmente funcional y productivo; ya que nos hará ahorrar tiempo por todas partes en todos esos trámites tediosos de la administración. Si bien esto no es del todo cierto ya que la instalación del lector de DNIe, junto con el módulo criptográfico, integrarlo en el navegador (o navegadores...) y que funcione, no siempre es lo rápida y limpia que desearíamos. En cualquier caso, yo tuve experiencias buenas y malas en la instalación; pero de una forma u otra, logré dejarlo funcionando; por lo que esto que comento no debería pesar a nadie.

(Próximamente dedicaré un post a explicar cómo prepararte para poder funcionar con el DNIe)

De hecho, tampoco hace demasiado tiempo había accedido al banco online mediante DNIe y no había tenido problemas. Sin embargo, últimamente, he intentado acceder con firefox y explorer a realizar unos trámites en la web de la Agencia Tributaria y en ninguno de los dos me funcionó.

Sin embargo, utilicé Google Chrome, y he de decir que me sorprendió ya que sí leyó del DNIe, me pidio mi contraseña y me dejó acceder al servicio sin problemas. Desde luego, visto el apuro que tenía por acabar y la utilidad y sencillez del navegador de Google para resolverlo, para mí ha ganado 1punto.

Podéis comentar otras virtudes que hayáis encontrado en Google Chrome con nosotros, si lo deseáis.

Por aquellas fechas, me encontraba revisando las estadísticas de Google para nuestro dominio, visitas, páginas de entrada, palabras clave... cuando sorprendentemente me encuentro con que han habido accesos desde las siguientes palabras clave: laboratorioweb, valeria piraino laboratorio y laboratorioweb.cl, las cuales (evidentemente) nada tienen que ver con nosotros por lo que investigamos un poco a ver qué eran aquellas keywords y/o de dónde provenían.

Accedimos a laboratorioweb.cl y ¡menuda sorpresa! ¡La web tiene nuestro diseño! ¿Nos han plagiado el diseño tan descaradamente? Concretamente la sección de servicios. No puede ser; pensamos:

Pues hasta ahora, se nos antojaba sospechoso el parecido de laboratorioweb.cl al diseño (de la sección de servicios, concretamente) que nos preparó disgenia.net; por lo que fuimos un paso más alla: comprobar el código fuente.

Comprobando el código fuente

Al comprobar el código fuente salimos de toda duda y supimos con toda certeza de que el diseño de laboratorioweb.cl es un plagio descarado del diseño de estilorama y, además, laboratorioweb.cl cometió robo de contenido al hacer el plagio:

Nota: ya hicieron algunos cambios; pero conservamos el código fuente del primer día, con la versión inicial del plagio. De todas maneras, los cambios hechos son ridículos y aún canta a la vista la usurpación realizada por laboratorioweb.cl

1º El código xHTML fue copiado y pegado, tal cual, de nuestra sección de servicios y modificando unas líneas de texto, solucionaron la papeleta. Esto aún se mantiene y podéis comprobar las similitudes que aún guardan si verificáis los códigos fuente xHTML.

2º La CSS de estilos generales (y alguna más) fue copiada de la original en estilorama y pegada tal cual en laboratorioweb.cl. Esto aún se mantiene.

3º Las CSS condicionales para explorer ahí quedaron. Tal cual; con ruta absoluta hacia estilorama.com; robándonos ancho de banda del servidor. Podéis comprobarlo en el código fuente si conocéis los condicionales CSS. Aún se mantiene.

4º La frase: "Hacemos todo tipo de trabajos en entorno web, desde maquetación XHTML hasta páginas web completas" ni se dignaron en cambiarla. Copiada y pegada tal cual.

5º En general, los títulos y textos están con mínimos cambios y aún se ve perfectamente que laboratorioweb.cl es una copia de la sección de servicios de estilorama. Han quitado los enlaces que existen en cada apartado. Esto aún se puede ver.

6º Dejaron nuestras funciones JS en los input del formulario de contacto, generando un error JS en su web, ya que no existe esa función en sus scripts. En el mismo formulario, la imagen del botón es la misma que la de estilorama.

7º Dejaron nuestra dirección de correo en el mailto: del enlace de contacto del pie (!!!). Esto ya fue demasiado pero parece que ya lo han corregido; aunque en la versión original del plagio está presente.

8º Y la grande: dejaron nuestro código de analytics por lo que están dejando su rastro de palabras clave en nuestras estadísticas. Mágico.

Tras la evidencia...

nos pusimos en contacto con la dirección de email que aparecía al pie de laboratorioweb.cl, indicando de la evidencia e instando a corregir la situación. Por supuesto, no obtuvimos respuesta si bien, a día de hoy, hemos comprobado que corrigieron el enlace del pie y cambiaron algo los metas; pero en general, el plagio aún sigue latente y bien visible.

Hemos optado por hacer una entrada en nuestro blog, al menos, para que el tema no caiga en el olvido. De momento: el diseño de laboratorio web es un plagio.

Saludos y gracias por leernos

1. FRAMESET y FRAME son elementos desaconsejados por el w3c.
2. Mezclan presentación con contenido.
3. El efecto visual que producen (si es la razón que tienes para usarlos) es perfectamente reproducible con CSS.
4. Mantiene siempre la URI estática al navegar por lo que todas las pantallas navegables del sitio tendrán la misma URI.
5. Por la razón anterior, el título de página siempre se mantiene estático, afectando al posicionamiento.
6. Presenta problemas al agregar una sección concreta a favoritos, ya que guardará siempre la URL que muestra (que por lo general será la misma que el index).
7. Presenta o puede presentar problemas de visualización en navegadores concretos, de indexación en buscadores y de usabilidad si se indexan páginas de contenido de un marco concreto y no permite la navegación desde el mismo, etc...
8. Al no tener una estructura de URIs, perdemos también enlaces de ancla a partes de un documento.
9. El código fuente del frameset no tiene contenido, propiamente dicho, dificultando el posicionamiento.
10. En general, no necesitarás utilizar frames o marcos jamás y menos aún si estás empezando en el desarrollo web y construyes nuevos sitios desde cero.

Un breve repaso y seguro que incompleto; pero creo que con razones suficientemente pesadas para tenerlas en cuenta y desviar nuestra atención de metodologías arcaicas.

Saludos

Aunque los datos de login se pasan por https (es decir, cifrados) , en cuanto se valida el acceso, Gmail guarda la cookie sin cifrar y esto permite que sea "espiada" cuando estemos comprobando nuestro correo sin estar conectados con https.

Esto permite, mediante técnicas de Cookie Hijacking, capturar nuestra cookie y acceder a nuestro correo.

Para evitar esto hay una opción en la configuración de Gmail. Es la siguiente:

Ir a Configuracion, Conexión del navegador y marcar "Utilizar siempre https".

Debéis tener en cuenta que no sólo Gmail puede tener este fallo y debéis ser muy cautos cuando os conectéis desde una red pública: siempre a través de SSL.

Saludos

El iPad

El nuevo "cacharro" de Apple para sus fieles seguidores o quizás ni eso, pues no ví demasiada reacción en internet a favor del iPad de mano de los ya usuarios (y parece que satisfechos) de iPhone, iPod, MacBook, etc...

Bien, veamos esas características del iPad.

Wi-Fi o Wi-Fi+3G
De mano, podemos ver que habrá 2 modelos diferentes, según conectividad: el primero (Wi-Fi) y el segundo (Wi-Fi + 3G). Bien. Esto no sé como se va a gestionar, pero al menos el segundo tipo (con 3G) a mi me huele a pago de tarifa de datos (enlace de ejemplo de las tarifas, no actualizadas, pero justificantes de lo que cuento) al operador correspondiente. Queda ver el tema Wi-Fi, pero perfectamente podría ser necesario pasar por la caja mensual de la operadora.

Pantalla
Podemos ver que posee una pantalla de 9.7 pulgadas, LED con capacidad Multi-touch. Protección anti-huellas y soporte para múltiples idiomas. Muy bonito; pero la triste resolución de 1024x768px nos hará retraernos a 1997, cuando mi monitor, por ejemplo daba ya esa resolución de pantalla; y había ya monitores que ofrecían más resolución. En cualquier caso, a olvidarse de la alta definición.

Capacidad
Existirán 3 modelos según la capacidad de su memoria flash, usada como disco duro: 16GB, 32GB, 64GB. Los cuales serán más rapidos que un disco duro tradicional, al ser memoria flash y no llevar mecanismos; pero se nos antojan ridículas esas capacidades, para los tiempos que corren y los espacios ya ocupados (en GB) en los discos duros de la gente. Aunque un poco más adelante veremos que poco importa la capacidad que dispongamos, puesto que no podremos meter todos nuestros ficheros en el iPad.

Procesador
Sistema en chip A4 de 1GHz, de alto desempeño y bajo consumo. Bien en este aspecto, tampoco voy a entrar demasiado, puesto que no hice ningún tipo de benchmarking al procesador ni a ningún otro. Desde luego, es de esperar que mueva el software del iPad con fluidez; pero a mi modo de ver, es bastante ridículo comparado con otros procesadores. Saliendo de reproducir videos, ver fotos y navegar por internet... No lo sé.

Batería
Desde luego, 10 horas de autonomía que prometen en su web es un buen número, comparado con un portátil de gama media; pero claro, al consumir poco tampoco se pueden esperar grandes especificaciones. Lo que sospecho es que cuando te pongas a jugar con el iPad, la batería se funda en mucho menos tiempo que el publicitado.

Entradas y salidas
Conector dock: En fin, un puerto de entrada/salida propietario. No haré comentarios, porque su propia especificación es vergonzosa. Los estándares existen por algo y si ese Dock es mejor que su homólogo estándar, no entiendo porqué no es él el estándar establecido. Para convertir ese puerto en conector usb, toca pasar por caja y adquirir el accesorio correspondiente. Muy bonito.

Salida para auriculares estándar (menos mal. ¿Poca capacidad para crear un estándar mejor?): minijack de 3.5

Altavoces y micrófono integrados.

Bandeja para la tarjeta SIM (en el caso de Wi-Fi + 3G).

TV y Video
Reproduce Videos con audio estéreo en formato .m4v, .mp4 y .mov. Esto ni lo comento porque al leerlo ya os debe de chocar a todos.

Facilidad de uso
En este aspecto, creo que lleva la de ganar.  El aparato ha de ser muy amigable y fácil de usar. Aunque claro, para las 4 cosas que tiene, no vas a tener que comprar "La Biblia del iPad"...

Comercial
Todos vimos la presentación inflada del iPad, y digo inflada puesto que no había otras palabras en el ambiente que "Mágico, Increíble, Fantástico...", a modo de mensaje de subliminal. La gente de Apple (y mucha más) son expertos en meternos necesidades inútiles en la cabeza: ¡Comprad malditos!

Espero que os haya entretenido esta entrada, o al menos, os haya invitado a conocer más a fondo el iPad y lo que os puede ofrecer.  Si tenéis alguna réplica que hacer, podéis dejarnos un comentario. Gracias por vuestra atención.

• Memory Stick. Es la versión inicial de la tarjeta.
• Memory Stick Pro. Es una revisión que permite mayor capacidad y velocidad de acceso.
• Memory Stick Pro Duo. Es una revisión de la tarjeta que presenta un tamaño inferior al habitual.
• Memory Stick Micro. Es una revisión de la tarjeta, en tamaño mini, al estilo de microSD; muy utilizada en teléfonos móviles.

Pese a ser Sony el principal defensor de las Memory Stick, los únicos fabricantes relevantes de las mismas son ScanDisk y Lexar.

Hecha esta pequeña introducción; ya conocemos la posición de Sony durante los últimos 10 años. La noticia es que,  a partir de ahora, Sony da su brazo a torcer y va a ofrecer una nueva serie de tarjetas de memoria; pero en formato SD:

• 2GB SD
• 4GB-8GB-16GB-32GB SDHC
• 2GB microSD
• 4GB-8GB microSDHC

Sin embargo, éstas tarjetas se ofrecerán para el almacenamiento en cámaras digitales, teléfonos móviles, etc mientras que la PSP, cámaras digitales Sony, PS3 y otros productos propietarios de Sony seguirán utilizando la Memory Stick.

La debate ahora es ¿qué necesidad hay de crear un caos a la hora de comprar/buscar tarjetas de memoria? Que si MMC, SD, Memory Stick...

Sí es comprensible sacar revisiones de una tarjeta, si mejoran las especificaciones; pero ¿tanta variedad para tareas cotidianas? ¿Tenemos que estudiar las especificaciones de todo? ¿Por qué no utilizan su potencial en conjunto para sacar una tarjeta estándar?

En estilorama* somos defensores de no tener que poseer 4 tipos de tarjeta distintos; de poder reutilizar las tarjetas de dispositivos que no utilizamos, etc. Creo que actualmente la SD es la que mejor cumple estas funciones.

Fuente: Sony

XHTML es un lenguaje de marcado de hipertexto extensible, similar y supuestamente sustituto del ya mítico HTML (lenguaje de marcado de hipertexto), y al igual que este último, sirve para dar forma y significado semántico a un documento web.

Esto quiere decir que son muy parecidos, sin embargo, la diferencia principal es que XHTML está basado en XML y cumple sus especificaciones. Pero esto no significa que HTML esté muerto, ni mucho menos: HTML4 sigue siendo recomendación del w3c y ya sabemos que el HTML5 está en preparación y desarrollo

Diferencias entre XHTML y HTML

Viendo esto parece que el HTML es la cosa más sucia que vió la web. Bien, esto no tiene porqué ser así. Si nos dejamos guiar por los validadores HTML del w3c, podemos obtener un documento web igual de válido que el análogo en XHTML. Los requisitos del proyecto o tu propio gusto deberá guiarte en si escoger una versión u otra.

Recordad que, dependiendo del doctype que escojais, deberéis ajustar otros pequeños detalles como por ejemplo, no incluir texto directamente sin un "contenedor":
Ej: Hola Mundo directamente en el BODY sería incorrecto. Debería estar dentro de, al menos un párrafo (p).

En estilorama* actualmente utilizamos XHTML por norma general; pero hemos desarrollado en HTML y si es un requisito; no tenemos problema en implementarlo.

Hasta otra!!

Saludos

Actualización: Hoy 19 de Noviembre he accedido a Youtube, y como prometían, ya tienen vídeos que se pueden visualizar a 1080p. Esperemos que vaya creciendo el número de videos que lo permitan. En cualquier caso, el video a 1080p parece cargar fluido con la conexión que tenemos aquí, que no es la máxima del mercado.

A ver cómo resulta todo pero la verdad que tiene muy buena pinta.

Idioma del documento y del texto

1º Marcamos el idioma en la etiqueta html, mediante el atributo "lang". Por ejemplo lang="es", indica que el documento es en español y éste sería su idioma base. Antes de dar un valor al atributo lang, éste tendrá el valor "desconocido". (HTML Y XHTML)
2º Si el documento es XHTML, además de lang, hemos de añadir también el atributo de lenguaje compatible con XML(xml:lang): xml:lang="es". (Sólo XHTML)
3º Si a lo largo del documento se produce un cambio de idioma, por cualquier motivo (un párrafo, una cita, un acrónimo, etc), hemos de indicarlo mediante el atributo "lang", para que sea detectado por los agentes de usuario. Se puede poner el atributo lang a las etiquetas P, TABLE, DIV, SPAN, ABBR, ACRONYM, etc allá donde haya un cambio de idioma, respecto al idioma "base" del documento. (HTML y XHTML).

De esta manera vamos marcando el idioma para todos los documentos de nuestro proyecto. Cuando preparemos un proyecto multi-idioma, tenemos que fijarnos al cambiar de idioma de cambiar también todas los atributos "lang", y adaptarlos al nuevo idioma que presenta el documento.

Dirección del texto

4º Si, por requisitos del lenguaje, hemos de modificar la dirección del texto (por ejemplo, el árabe se lee de derecha a izquierda); podemos utilizar el atributo "dir". El cual puede tener los valores: "ltr", de izquierda a derecha (por defecto) y "rtl", de derecha a izquierda.

Creo que no me dejo nada en el tintero. Si tenéis alguna duda, sugerencia o corrección que hacer...

Saludos!!

Como siempre, existen navegadores más preparados para el futuro, con soporte para nuevas versiones de CSS. Concretamente CSS3 está a puntito pero aún no es soportado por todos los navegadores y además, no siempre al 100%.

¿Esto quiere decir que puedo o que no puedo utilizar estas propiedades?

Bien. Esto queda a puro criterio del desarrollador. Personalmente, creo que deberían de poder usarse y que el validador w3c no debería de protestar por utilizar propiedades CSS3. Pero esto no es así y utilizando nuevas propiedades conseguirás un error de validación CSS en cada elemento que tenga una de ellas.

Ventajas de utilizar nuevas propiedades

- Puedes aportar novedosos efectos a tus sitios web, mediante más CSS.
- Aprendes bastante al moverte por nuevas especificaciones y más aún, si investigas el porqué de las nuevas propiedades.
- De la misma manera, vais practicando con nuevas propiedades y sus efectos, para cuando la versión 3 esté operativa 100%.

Desventajas de utlizar nuevas propiedades

- El documento, a dia de hoy, presentará un error de validación por cada elemento que tenga una de ellas.
- No todos los navegadores representarán dicha propiedad.
- Cualquiera puede validar y opinar sobre la pureza de tus estilos, de manera contraria a tu posición. (No es una desventaja muy clara).

Si tenéis alguna sugerencia... adelante!!

Saludos

• Transicional (Transitional): es el más extendido. Presenta un paso intermedio entre la manera "antigua" de hacer documentos (x)html (etiquetas desaconsejadas como font aún son toleradas por este doctype, entre otras) y la manera adecuada, utilizando sólo los elementos aconsejados por el estándar w3c (Strict).
• Estricto (Strict): es la meta final de todo sitio web que utiliice estándares. Como su nombre indica, es considerablemente más estricto que el doctype transicional, a fin de generar un documento mas puro, estructuralmente hablando.
• Marcos (Frameset): los marcos están desaconsejadísimos y nunca deberías de utilizarlos. En cualquier caso, si los usas, éste es tu doctype.

Sea de un tipo u otro, el doctype es obligatorio en todos los documentos (x)html y ha de ser la primera declaración de todas. Sin doctype, al pasarle el validador de documentos (x)html, éste cogerá un doctype por defecto pero será tomado como un error de validación. Y no sólo tenemos ese problema, ya que un documento sin doctype se va a representar diferente en los diversos navegadores y seguramente en la mayoría no funcionen como deberían vuestras técnicas CSS.

Si tenéis algún apunte que hacer, como siempre, tenéis abiertos los comentarios.

Saludos!!

¿Qué es un captcha?

Un captcha es una medida de "seguridad" que ayuda a impedir que los formularios de una web, sean procesados y rellenados con SPAM; y posteriormente, enviados. El funcionamiento es sencillo y conocido por todos: se genera una imagen con una serie de caracteres aleatorios, los cuales hay que introducir en un campo del formulario, como método de comprobación de que la pantalla está siendo leída por una persona y no por un proceso automático de un programa.

¿Es realmente necesario?

Bajo mi punto de vista, quizás no sea necesario tenerlo en cuenta de base o a la publicación inicial del sitio; pero lo que estoy seguro es que si no se implementa, con el tiempo y el incremento de visitas lo echarás en falta y recibirás mensajes de SPAM en tu correo (vía el formulario de contacto de la web) o bien SPAM en forma de comentarios de un blog, etc. Como nos ha estado pasando en nuestro Blog*.

¿Y no hay ninguna alternativa?

La alternativa rápida que se me ocurre es la protección de los formularios, que recepcionan datos en tu sitio web, mediante una zona privada, accesible sólo tras registro e identificación del usuario. El proceso de registro ha de estar protegido, a su vez, mediante email de confirmación a la cuenta del registro.

Cómo medida extra siempre puedes implementar, junto con la zona privada, el captcha de cada formulario; para tener un nivel más de "seguridad".

Conclusiones

El SPAM es uno de nuestros mayores enemigos. Con esta técnica conseguiremos minimizar el SPAM recibido mediante los formularios de nuestra propia web. Sin embargo, el SPAM recibido directamente en nuestra cuenta de correo es otra historia ya...

Saludos!!!

Hay que decir que en sitios web de los profesionales del sector el porcentaje de uso de Firefox, unido con otros navegadores, se incrementa notablemente.

Veo en las estadísticas de w3schools que en Septiembre de 2009, en general:

Navegadores IE (6, 7 y 8) - 39,6%
Resto de navegadores (ff, opera, chrome, safari...) - 59,5%

Si tenemos en cuenta que el gran navegador enemigo del desarrollador, y de internet en general, es el ie6 vemos que la cosa ha mejorado susceptiblemente:

IE6 - 12,1 %
Resto de navegadores - 87%

Ya sé que los porcentajes no suman 100%. Esto debe ser a causa de otros navegadores utilizados, no tenidos en cuenta en estas tablas.

Hecha esta pequeña introducción os planteo la siguiente cuestión:

¿Que creéis que ha motivado, desde el comienzo de FireFox, el que haya crecido su uso: diseño, funcionamiento, extensiones...?

Esperamos vuestra opinión!!.

Saludos.

En cualquier caso, dicho post ha dejado huella en internet ya que con una simple búsqueda encontramos multitud de referencias al tema. Y no siempre a favor del mismo: hemos visto discusión en la que algún individuo dudaba de la validez de las maquetaciones tableless.

¿Algún tipo de teoría superior habrán encontrado? Parece que no. El hecho se daba simplemente porque dichos individuos habían aprendido a montar sitios web en la época de los TR y spacers .gif y consideraban poco útil y laborioso el cambio a no utilizar tablas para maquetar. La máxima que defendía esta gente es que era mucho más dificil e impreciso maquetar sin tablas que que con ellas.

Una buena tontería. Cuando nosotros aprendimos también habían TR y spacers.gif pero de ninguna manera se hacía más maniobrable el código que el que utilizamos actualmente. Sino, más bien, todo lo contrario: era misión imposible controlable para mi gusto. De hecho, no se me hubiera pasado por la cabeza dedicarme a entornos web si todo hubiera seguido así.

Menos mal que con los estándares topamos. Nos quitamos de encima todos los border=0, spacers, y líneas y líneas de TR y TD, de un plumazo. De manera razonada y poco discutible, tenemos los siguientes "preceptos" antitablas:

• Las tablas son para datos tabulares: cada elemento (x)html tiene una finalidad. Una tabla tiene la misión de mostrar datos de forma tabular: un horario, una lista de precios, etc...
• Las maquetaciones sin tablas son más ligeras: generan documentos de menos tamaño, lo cual el usuario al acceder y el servidor al responder las peticiones, agradecerán.
• Gracias a la hoja de estilos externa, los sitios tardan menos en cargar. Ya que una copia de ella se guarda en la caché del navegador.
• Podemos mantener una coherencia visual entre las diversas páginas del sitio sin grandes esfuerzos, gracias a la hoja de estilos CSS.
• El rediseño completo del sitio sólo requiere tocar CSS.
• Utilizar correctamente el XHTML ayuda a mejor nuestra posición en los buscadores.
• Utilizar CSS no es impreciso. Puedes maquetar al px de precisión, si es requerido.

Viendo todas estas ventajas parece increíble que alguien pueda dudar sobre la invalidez de las maquetaciones hechas con tablas. Esa gente existe y aunque las maquetaciones sin tablas son cada vez más utilizadas, todavía hay muchísimos sitios en internet construidos sobre una tabla gigante, con estilos metidos con FONT BGCOLOR, etc...

Quizás algo de culpa del tema esté en los propios centros de educación, que no renuevan los temarios de acuerdo con los sucesos que les rodean. Apuesto la cabeza que en el curso Desarrollo Web para desempleados, del INEM, ni siquiera nombran al w3c. ¿Cómo lo véis?

Descripción del bug

Digo conocido porque seguramente os lo hayáis encontrado en más de una ocasión, en algún proyecto o navegando por internet. Y desconocido debido a la naturaleza del bug, que la primera vez que lo ves se hace difícil intentar razonar qué puede hacer aparecer esos caracteres de más, en zonas donde no debería haber texto. Mi primera reacción al ver dicho efecto fue buscar en Google 'caracteres fantasma' y efectivamente, encontré referencias a duplicate chars.

Vamos a ver las maneras de solucionarlo, que son varias y apuesto la cabeza a que no son las únicas, y finalmente sólo la experiencia y práctica solucionándolo indicará cuál es mejor. Pese a conocer la manera de solucionarlo, en parte sigue siendo un misterio y no entiendo qué puede producir tal locura en nuestro "amigo" ie6.

¿Cuándo suele aparecer?

Por mi experiencia personal, enumero las razones que he comprobado:

1. Ocurre al maquetar utilizando float. Nuestra manera favorita :(
2. Suele darse con elementos flotantes adyacentes en el código, por lo que al maquetar con float, nos puede afectar.
3. Puede darse por espacios en el código xHTML.
4. Puede darse por comentarios en xHTML. !Éstos, además, pueden producir otros fallos en el renderizado de tu página en ie6! No los recomiendo.
5. Y como última posibilidad, atención a la propiedad CSS padding, que en combinación con otras propiedades CSS (o no), del elemento afectado (del que se duplican los caracteres), su contenedor, y los elementos flotantes adyacentes.

¿Cómo controlar esto?

Particularmente, hago lo siguiente:

1. Aislar el código CSS de los elementos implicados en el bug: elemento afectado, elementos adyacentes y el elemento contenedor. Sabemos que aislamos el código afectado si al comentar todo ese código y comprobar en el ie6 la maquetación, no presenta el duplicate chars.
2. Comprobar que no hay ningún comentario en el xHTML en toda su extensión y que no haya espacios, al menos en los alrededores de las capas afectadas; aunque puedes dejar el tema de los espacios y saltos de línea para más adelante, si estás seguro y comprobaste que el bug lo hace saltar la CSS y no el xHTML.
3. Intentar quitar algún float de los elementos afectados, comprobando que no estropee la maquetación.
4. En este momento, comentaría la mitad del código CSS afectado y comprobaría si el bug se sigue produciendo, desde el ie6. Si se produce, sabemos que el "culpable" de saltar el bug está en la otra mitad de código. De esta manera puedes ir cerrando el cerco alrededor del código CSS afectado, comentando partes mas grandes, hasta llegar a una o varias propiedades CSS que son las "causantes" del bug.
5. Si en este punto no has solucionado el problema, puedes usar la metodología de comentar el código CSS para buscar las propiedades críticas por todo el fichero CSS.
6. Si aún no se ha solucionado y ni siquiera te has acercado a la solución, quizás debas estudiar de una manera más profunda el bug:
   Positioniseverything tiene una buena explicación y diferentes formas de solucionarlo a las que yo he expuesto, creo recordar.

Despedida

El mundo de los bugs de ie6 es increíblemente extenso, con errores para todos los gustos; aunque espero, por el bien de todos, que tengan los días contados. Ya existen iniciativas para animar a la gente a que se actualice a navegadores actuales. En fin. El tiempo dirá.

Tenemos hasta 6 marcas: h1, h2, h3, h4, h5 y h6. El h1 indica encabezado de primer nivel y así sucesivamente.

Es muy sencillo utilzarlos de manera adecuada:

Debes utilizar hx para marcar los encabezados semánticamente y, así, que estructuren el documento que estás creando.
Esta regla se puede aplicar a todos los elementos xhtml (válidos para el DOCTYPE que hayas escogido). Existen para que se usen y cada uno de ellos sirve para marcar una cosa concreta, por lo que está bien tenerlo en cuenta siempre. Hay que tener en cuenta también el cerrar bien los elementos y demás matices básicos de maquetación con HTML o XHTML, en los que, ahora mismo no voy a entrar. Aunque no descarto hacerlo próximamente.

Respeta la jerarquía de los encabezados.
Empieza con h1 para el primer encabezado, y continua con los siguientes: h2, h3, ..., h6 según requiera la estructura de tu documento.
Ten en cuenta que no puedes saltar la jerarquía al insertar encabezados. Tienes que seguir el orden h1, h2, h3, etc.
Por ejemplo: h1, h2, h3.. sería correcto. h1, h3.... está mal.

Sin embargo, los encabezados de un tipo concreto ya incluidos sí pueden repetirse, como por ejemplo: h1, h2, h1.

¡Optimiza tus encabezados!
Existen extensiones para los diversos navegadores que te ayudan a comprobar y probar qué tal llevas los encabezados en tu documento.Yo conozco el de Mozilla Firefox y es el que os puedo recomendar, ya que tiene muchísimas funcionalidades más para el desarrollo web. Web Developer (Firefox).

Para comprobar la correcta estructura de los encabezados de tu documento puedes hacerlo comprobando si al leer sólo los encabezados (ocultando el resto de textos e imágenes) se mantiene, en general, el sentido del contenido y de la jerarquía que representan.

Comencemos por el principio:

¿Qué es el w3c?

Por dar una definición propia, sin tirar de wikipedia, puedo decir que el w3c es un organismo mundial, formado por diversos miembros (asociados, desarrolladores, instituciones, empresas de tecnología, etc); los cuales se dedican a poner un poco de orden en diversas tecnologías (XHTML, CSS, XML, javascript, etc) y unificar en una sola, todas las formas de utilizar una tecnología concreta. La meta es interoperabilidad correcta entre diversas plataformas, correcto acceso al contenido, separación de presentación y contenido, accesibilidad web, etc; entre otras cosas.

El w3c tiene muchas oficinas repartidas por todo el mundo y las discusiones sobre las diversas tecnologías no cesa jamás, por lo que hay que estar bastante al día sobre las últimas novedades de las tecnologías en las que estés implicado.

Los estándares en páginas web: (X)HTML y CSS

Uno de los temas fundamentales que tratan es sobre la mejor forma de crear páginas web y que esté unificada. La manera correcta de llevarla a cabo es olvidarse de editores WYSIWYG, coger la referencia de (X)HTML y CSS y comenzar a maquetar el documento en nuestro editor de textos favorito, en base a las recomendaciones del w3c.

(X)HTML
Tanto XHTML como HTML, son lenguajes de marcado de hipertexto. Gracias a éstos lenguajes podemos marcar los diversos contenidos de nuestro documento; y darles significado más allá del texto que contienen. Por ejemplo, la etiqueta strong, indica que el texto que contiene ha de ser marcado como más importante. En el caso de navegadores normales como firefox o ie, lo mostrarán en negrita; mientras que los navegadores de voz (para personas invidentes), leerán con más fuerza esas palabras.

Es importante utilizar el marcado correctamente y con cabeza: utilizar encabezados, párrafos y listas cuando sea necesario y las tablas únicamente para mostrar datos tabulares. Cada elemento (X)HTML existe para dar una funcionalidad que el resto de etiquetas no puede dar. Usemos cada elemento para lo que fue concebido.

El XHTML/HTML no sirve para colorear los textos o los fondos de página: para todos los temas de estilos tenemos las hojas de estilo.

Hojas de estilo (CSS)
Una vez hayamos moldeado nuestro documento con XHTML, ya tenemos el contenido y podemos acceder desde cualquier navegador. Sin embargo, el aspecto que presentará será el más feo posible: los estilos por defecto, fondo blanco, texto negro y poco más. Pero eso tiene solución.

Todos esos estilos podemos modificarlos a nuestro gusto, y con gran precisión, gracias a las hojas de estilo. Una hoja de estilos es un documento escrito en un lenguaje de estilos determinado (CSS para (X)HTML, XSLT para XML, etc),  que permite modificar el aspecto y ajustarlo a un determinado diseño que nos hayan pasado nuestros compañeros creativos.
Utilizar XHTML y CSS, bien utilizados,  garantiza la separación entre presentación (CSS) y contenido (XHTML) y unifica el aspecto que tendrán todos los documentos XHTML que lleven vinculada una hoja de estilos concreta.

Conclusiones

Pese a que todo es tan obviamente útil, aún queda mucho camino por recorrer para que los estándares del w3c formen todos y cada uno de los documentos que conforman internet. Quizás, hasta sea una tarea imposible. En cualquier caso, en estilorama, apostamos por los estándares w3c: nacimos ya utilizándolos y asi seguirá hasta que se encuentre y demuestre otra metologia mejor.

Saludos

Os damos la bienvenida y os animamos a que participéis: expongáis vuestra opinión, preguntéis dudas, desarrollemos más los temas tratados con vuestros comentarios, etc... Es una buena manera de recopilar información sobre los estándares y que esté accesible para el público.

Por ahora nada más.

Os invitamos a que nos visitéis periódicamente y que participéis activamente en nuestro Blog*: tu mensaje no quedará sin respuesta ;)