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 ;)