Tecnologías Web.
Las tecnologías Web sirven para acceder a los recursos de conocimiento disponibles en Internet o en las intranets utilizando un navegador. Están muy extendidas por muchas razones: facilitan el desarrollo de sistemas de Gestión del Conocimiento (en lo adelante GC), su flexibilidad en términos de escalabilidad, es decir, a la hora de expandir el sistema; su sencillez de uso y que imitan la forma de relacionarse de las personas, al poner a disposición de todos el conocimiento de los demás, por encima de jerarquías, barreras formales u otras cuestiones. Estas tecnologías pueden llegar a proporcionar recursos estratégicos, pero, evidentemente, no por la tecnología en sí misma, que está disponible ampliamente, sino por lo fácil que es personalizarla y construir con ella sistemas de GC propietarios de la empresa.
Internet, Intranet o extranet permiten a los usuarios el acceso a una gran cantidad de información: leer publicaciones periódicas, buscar referencias en bibliotecas, realizar paseos virtuales por museos, compras electrónicas y otras muchas funciones. Gracias a la forma en que está organizada la World Wide Web (WWW), los usuarios pueden saltar de un recurso a otro con facilidad.
Dentro de este grupo de tecnologías Web, podemos incluir los agentes inteligentes, el chat, los motores de búsqueda, los navegadores y las tecnologías push.
TEMARIO
UNIDAD 1: HTM5 Y CSS3
1.1 Estándares web renovados
1.2 Estándares W3C
1.3 Marcado HTML
1.4 Los estilos CSS
1.4.1 Color y degrade
1.4.2 Bordes, sombras y fondos
1.4.3 Tipografías
1.5 Programación en JavaScript.
1.6 Diseño web adaptable para celulares y tabletas.
1.1 ESTÁNDARES WEB RENOVADOS.
La Web cambió.
Para la mayoría de los diseñadores web es bastante reciente el momento en que cambiamos nuestra metodología de trabajo, dejamos de maquetar nuestros sitios con tablas, visualmente, y pasamos a utilizar posicionamiento CSS (¡y algunos ni siquiera transitaron ese camino aún!). pero como si esto fuera poco, ahora estamos frente a un desafío todavía mayor: hacer que nuestros sitios se adapten dinámicamente su layout para que puedan ser navegados sin problemas desde tabletas y smartphones.
el contexto del diseño web cambió, ya no se trata, como hace una década, de diseñar para pantallas de 800 por 600, o como hasta hace un par de años, de pensar en una resolución de 1024 por 768 píxeles. En realidad, nunca más podremos saber con exactitud para cuál resolución de pantalla estamos diseñando. La nueva web es flexible. Muy flexible. Nuestra páginas web pueden visualizarse en una pantalla mínima pongamos de ejemplo, la de un celular de 240 por 320 píxeles. hasta.. ¿quién se anima a poner el limite máximo?¿Por ahora serán unos casi 4000 por más de 2000 píxeles? Seguramente, en el tiempo transcurrido entre le momento de escribir éstas líneas y el de su lectura, esa medida ya habrá sido superada, alejándonos cada día más de esa antigua ilusión de pretender un diseño "fijo" uniforme para todos los dispositivos y navegadores, una idealización heredada del diseño gráfico para papel, pero claro: ¡los papeles vienen una sola resolución!
El concepto de diseño para la web debe cambiar. Ya no puede seguir primando el que hemos heredado del diseño gráfico, basado en un medio estático como el papel. La clave está en pensar al diseño web como la creación de experiencias para el usuario, y no más como un diseño rígido, visualmente uniforme, ni como un lienzo artístico.
Algo es diseño si es funcional a una meta: el diseño no es arte. De modo que la pregunta para evaluar un diseño si es funcional a una meta: el diseño no es arte. De modo que la pregunta para evaluar un diseño web ya no es "si se ve idéntico" en todos los navegadores y dispositivos, sino que debería ser: "¿puedo hacer las tareas requeridas por este sitio, con cualquier dispositivo, con cualquier navegador y versión?". Si puedo responder afirmativamente a esta pregunta, el diseño logró su objetivo, Si no, ha fracasado. Es hora de aceptar la flexibilidad de la web, y cambiar nuestras expectativas de diseño ( y las de nuestro clientes y jefes), para no seguir condenando al fracaso a todos nuestro proyectos.
En este nuevo contexto flexible, es inevitable que nos encontremos explicando a nuestro clientes que sus sitios se verán de diferentes maneras en algunos dispositivos. Intentaremos hacerles comprender que eso es inevitable y que no tiene nada de malo. Posiblemente, ellos ya lo hayan experimentando al intentar navegar la web de su empresa desde su nuevo celular. Esta diversidad de dispositivos, es la que nos abrirá las puertas para considerar la diversidad incluso entre navegadores (algo impensado un par de años atrás, cuando se seguían creando trucos para que las webs no se desarmen en Explorer 6). Los celulares han abierto las puertas de la diversidad para siempre.
En este contexto, es bueno recordar que HTML5 y CSS3 ya están aquí, vinieron par a quedarse, y vinieron con respecto a HTML5 y CSS3 es si ya se pueden usar aunque determinada funcionalidad en tal versión de Explorer no sea soportada nativamente Si la pregunta es planteada con esa sencillez, nuestra respuesta, con igual sencillez será afirmativa: sí, se pueden usar HTML5 y CSS3 hoy mismo. Pero eso no es lo más importante.
El punto clave es "cómo" usar HTML5 y CSS3 hoy. Mientras que la gran mayoría de tutoriales y libros -por no decir todos- se limitan a enunciar las novedades con un ejemplo simple que funciona en apenas la mitad de los escenarios (o menos), nosotros nos enfocamos en lograr compatibilidad en la mayor cantidad de escenarios que sea posible. De modo que la respuesta en versión no tan abreviada, sería que se pueden usar HTML5 y CSS3 hoy, pero aplicando técnicas de compatibilidad que nos permitan obtener buenos resultados (similares, o al menos predecibles) en los navegadores "antiguos" que aún utilizan nuestros usuarios.
La clave para poder aplicar HTML5 y CSS3 pasa por conocer y dominar algunos enfoque de compatibilización tales como:
- Mejora progresiva (progressive enhancement),
- Degradación elegante (graceful degradation) y
- Mejora regresiva (regressive enhancement).
Alfabetización web: ¡a leer y a escribir código!
_____________________________________________________________________
Desde el punto de vista del proceso o metodología de diseño web que emplearemos, el diseño principal que plantean HTML5 y CSS3 para la mayoría de los diseñadores web principiantes es el de profundizar su capacidad de entender (leer) y generar (escribir) las etiquetas HTML y el código CSS que los editores visuales usualmente escriben por ellos, manteniéndolos apartados de los lenguajes con los que está construida toda Web.
La meta es animarse a escribir códigos simples, como por ejemplo: <section></section> o <nav></nav> envolviendo algún bloque de una página web previamente creada. Después de todo, si de alguna manera pudimos aprender HTML4 y CSS2.1, ¿Por qué no vamos a aprender ahora HTML5 y CSS3?
Cualquier editor sirve para escribir en lenguaje HTML y en cSS, solo que algunos nos permiten se más rápidos, precisos y productivos, gracias al autocompletado de etiquetas y atributos.
Una evolución revolucionaria
En la década de 1970, cuando la empresa que dominaba el mercado del software era IBM ( no: ¡aún no existía Microsoft!), la gente de IBM se enfrentaba a un grave problema, que era la dificultad para compartir información entre distintas oficinas de la misma empresa (muchísimas oficinas por todo el mundo, y no: ¡tampoco existía Internet!).
En esa época, no había archivos de formatos estandarizados, y cada programador generaba los suyos propios, generalmente de texto plano, con sus propias "claves". Para graficar lo anterior, imaginemos que en una oficina un código "t" antes de una frase podía significar que ese texto era un "titulo", pero para otra oficina eso significaba que era un "tabulador", con los malos entendidos que nos podemos imaginar. Esto provocaba serias dificultades y pérdidas de tiempo para reutilizar esa información ya almacenada en otra sección de la empresa, que debía reconstruir y readaptar el archivo a su propia forma de almacenamiento y procesamiento de datos. El problema era la incompatibilidad.
En vista de esto, IBM decidió crear un lenguaje que permitiera estructurar el contenido de los documentos que producía, mediante el agregado de etiquetas o marcas (tags), que envolvieran al texto y describieran qué importancia y función tenía el mismo dentro de un documento. De esta manera indicaban que tal frase era el "titulo", tal otra el "subtitulo", otra un simple párrafo y así sucesivamente. Tenían la esperanza de que, si todos usaban ese nuevo lenguaje, se solucionaría el problema de la incompatibilidad.
Este lenguaje de marcas fue llamado GML (Generalized Markup Language) y funcionó a la perfección, logrando establecer un "idioma común" para que todas las oficinas de IBM pudieran compartir su información rápidamente y sin conversiones.
Pero pasado un tiempo notaron que el problema persistía cuando los proveedores (clientes) de IBM introducían datos desde el "mundo exterior", ya que no los estructuraban con GML.
Entonces, decidieron realizar algunos cambios al lenguaje GML y liberar para uso público este lenguaje de marcas: lo ofrecieron a una oficina de estándares (ISO) y así nación SGML (Standard Generalized Markup Language), un lenguaje estándar, público, que en los años 80 tuvo gran difusión en la informática mundial.
¿Y esto que relación tiene con las páginas web? ¡Muchísima!
Cuando a fines de los años 80 un grupo de investigadores del CERN, entre los cuales estaba Vinton Cerf, tuvo que decidir cuál sería el tipo de documento que se utilizaría en ese nuevo servicio de navegación hipertextual al que llamaron World Wide Web, enseguida pensaron en SGML, puesto que varios de ellos ya lo conocían por que habían trabajado para ibM y podían dar fe de sus ventajas a la hora de intercambiar información. Ventajas de compatibilidad...
Quienes tomaron la decisión bien podrían haber decidido que el formato de los documentos a usar en la web fuera TXT, o bien el DAT o el EXE. Sin embargo, prefirieron las conocidas ventajas de un lenguaje de marcado estandarizado, con etiquetas (tags) como era SGML.
Lenguaje HTML
A partir de esa decisión, crearon el lenguaje HTML (Hyper Text Markup Language), que no es más que un derivado de SGML, y lo crearon con el objetivo de estructurar el contenido de los documentos que se publicarían en la web.
La relativa complejidad de este lenguaje hizo que fueran los programadores (la gente del área de Sistemas de las empresas) quienes crearan las primeras páginas web de la historia (¡feísimas, por supuesto!, pero no era estética la necesidad de ese momento, con las conexiones dial-up muy lentas de que disponíamos).
Más a delante, al sucederse nuevas versiones del lenguaje HTML, se fueron incorporando nuevas etiquetas, que permitían decorar (dar formato, estilo, colores, alineación, etc.) al texto y demás elementos de las páginas web. En ese momento hicieron su entrada en escena dos actores principales de los que sería la web hasta nuestro días: los diseñadores gráficos, y los programas de edición visual de documentos HTML (FrontPage y programas similares). Esto sucedía alrededor del año 2000.
La preocupación inicial de la gente de sistemas por lograr documentos claramente estructurados, cedió paso a la preocupación estética, de acomodar en la pantalla los bloques de información, la como si estuviésemos ante una página rígida de papel, e medio previamente conocido por lo diseñadores gráficos. La información muchas veces terminó escondida por la presentación, el contenido dejó de importar detrás de la apariencia, todos los clientes pedían animaciones, efectos especiales, funcionalidades extras posibles "en un solo navegador" y otros caprichos conocidos por todos los que hacemos sitios web desde hace más de 10 años.
Así es que se usó y abusó de las tablas para maquetar documentos web, y de etiquetas dedicadas a la estética tales como <font>, <center> y muchas otras, que llevaron al callejón sin salida del re-diseño. En el momento de tener que re-decorar un sitio web, era preciso reconstruir su código HTML desde el principio, copiando y pegando cada párrafo (a veces, palabra por palabra y has ¡letra por letra!) del documento viejo en uno nuevo, dando más trabajo rediseñar algo que en diseñarlo desde cero.
Para solucionar esto, se decidió separar funciones estructurales, decorativas y funcionales en lenguajes diferentes: XHTML, CSS y JavaScript, respectivamente. El lenguaje HTML ya no siguió adelante, y de hecho la última versión (4.01) pasó cerca de 10 años sin actualizarse hasta la versión 5, de la que hablaremos luego. En su lugar se reformuló el lenguaje HTML intentando que implemente reglas propias de otro estándar, el lenguaje XML, fijando su objetivo en lo que fue originalmente y nunca debió haber abandonado: la estructuración jerárquica del contenido de un documento web.
Ese conjunto de reglas y etiquetas llamado XHTML fue durante los últimos años el tipo de marcado más utilizado, el que generaban automáticamente los bueno editores cuando marcábamos contenidos para la web. La idea era marcar "qué era" cada bloque de contenido (una lista, un encabezado, una cita, etc.).
Sustantivos...
Por otro lado, para el costado estético de los documentos web, se recurrió a otro lenguaje, el CSS (Cascading Style Sheet, Hojas de Estilo en Cascada). De esta forma no fueron necesarias más tablas, ni más mezclas de contenido y formato que impidieran los rediseños. Además, parecía haberse abandonado el lenguaje HTML. La solución parecía ser el código XHTML para estructurar la información, y CSS para decorarla. CSS indicaba "cómo era" cada elemento, cómo se presentaría.
Adjetivos...
Y JavaScript agregaría comportamientos, reacciones ante eventos. funcionalidades: "qué hace" cada elemento, cómo funciona.
Verbos...
Podemos sintetizar los roles de cada uno de los 3 principales lenguajes de la web asimilándolos a las funciones dentro de una gramática, según a que pregunta responden:
HTML | Sustantivo | ¿Qué es esto?
CSS | Adjetivo | ¿Cómo es esto?
JavaScript | Verbo | ¿Qué hace esto?
Información obtenida de: BEATI - HTML5 y CSS3 PARA DISEÑADORES Editorial ALFAOMEGA
Una evolución revolucionaria
_____________________________________________________________________
En la década de 1970, cuando la empresa que dominaba el mercado del software era IBM ( no: ¡aún no existía Microsoft!), la gente de IBM se enfrentaba a un grave problema, que era la dificultad para compartir información entre distintas oficinas de la misma empresa (muchísimas oficinas por todo el mundo, y no: ¡tampoco existía Internet!).
En esa época, no había archivos de formatos estandarizados, y cada programador generaba los suyos propios, generalmente de texto plano, con sus propias "claves". Para graficar lo anterior, imaginemos que en una oficina un código "t" antes de una frase podía significar que ese texto era un "titulo", pero para otra oficina eso significaba que era un "tabulador", con los malos entendidos que nos podemos imaginar. Esto provocaba serias dificultades y pérdidas de tiempo para reutilizar esa información ya almacenada en otra sección de la empresa, que debía reconstruir y readaptar el archivo a su propia forma de almacenamiento y procesamiento de datos. El problema era la incompatibilidad.
En vista de esto, IBM decidió crear un lenguaje que permitiera estructurar el contenido de los documentos que producía, mediante el agregado de etiquetas o marcas (tags), que envolvieran al texto y describieran qué importancia y función tenía el mismo dentro de un documento. De esta manera indicaban que tal frase era el "titulo", tal otra el "subtitulo", otra un simple párrafo y así sucesivamente. Tenían la esperanza de que, si todos usaban ese nuevo lenguaje, se solucionaría el problema de la incompatibilidad.
Este lenguaje de marcas fue llamado GML (Generalized Markup Language) y funcionó a la perfección, logrando establecer un "idioma común" para que todas las oficinas de IBM pudieran compartir su información rápidamente y sin conversiones.
Pero pasado un tiempo notaron que el problema persistía cuando los proveedores (clientes) de IBM introducían datos desde el "mundo exterior", ya que no los estructuraban con GML.
Entonces, decidieron realizar algunos cambios al lenguaje GML y liberar para uso público este lenguaje de marcas: lo ofrecieron a una oficina de estándares (ISO) y así nación SGML (Standard Generalized Markup Language), un lenguaje estándar, público, que en los años 80 tuvo gran difusión en la informática mundial.
¿Y esto que relación tiene con las páginas web? ¡Muchísima!
Cuando a fines de los años 80 un grupo de investigadores del CERN, entre los cuales estaba Vinton Cerf, tuvo que decidir cuál sería el tipo de documento que se utilizaría en ese nuevo servicio de navegación hipertextual al que llamaron World Wide Web, enseguida pensaron en SGML, puesto que varios de ellos ya lo conocían por que habían trabajado para ibM y podían dar fe de sus ventajas a la hora de intercambiar información. Ventajas de compatibilidad...
Quienes tomaron la decisión bien podrían haber decidido que el formato de los documentos a usar en la web fuera TXT, o bien el DAT o el EXE. Sin embargo, prefirieron las conocidas ventajas de un lenguaje de marcado estandarizado, con etiquetas (tags) como era SGML.
Lenguaje HTML
A partir de esa decisión, crearon el lenguaje HTML (Hyper Text Markup Language), que no es más que un derivado de SGML, y lo crearon con el objetivo de estructurar el contenido de los documentos que se publicarían en la web.
La relativa complejidad de este lenguaje hizo que fueran los programadores (la gente del área de Sistemas de las empresas) quienes crearan las primeras páginas web de la historia (¡feísimas, por supuesto!, pero no era estética la necesidad de ese momento, con las conexiones dial-up muy lentas de que disponíamos).
Más a delante, al sucederse nuevas versiones del lenguaje HTML, se fueron incorporando nuevas etiquetas, que permitían decorar (dar formato, estilo, colores, alineación, etc.) al texto y demás elementos de las páginas web. En ese momento hicieron su entrada en escena dos actores principales de los que sería la web hasta nuestro días: los diseñadores gráficos, y los programas de edición visual de documentos HTML (FrontPage y programas similares). Esto sucedía alrededor del año 2000.
La preocupación inicial de la gente de sistemas por lograr documentos claramente estructurados, cedió paso a la preocupación estética, de acomodar en la pantalla los bloques de información, la como si estuviésemos ante una página rígida de papel, e medio previamente conocido por lo diseñadores gráficos. La información muchas veces terminó escondida por la presentación, el contenido dejó de importar detrás de la apariencia, todos los clientes pedían animaciones, efectos especiales, funcionalidades extras posibles "en un solo navegador" y otros caprichos conocidos por todos los que hacemos sitios web desde hace más de 10 años.
Así es que se usó y abusó de las tablas para maquetar documentos web, y de etiquetas dedicadas a la estética tales como <font>, <center> y muchas otras, que llevaron al callejón sin salida del re-diseño. En el momento de tener que re-decorar un sitio web, era preciso reconstruir su código HTML desde el principio, copiando y pegando cada párrafo (a veces, palabra por palabra y has ¡letra por letra!) del documento viejo en uno nuevo, dando más trabajo rediseñar algo que en diseñarlo desde cero.
Para solucionar esto, se decidió separar funciones estructurales, decorativas y funcionales en lenguajes diferentes: XHTML, CSS y JavaScript, respectivamente. El lenguaje HTML ya no siguió adelante, y de hecho la última versión (4.01) pasó cerca de 10 años sin actualizarse hasta la versión 5, de la que hablaremos luego. En su lugar se reformuló el lenguaje HTML intentando que implemente reglas propias de otro estándar, el lenguaje XML, fijando su objetivo en lo que fue originalmente y nunca debió haber abandonado: la estructuración jerárquica del contenido de un documento web.
Ese conjunto de reglas y etiquetas llamado XHTML fue durante los últimos años el tipo de marcado más utilizado, el que generaban automáticamente los bueno editores cuando marcábamos contenidos para la web. La idea era marcar "qué era" cada bloque de contenido (una lista, un encabezado, una cita, etc.).
Sustantivos...
Por otro lado, para el costado estético de los documentos web, se recurrió a otro lenguaje, el CSS (Cascading Style Sheet, Hojas de Estilo en Cascada). De esta forma no fueron necesarias más tablas, ni más mezclas de contenido y formato que impidieran los rediseños. Además, parecía haberse abandonado el lenguaje HTML. La solución parecía ser el código XHTML para estructurar la información, y CSS para decorarla. CSS indicaba "cómo era" cada elemento, cómo se presentaría.
Adjetivos...
Y JavaScript agregaría comportamientos, reacciones ante eventos. funcionalidades: "qué hace" cada elemento, cómo funciona.
Verbos...
Podemos sintetizar los roles de cada uno de los 3 principales lenguajes de la web asimilándolos a las funciones dentro de una gramática, según a que pregunta responden:
HTML | Sustantivo | ¿Qué es esto?
CSS | Adjetivo | ¿Cómo es esto?
JavaScript | Verbo | ¿Qué hace esto?
Información obtenida de: BEATI - HTML5 y CSS3 PARA DISEÑADORES Editorial ALFAOMEGA
