Fecha de publicación: 2008/10/26
Hace más de un año saltó el escándalo del aberrante sitio web del Congreso de los Diputados (no por el aspecto, sino por el código y la accesibilidad).
En aquel momento se podían ver varias declaraciones de DTD a lo largo del código fuente, varias aperturas del elemento BODY y aberraciones similares.
En este momento parece que han solucionado algunos problemas. Pero está maquetada en tablas y tiene Javascript intrusivo. En el HEAD tiene elementos STYLE llenitos de reglas CSS (todo eso es mejor meterlo en un documento externo CSS y vincularlo al HTML con el elemento LINK). El sitio dispone de una página de accesibilidad, y al menos tienen la decencia de no colgarse medallas y decir que están en ello.
Han pasado 16 meses desde que se vio el asunto: ¿no es suficiente tiempo para arreglar un problema de maquetación?
Documento RTF (se abre con cualquier procesador de textos) con el HTML de la página de inicio del Congreso en el 26 de octubre de 2008 (este documento puede herir su sensibilidad y/o dañarle la vista: lo abre bajo su propia responsabilidad).
Otro detalle. Parece que el engendro ha sido puesto en marcha por Indra y por Telefónica. Son empresas mas o menos poderosas. ¿No tienen en sus filas ni un solo maquetador cualificado? Si no lo tienen, ¿no pueden subcontratarlo? ¿No hay nadie del Congreso supervisando la calidad del sitio web que han montado (y viendo si han tirado el dinero)?
Pagadores de impuestos, como bien dijo CCCP diputada en el Congreso:
Estamos manejando dinero público, y el dinero público no es de nadie.
Fecha de publicación: 2008/10/20
Un aspecto que debe cuidar una empresa cuando dispone de un sitio web es el del mantenimiento y creación de contenidos. Se suelen utilizar gestores de contenido, lo que facilita dicha tarea.
Y es ahí donde pueden surgir problemas. ¿Quién se dedica a introducir y modificar los contenidos? Hay ocasiones, incluso en compañías enormes que son la cabeza visible de su sector, que esa tarea se encarga a personas sin el más mínimo conocimiento de HTML.
Esto ocasiona que a veces un portal que se ha elaborado respetando estándares y accesibilidad acabe perdiendo dichas características, de modo que la inversión extra realizada para ello resulta un desperdicio.
Las personas que se dediquen a realizar estas funciones no tienen por que saber de maquetación HTML-CSS, pero si deben tener unos conocimientos básico de HTML que no es muy complicado de aprender:
DIV, SPAN.H1-H6, P, BR, STRONG, EM.BR.DL, UL, OL, DL: las etiquetas para listados.TABLE, CAPTION, COL, COLGROUP, THEAD, TBODY, TFOOT, TR, TH, TD etiquetas para tablas. Debe también saber hacer uso del atributo scope.IMG: debe conocer al menos el atributo alt.id y class.Además deben saber en que momento utilizar cada etiqueta y como hacer que el contenido que están generando sea mínimamente accesible.
Fecha de publicación: 2008/10/18
Listado de características del HTC Diamond:
Fecha de publicación: 2008/10/07
Se puede realizar mediante esta sencilla función:
function averiguaUrl() {
$protocolo = $_SERVER['HTTPS'] == 'on' ? 'https' : 'http'; // Se extrae el protocolo (http o https)
return $protocolo.'://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; // Se devuelve la URL completa
}
Visto en PHP Tutorials Examples: Get Full URL.
Fecha de publicación: 2008/10/06
En algunas ocasiones al crear un comportamiento Javascript se necesita, por accesibilidad, que haya un contenido alternativo en el caso de tener Javascript deshabilitado.
Esto puede conseguirse mediante la etiqueta NOSCRIPT. Aunque tiene un inconveniente. Supongamos un navegador que tiene Javascript activado pero no soporta el Javascript que se ha creado. No obtendrá ni el contenido resultante de ejecutar el Javascript ni el contenido de la etiqueta NOSCRIPT.
¿No sería mejor que el HTML tenga de inicio el contenido que va en NOSCRIPT y que mediante Javascript ese contenido se elimine al cargar la página en el caso de que el navegador sea compatible con el Javascript realizado?
Idea sacada de Replacing <noscript> with accessible, unobtrusive DOM/JavaScript
Fecha de publicación: 2008/10/02
Parece que proximamente va a aparecer una nueva versión de Internet Explorer para Windows Mobile 6.1, incluyendo como principal novedad el poder mostrar las páginas como si se estuviesen viendo en una pantalla grande con un navegador normal, y hacer zoom en la parte que se quiera visualizar (Igual que Safari para Iphone, Opera 9.5 para Windows Mobile o la última versión de Opera Mini).
La pega es que ese nuevo navegador está basado en el exitoso Internet Explorer 6 (si, ese que soporta tan maravillosamente los estándares web). Aun así es un avance, ya que la versión actual está basada en Internet Explorer 4.
Dicen que soportará Flash. Solo así podrá superar en algo a Opera 9.5 Mobile.