Mostrando entradas con la etiqueta Estándares web. Mostrar todas las entradas
Mostrando entradas con la etiqueta Estándares web. Mostrar todas las entradas

sábado, 13 de junio de 2009

XHTML(ii)

Siguiendo con nuestra introducción al mundo XHTML, veremos hoy un elemento importante e imprescindible en el mundo del hipertexto; los hiperenlaces.

Los hiperenlaces conviven con nuestros documentos en la red desde sus inicios ya que son parte fundamental de su finalidad: enlazar recursos en la red; páginas, documentos, archivos, etc.

Antes de intentar comprender la esructura formal de los enlaces en la web, debemos entender el concepto URL (identificador único de recurso).

Una URL digamos que es la clave única en la red para acceder a un recurso, como por ejemplo una imagen alojada en nuestro servidor.

Está compuesta por tres partes:

  • Protocolo. Normalmente http://, o https:// para los entornos seguros, o ftp://, etc.
  • Servidor. Nombre de dominio o ip pública del servidor que sirve el recurso, como por ejemplo velneo.es
  • Ruta. Ruta interna al servidor que lleva hasta el recurso compartido y servido, como por ejemplo /cgi-vel/alias-aplicacion/imagen.jpg para un archivo imagen.jpg dentro de la carpeta raiz de la aplicación con ese alias servida por un vServer.

Existen dos tipos de url: absoluta y relativa.

Una url absoluta contiene las tres partes comentadas; protocolo, servidor y ruta.

Una url relativa prescinde de alguna de las partes anteriores. Por ejemplo, si ya estamos en el documento http://midominio.com/cgi-vel/alias-aplicacion/index.pro, para acceder al proceso portada.pro de la misma aplicación, la url podría ser simplemente portada.pro en lugar de http://midominio.com/cgi-vel/alias-aplicacion/portada.pro

Xhtml define toda una serie de reglas para acceder por ruta relativa a recusos compartidos: si el origen del enlace y el destino se encuentran en el mismo directorio, si el destino se encuentra en el nivel superior, en un nivel inferior, muy lejos, etc, pero como nosotros trabajamos en Velneo, nuestras páginas web siempre van a tener una ruta relativa: proceso-destino.pro, ya que nuestras páginas xhtml siempre las vamos a componer por proceso.

Veamos pues como es un elemento enlace.

ENLACE (<a></a>)

Un enlace es un elemento en línea y dispone de los siguientes atributos, entre otros:

  • name, para poder referirnos a un enlace por su nombre único.
  • href, para indicar la url del recurso enlazado.
  • type, para indicar al navegador sobre el tipo de elemento enlazado; imagen (image/gif), documento (text/css o application/rss+xml), etc.
  • rel, para indicar la relación entre el documento actual y el enlazado, muy útil a la hora de indicar a Google si debe seguir e indexar el contenido enlazado o no.
  • hreflang, para indicar el idioma del recurso enlazado (es-ES para español de españa, o es-AR para español de Argentina, por ejemplo).
  • charset, para la codificación del recurso enlazado (utf-8 o iso-8859-1, por ejemplo).

Veamos algunas aplicaciones de estos atributos.

El atributo name se suele utilizar para lo que se conoce como "anclas" o "anchors".

Si tenemos un enlace del tipo <a name="punto1"></a> dentro de un documento podemos generar un enlace a él de la siguiente forma <a href="#punto1"></a>, como por ejemplo para acceder desde una tabla de contenidos al principio de una página "larga" hasta el Punto 1 dentro de la misma página.

Si el origen del enlace está en la página index.pro, por ejemplo, y el destino está en la página faq.pro en el ancla con name="faq1", el enlace sería <a href="faq.pro#faq1"></a>.

El atributo rel se suele utilizar por ejemplo para decirle al robot de Google si debe seguir un enlace e indexar el contenido del documento enlazado, cuestión muy importante en el trabajo SEO de una web.

Si indicamos el atributo rel="noindex, nofollow", le estamos diciendo al robot de Google que no siga el enlace y que no indexe el contenido del documento enlazado, tema muy interesante si no queremos que páginas "inútiles" como el contactar o condiciones de servicio resten importancia al resto de páginas de nuestra web con contenidos frescos e interesantes que sí queremos que Google indexe.

Dentro de la cabecera de nuestro documento encontraremos unos tipos de enlaces especiales como por ejemplo:

  • <link rel="stylesheet" type="text/css" href="/css/estilo.css" />, para hacer referencia a la hoja de estilos css que se utiliza para renderizar el documento xhtml
  • <link rel="shortcut icon" href="/favicon.ico" type="image/ico" />, para hacer referencia al icono de nuestra página web que se mostrará en la barra de direcciones del navegador web o en el enlace al ser añadido a favoritos.
  • <link rel="alternate" type="application/rss+xml" title="Canal RSS" href="/feed.xml" />, para hacer referencia al documento xml donde publicamos periodicamente las actualizaciones de nuestra web.
  • <script type="text/javascript" src="/js/javascript.js"></script>, para hacer referencia al archivo que contiene la definición de las funciones javascript que usaremos en nuestro documento.

Me gustaría comentar un par de tipos de enlace cuyo uso está desaconsejado:

  • Los enlaces <a href="mailto:cuenta@dominio.com">correo</a>, que abren el programa asociado en el equipo al envío de correo electrónico y componen un nuevo correo indicando en el Para, la dirección indicada. Su uso está desaconsejado debido al mal uso de la web de robots malintencionados que recolectan emails que aparecen en webs y los inundan de spam, y más desaconsejado está el intento de incluir el Asunto del mensaje o parte del contenido, pasando los parámetros subject o body en el enlace, ya que esto es una violación de seguridad.
  • Los enlaces por javascript. Un enlace sin destino y con un comportamiento onclick que abra una url no es un enlace. Un usuario normal puede tener dificultades para seguirlo, y no digamos un usuario ciego como Google que no ve el javascript asociado ni el enlace compuesto en la función.

Y hoy hasta aquí. En la próxima entrega seguiremos con las Listas, un elemento muy, muy, muy útil para menús de navegación usando un poco de css.

Hasta entonces,

Life is soft!

sábado, 9 de mayo de 2009

Estándares web

Mis inicios como desarrollador web fueron bastante penosos: terminaba mis estudios de ingeniería en la universidad, vivía entre casa de mis padres y el piso compartido de estudiantes de mi novia y sus compañeras, y curraba en una "empresa" haciendo lo necesario; Photoshop, 3dStudio, Premier, AutoCad...

La "empresa" se llamaba Valenciana de Servicios Completos. Os podéis imaginar que hacíamos prácticamente cualquier cosa que se pudiera vender (no penséis mal, no tan completos...).

Así que cuando mi jefe me dijo: "Ahora vas a hacer webs. Aquí tienes un libro (era algo así como html para torpes) y aquí el programa para hacerlas (FrontPage). Al tajo!", pues me puse a ello.

Por cómo me habían modelado el cerebro en la universidad, cabezón y cuadriculado, la forma de hacer webs de la herramienta me venía al pelo: tablas para la maquetación, tablas para texto, tablas para imágenes, para espacios en blanco, para contener botones y menús, para contener tablas que a su vez contenían más tablas...

Usando esa táctica constructiva desarrollé muchísimas webs durante muchos años, y cobraba por ello.

A lo largo de esos años intenté formarme continuamente; hice cursos de Flash, de DreamWeaver, de ASP, y básicamente me autoformé leyendo sin cesar libros y páginas y más páginas en internet sobre el tema web (aún no existían los blogs!!!).

Al principio las webs eran poco más que texto e imágenes gif, luego la cosa se fue complicando con javascript, actionscript, frames, sonido, animaciones, vídeo, etc, y a la vez crecían en tamaño y complejidad.

Por entonces ya sentía que algo no andaba bien, ya que trabajar en webs grandes utilizando plantillas de página que se repetían en cada página no me parecía una forma eficiente de realizar el trabajo, y menos de mantenerlo, ya que cada cambio de diseño implicaba recorrer todas y cada una de las páginas para aplicarlo. Las plantillas no eran dinámicas.

El descubrir DreamWeaver MX que podía conectar la web a una base de datos supuso un gran avance en este aspecto, ya que con una página base podía mostrar infinitas páginas tirando de tablas de la bd.

Por aquel entonces empecé a conocer algo que llamaban CSS y básicamente servía para definir tipos de letra, tamaños y colores en un archivo único externo que permitía mantener esos aspectos de forma muy cómoda, pero eso sólo era la cáscara superficial.

El día que descubrí el modelo de cajas y el posicionamiento por CSS cambió mi vida: eso era!. Mi sentimiento inicial había encontrado la respuesta definitiva.

Lo tenía todo:
  • una base de datos para proporcionarme los contenidos
  • una forma de estructurar esos contenidos (html)
  • una forma de mostrarlos (el css)

Ahora sólo faltaba comprender y dominar el css, la herramienta definitiva.

Desde entonces llevo estudiando todos y cada uno de los días css sin parar.

Qué tiene que ver esto con los estándares web? Creo que bastante.

Los estándares web los dictan una comisiones de expertos del World Wide Web Consortium (W3C), y cuando digo expertos quiero decir expertos: son los autores originales de la web y sus alumnos aventajados, la gente que inventó y diseñó los protocolos de comunicaciones de redes, la gente que inventó internet, los lenguajes que organizan la información en la web.

Ellos estudian y dicen (recomiendan) cómo es y cómo será la web, dicen cómo hay que construir los navegadores de internet para que puedan leer e interpretar correctamente la información que se transmite por la red.

Crean estándares que todos deberíamos utilizar y respetar: tú, yo, el vecino, Internet Explorer, Firefox, Opera...

Lo que al principio son recomendaciones, terminan siendo al final estándares que aplican los desarrolladores de software para internet, y si desarrollas webs sería muy interesante conocer esas recomendaciones y aplicarlas para que así tus contenidos web puedan ser mostrados en la mayoría de navegadores web y llegar a más y más gente.

El aplicar estándares al desarrollo web tiene muchas ventajas, la primera es la eficiencia: los estándares recomiendan separar el contenido (html) de la forma (css) y los comportamientos (javascript), y el tener organizadas de esta forma las cosas te permitirá reutilizar mucho código, y así aumentar tu eficiencia.

La segunda ventaja es la facilidad de mantenimiento. Teniendo así separadas las cosas es muy fácil hacer un cambio global en toda la web tocando sólo el css o la estructura html.

La tercera gran ventaja es la compatibilidad con diferentes dispositivos. Usando estándares es mucho más fácil hacer que mi web sea accesible a diferentes navegadores en diferentes sistemas operativos y diferentes dispositivos; pc's, teléfonos móviles, pda's, etc.

La cuarta ventaja yo la consideraría casi como una verdadera obligación por parte de todos y cada uno de nosotros: accesibilidad.

La Constitución Española no lo dice así pero casi: nadie será discriminado por su condición. Así que no hacer una web accesible a todos debería ser casi considerado como un ejercicio de irresponsabilidad democrática.

Hay gente que no puede dominar un ratón, así que porqué no facilitarle la navegación a través del teclado? Hay gente con dificultades visuales, así que porqué no proporcionar contenido alternativo textual que explique las imágenes, las tablas, los menús? Hay gente que no puede ver tu web y usa lectores de voz para ello, así que porqué no facilitarles el acceso a tus contenidos?

Hay gente que navega sin javascript activado, sin poder reproducir flash, sin css. Piensa en los teléfonos móviles.

Decirle a un usuario "Este sitio usa frames y tu navegador no los soporta" o "Este sitio está diseñado para 1024x768" es casi como decirle a alguien "Lo siento, con silla de ruedas no pasas".

Si todo esto no te convence, seguro que hay un usuario ciego al que no le quieres negar la entrada a tu sitio web: Google.

Piensa en cómo "ve" Google tu sitio y te darás cuenta de que es ciego. No quieres hacer tus contenidos accesibles a Google? Seguro que sí. Pues los estándares web nos ayudan a hacer nuestros sitios accesibles a más usuarios.

La última ventaja de usar estándares es que es mucho más fácil aplicar técnicas SEO (optimización para motores de búsqueda) a nuestros sitios con todas las ventajas que ello conlleva.

A pesar de todas estas ventajas habrá gente que quiera argumentar:

  • No tengo medios. Falso! En internet hay miles de sitios ofreciendo recursos formativos gratuitos de la mejor calidad.
  • Es por la política de empresa. Mal vamos si la empresa no quiere llegar a cada vez más usuarios.
  • No lo necesito, sigo haciendo las cosas como siempre y me siguen pagando. No quieres ser más eficiente? No quieres facilitarte el mantenimiento de tus sitios web? No quieres ganar lo mismo en menos tiempo? No quieres ganar más en el mismo tiempo? Afortunadamente ya hay muchas empresas buscando desarrolladores web formados en estándares. Te quieres cerrar las puertas?
  • Los navegadores web no soportan los estándares. Ese tiempo ya pasó. Afortunadamente todos los navegadores soportan cada vez en mayor medida los estándares.

Llegados a este punto espero haber conseguido explicar la importancia de los estándares, su uso y ventajas, y espero haber despertado ese gusanillo en vosotros para que empecéis a aprender y aplicar estándares web en vuestros desarrollos.

Un saludo,

lunes, 1 de diciembre de 2008

XHTML (i)

Antes de intentar cosas complejas en el entorno web deberíamos preocuparnos de entender mínimamente las bases del lenguaje que vamos a utilizar para desarrollar documentos web, así que vamos a comenzar por entender el XHTML y sus peculiaridades.

La primera duda que nos puede surgir al intentar desarrollar algo en web es; "HTML o XHTML?"

Veamos las diferencias.

Tanto uno como otro surgen del SGML; HTML es "hijo" de SGML y XHTML es "nieto" de SGML, ya que su "padre" es XML, este sí, descendiente directo de SGML.

Vemos entonces que son de la misma familia, pero que cada uno pertenece a una rama diferente y por tanto tiene sus características y peculiaridades diferentes y específicas.

Ambos son lenguajes de "etiquetas" (tags) pero sus reglas no son las mismas; HTML es mucho más relajado en cuanto a normativa sintáctica y nos permite hacer cosas mal, pero XHTML hereda de su "padre" XML una cierta manía "formal" e impide hacer mal muchas cosas que HTML permite.

La principal diferencia entre ambos lenguajes es la siguiente; XHTML separa el contenido de la forma y HTML no lo hace.

En XHTML definimos los contenidos, la forma se la dará el CSS aplicado, mientras que en HTML la forma y el contenido están mezcladas de forma confusa e inconsistente.

Esta es la principal característica que nos hará decidirnos por un lenguaje u otro; necesito generar contenidos dinámicos independientes de la forma, o me da igual?

HTML incluye entre sus etiquetas muchas destinadas a dar forma a sus contenidos; fuente, tamaño, negrita, cursiva, etc.

XHTML sustituye esas etiquetas por otras destinadas a dar sentido a sus contenidos; titular, subtitular, destacado, etc.

Es una aproximación muy diferente: en el caso del XHTML decimos si un contenido es un titular, subtitular, cuerpo normal, si debe ser destacado, etc, mientras que en HTML estamos diciendo que ese contenido va en fuente Arial Negrita de 14, en Cursiva, etc. Es muy diferente.

Al diseñar en HTML estamos mezclando conceptos; los contenidos y su representación, mientras que al diseñar en XHTML dividimos el problema en dos partes muy diferenciadas, por una parte definimos los contenidos y su significado, y por otra parte definimos su representación (CSS).

Nosotros, como diseñadores de soluciones Velneo, contamos con la misma dicotomía en nuestro sistema; por una parte la bd (contenidos), y por otra la apariencia (objetos visuales), así que adoptaremos XHTML + CSS como nuestro modelo de desarrollo web.

Las etiquetas (tags) que vamos a poder utilizar son las siguientes:

a, abbr, acronym, address, applet, area, b, base, basefont, bdo, big, blockquote, body, br, button, caption, center, cite, code, col, colgroup, dd, del, dfn, dir, div, dl, dt, em, fieldset, font, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, hr, html, i, iframe, img, input, ins, isindex, kbd, label, legend, li, link, map, menu, meta, noframes, noscript, object, ol, optgroup, option, p, param, pre, q, s, samp, script, select, small, span, strike, strong, style, sub, sup, table, tbody, td, textarea, tfoot, th, thead, title, tr, tt, u, ul, var

Aparte de estas existen otras propias del HTML, ya obsoletas, y cuyo uso queda prohibido de ahora en adelante, y son:

applet, basefont, center, dir, font, isindex, menu, s, strike, u

No son muchas etiquetas, y su uso nos hará acostumbrarnos a todas y cada una de ellas hasta dominarlas completamente.

Veamos cuál va a ser nuestra unidad mínima de trabajo: el ELEMENTO.

Un elemento está compuesto por:

  • Una apertura de etiqueta
  • Ninguno o más atributos
  • Un texto
  • Un cierre de etiqueta

Ejemplo:

<p class="estandard">Texto del párrafo</p>

donde

  • <p> es la apertura de etiqueta
  • class="estandard" es un atributo
  • Texto del párrafo es el texto contenido entre la etiqueta de apertura y la de cierre
  • </p> es el cierre de etiqueta

Aquí quiero comentar unas diferencias muy notables entre HTML y XHTML:

  • en HTML estamos acostumbrados a abrir etiquetas, pero puede ser que no a cerrarlas. XHTML obliga a cerrar siempre una etiqueta que se abre.
  • en HTML puede ser que funcionen etiquetas mal anidadas (ej; <p><a href="www.loquesea.com">loquesea.com</p></a>), pero XHTML nos obliga a seguir un orden estricto a la hora de cerrar etiquetas; el mismo por el que se han abierto pero a la inversa, en nuestro ejemplo (<p><a href="www.loquesea.com">loquesea.com</a></p>).
  • tanto los descriptores de etiqueta como sus atributos como los nombres de los atributos van en minúsculas. Aquí vemos que el editor HTML de Velneo es eso, un editor HTML que no XHTML.
  • los valores de los atributos van entre comillas, no como en HTML.

Inciso. Si el editor HTML de Velneo no es ideal, cuál deberíamos usar?

  • Word NO. Word inserta una serie de etiquetas "basura" que fundamentalmente engordan nuestros documentos y lo hacen no compilante, ilegible e inservible.
  • Dreamweaver. Se puede usar con conocimiento de causa, es decir, debemos conocer XHTML y saber eliminar toda la basura que introduce el programa en nuestros documentos.
  • FrontPage NO. Hablamos de editores HTML, por favor...
  • Alguno gratuito. Lo mismo que con Dreamweaver, con conocimiento de causa y con la escoba preparada.

El editor ideal HTML es nuestro cerebro, nuestros conocimientos de XHTML y nuestras manitas, que junto con un editor de textos como por ejemplo el Bloc de notas de Windows, nos permitirán confeccionar documentos estructurados, compilantes, legibles, usables y corectos.


Una vez entendida la unidad mínima de trabajo, el ELEMENTO, veamos su clasificación.

Los elementos se clasifican en:

  • Elementos en línea (a, abbr, acronym, b, basefont, bdo, big, br, cite, code, dfn, em, font, i, img, input, kbd, label, q, s, samp, select, small, span, strike, strong, sub, sup, textarea, tt, u, var)
  • Elementos de bloque (address, blockquote, center, dir, div, dl, fieldset, form, h1, h2, h3, h4, h5, h6, hr, isindex, menu, noframes, nos-cript, ol, p, pre, table, ul, además de dd, dt, frame-set, li, tbody, td, tfoot, th, thead, tr)

Los elementos button, del, iframe, ins, map, object, script, pueden ser considerados tanto como en línea como de bloque dependiendo de las circunstancias.

Una vez vistos estos conceptos básicos pasemos a la parte fundamental: estructurar nuestros documentos.

Todos nuestros documentos tendrán siempre tres secciones básicas y fundamentales:

  • Inicio y fin de documento. Viene determinado por las etiquetas <html> y </html>. Irán siempre (salvo determinadas especificaciones que veremos más adelante) al principio y fin del documento.
  • Cabecera. Encerrada entre <head> y </head>. Aquí definiremos elementos como el Título del documento, metainformación sobre el documento, links a documentos css o javascript, etc.
  • Cuerpo. Encerrado entre <body> y </body>, que define el contenido de nuestro documento y supondrá entorno a un 90% de nuestro documento.

Como el 90% del trabajo lo tenemos en el cuerpo del documento veamos cómo MARCAR correctamente nuestros contenidos para darles sentido semántico.

PÁRRAFOS (<p></p>)

Un párrafo es, como hemos visto, un elemento de bloque y como tal ocupa por defecto la anchura disponible en la ventana del navegador.

No tiene atributos específicos pero se le pueden asignar toda una serie de atributos básicos, de internacionalización y de eventos.

Por similitud con un documento Word, diremos que un párrafo es aquello comprendido entre el inicio de una línea de texto y un "Intro".

Inciso. Word es quizás el editor de textos más utilizado del planeta y por ende el peor utilizado también. Cuando empezamos a escribir un texto con Word, tecleamos letras y espacios hasta llegar a un punto y aparte. Esto es un párrafo. Muchos usuarios introducen "Intros" adicionales para separar un párrafo del siguiente, pero esto no se hace así: hay una propiedad del documento llamada separación entre párrafos que se usa para tal fin. No hay que introducir "saltos de línea" o "párrafos en blanco" para separar párrafos, basta con definir la separación entre párrafos y Word ya sabe lo que tiene que hacer cuando pulsamos "Intro".

Un párrafo empieza por <p> y termina </p>.

TÍTULOS DE SECCIONES (<h1></h1>, <h2></h2>, <h3></h3>, <h4></h4>, <h5></h5> y <h6></h6>)

Es habitual que el contenido de nuestro documento se estructure a su vez en secciones de mayor o menor importancia. Para indicar los títulos de dichas secciones usaremos las etiquetas h, siendo h1 la de mayor importancia, reservada normalmente para el Título de la sección, h2 para el subtítulo, y así sucesivamente para subsecciones del documento de cada vez menor importancia dentro del mismo.

Cualquier navegador web interpreta de por sí estas etiquetas destacándolas del resto de texto del documento otorgándoles ciertas características de tamaño de fuente y negrita o cursiva.

También son elementos de bloque al igual que los párrafos.

Con estas dos simples etiquetas ya podemos estructurar nuestro contenido en secciones de mayor o menor importancia, y a su vez dividir el texto dentro de cada sección en párrafos. Básico pero fundamental.

Ahora veamos cómo marcar el texto dentro de cada párrafo o sección para indicar que va en negrita, cursiva, es una anotación, una corrección, una cita a otro documento, etc.

ÉNFASIS (<em></em>) y MÁS ÉNFASIS (<strong></strong>)

Son elementos en línea a diferencia de los dos anteriores y se utilizan para destacar un texto respecto del resto.

  • <em></em> indica que el texto encerrado tiene mayor importancia que el resto y los navegadores lo suelen representar en cursiva.
  • <strong></strong> indica que el texto encerrado es de la mayor importancia dentro del documento y los navegadores lo suelen representar en negrita.

Inciso. Elementos de bloque y elementos en línea. La principal diferencia entre unos y otros es cómo ocupan el espacio dentro del documento; los elementos de bloque provocan el salto de línea (empiezan en nueva línea) y ocupan el ancho disponible independientemente de su longitud, mientras que los elementos en línea no provocan salto de línea y ocupan el ancho necesario para mostrar su contenido.

MODIFICACIONES (<ins></ins> y <del></del>)

Para indicar las diferentes modificaciones introducidas en un documento disponemos de estas dos etiquetas.

  • <ins></ins> se emplea para indicar la inserción de nuevo contenido en el documento.
  • <del></del> se emplea para indicar el borrado de cierto contenido.

Ambas etiquetas disponen de dos atributos específicos que son:

  • cite="url". Para indicar la fuente explicativa de la modificación.
  • datetime="fecha". Para indicar la fecha y hora de la modificación.

Los navegadores suelen representar las inserciones como texto subrayado y los borrados como texto tachado.

Ambos son elementos en línea.

CITAS TEXTUALES (<blockquote></blockquote>)

Este elemento se utiliza para incluir citas textuales de otros documentos en el actual.

Dispone del atributo cite="url" para indicar la referencia al texto original citado.

Los navegadores suelen representar este elemento con un cierto margen a la izquierda.

Es un elemento de bloque.

AUTOR CITADO (<cite></cite>)

Este elemento se utiliza para declarar el autor de una cita. La diferencia con blockquote es que mientras esta contiene la cita en sí, cite denota al autor de la cita.

Es un elemento en línea.

ABREVIATURAS (<abbr></abbr>), ACRÓNIMOS (<acronym></acronym>) y DEFINICIONES (<dfn></dfn>)

Son elementos en línea con el atributo title="texto" que se usan para abreviaturas, siglas y definiciones de palabras "extrañas" usadas en el documento y así poder indicar su significado.

Los navegadores las suelen representar como texto subrayado por puntos, y suelen mostrar un texto alternativo al situar el ratón sobre ellas (el indicado en el atributo title).

SALTO DE LÍNEA (<br />)

La etiqueta <br> es un tanto especial. Sirve para forzar un salto de línea en nuestro documento.

Es una etiqueta vacía y como tal debe abrirse y cerrarse consecutivamente, pero para evitar tener que escribir <br></br> se abrevia como <br />.

Debemos limitar su uso a ocasiones bastante especiales y no abusar; seguro que lo que queremos hacer se puede hacer de otra manera mucho mejor.

Inciso. Los espacios en blanco sobrantes dentro de un documento (tabulaciones, espacios en blanco consecutivos) son ignorados por HTML salvo que indiquemos lo contrario. Para introducir un espacio en blanco debemos recurrir a la entidad &nbsp;

TEXTO PREFORMATEADO (<pre></pre>)

Hay veces que debemos mostrar un texto dentro de un documento "tal cual se ha escrito", con todos sus espacios, tabulaciones, saltos de línea, etc (por ejemplo un objeto texto de la bd de Velneo). Para estos casos especiales usaremos la etiqueta <pre>.

Es un elemento de bloque cuyo ancho no se ajusta a la ventana del navegador, así que puede forzar la aparición del scroll horizontal en nuestras páginas.

Los navegadores suelen representarlo con un tipo de letra de ancho fijo.

CÓDIGO (<code></code>)

Cuando dentro de un documento hemos de representar código html o de otro tipo que haga uso de las entidades específicas de HTML usaremos la etiqueta <code>.

Es similar a <pre> con la salvedad de que no respeta los espacios en blanco y es un elemento en línea.

LISTAS ORDENADAS (<ol></ol>) y NO ORDENADAS (<ul></ul>)

Cuando hemos de representar en nuestro documento una sucesión de elementos ordenados (numerados de alguna forma) o sin orden aparente, usaremos las listas.

Cada elemento de una lista irá encerrado entre <li> y </li>.

Son elementos de bloque y los navegadores suelen representarlas indentadas y usando números para los elementos de una lista ordenada, y viñetas gráficas para las lista no ordenadas.

Inciso. Este tipo de elementos, veremos más adelante que nos servirá para definir nuestras estructuras de navegación (menús) usando un poco de CSS.

Y por hoy hasta aquí!

En la próxima entrega veremos cómo introducir tablas, imágenes, enlaces y otros elementos útiles dentro de nuestros documentos.

Life is soft!!