Lesson No. 1: Everything you know is wrong… sort of
Just so we’re on the same wavelength, I want to underscore the fact that if you’re starting to work with CSS, everything you’ve learned to this point probably feels useless, or worse than useless.

Una lectura interesante para aquellos que quieran pelear con (X)HTML.

Real como la vida misma.

El segundo enlace es “Design Tips for Building Tag Clouds”, en el que se dan algunas sugerencias y consejos sobre como presentar las nubes de etiquetas, sin ninguna explicación técnica (nada de programación ni HTML), sólo es una breve discusión sobre cómo hacerlas más útiles.

Y ya puestos a dar enlaces quiero rescatar algunos que considero interesantes sobre diseño líquido. El primero, “Liquid layouts the easy way” en el que se da una introducción a los diseños líquidos en HTML (distribuciones de páginas que no tienen un tamaño prefijado y que se adaptan al navegador y/o al dispositivo). El segundo artículo “Liquid CSS Layouts - Design Alternative to Table Based Websites” es algo más extenso y entra en más detalle sobre las implementaciones. Son técnicas antiguas y seguramente muchos las conoceréis, pero no está de más intentar adoptar esa nueva forma de diseñar para hacer una web más usable y accesible ¿no créeis?

Leyendo la crítica en la que se anuncia la creación de este grupo podemos adivinar que el objetivo es tener una un conjunto de reglas claras, bien definidas y basadas en estándares como HTML (parte de las quejas hacia WCAG 2.0 se centran en que ¡no es necesario tener (X)HTML válido!). También parece que quiera darse importancia a “la accesibilidad que no pueden comprobar las máquinas”, ofreciendo un lenguaje claro, alternativas para las personas con problemas de visión o sordera, una buena plataforma sobre la que desarrollar multimedia accesible.

Realmente me parece muy interesante el proyecto, creo que WCAG 1.0 a pesar de sus lagunas puede ser un buen punto de partida, y el espiritú que transmite el anuncio (centrarse en estándares y en lo que se ha aprendido en la realidad) me hace ilusionarme por unas WCAG 1.1-Samurai o como vayan a llamarlas. ¿Qué deseas ser miembro y aportar tus experiencias? Me temo que no podrá ser:

WCAG Samurai will toil in obscurity for the foreseeable future. Membership rolls will not be published, and membership is by invitation only. Don’t call us; we’ll call you.

En el mismo artículo explica que quizás no sea la opción más justa, pero que creen que para este tipo de documentos y especificaciones es la mejor forma de trabajar. Esperamos vuestro trabajo con los brazos abiertos, samurais.

Por cierto, Joe Clark trabaja como consultor experto en accesibilidad, escribió Building Accessible Websites, y colabora regularmente en ALA.

‘Surfing’ is a really misleading metaphor, right? Surfing evokes images of beaches, bikinis, fun times and waves in the sun. Sitting glued to a monitor, clicking-away into the never-never is the furthest thing from this possible (OK, so may be there’s a few bikinis).

¿Os hace ser muy improductivos tener un navegador a vuestra disposición en cualquier momento? Yo debo admitir que sitios como Slashdot, Barrapunto y Bloglines más de una vez hacen que me salga de mi camino. No me extraña la aparición de términos como infoxicados (aunque debo admitir que me gusta más el término information overload.

It’s $80 more than the Pro plan ($19 vs. $99), and we were worried that it might be a bit too expensive. Holy crap, were we wrong.

Y explica la experiencia de un producto web que ha conseguido aumentar sus ingresos gracias a un producto. Otro enlace interesante, sobre un caso típico de los precios la enlazan en los comentarios. Además, así también he descubierto Vitamin un sitio que parece bastante interesante para ir observando el momento punto-com 2.0 desde un punto de vista optimista y constructivo.

Creo que mucho de todo eso de AJAX es un poco exagerado. Mucha gente ha estado utilizando cosas parecidas
desde mucho antes que se llamase “AJAX“, y realmente tampoco es tan complicado como mucha gente lo hace parecer.

Aquí hay un pequeño ejemplo de una de mis aplicaciones. Primero el JavaScript:

function createRequestObject() {
var ro;
var browser = navigator.appName;
if(browser == "Microsoft Internet Explorer"){
ro = new ActiveXObject("Microsoft.XMLHTTP");
}else{
ro = new XMLHttpRequest();
}
return ro;
}

var HTTP = createRequestObject(); function sndReq(action) {
HTTP.open(’get’, ‘RPC.php?action=’+action);
HTTP.onreadystatechange = handleResponse;
HTTP.send(null);
} function handleResponse() {
if(HTTP.readyState == 4){
var response = HTTP.responseText;
var update = new Array();

if(response.indexOf(’|’ != -1)) {
update = response.split(’|');
document.getElementById(update[0]).innerHTML = update[1];
}
}
} Con este código creamos un objecto Request además de una petición de envío y una función que gestione
la respuesta. Si quieres usarlo añades este JavaScript a tu página. Después para usarlo tan sólo necesitas
enlazarlo a algo, como por ejemplo a un evento onclick o directamente en un href como este: [foo] Así cuando alguien haga click en ese enlace lo que realmente pasará es que se generará una petición a
RPC.php?action=foo que se ejecutará en el servidor. En RPC.php puedes tener algo como esto: switch($_REQUEST['action']) {
case 'foo':
/* do something */
echo "foo|foo done";
break;
...
}


Ahora, miremos a la función handleResponse. Analiza la cadena “foo|foo done” y la separa a partir del carácter
‘|’. Entonces utiliza lo que va antes de ‘|’ como el identificador del elemento DOM de la página y lo que va después
será el nuevo innerHTML del elemento que hemos referenciado. Esto significa que si tenemos una etiqueta div como esta: