Inicio Autor Contacto

13 leyes de oro para dar el gran paso

Amigos, aquellos que están decididos pero no saben cómo entrar en el mundo XHTML, este post quizás les aclare algunas cosas. El gran paso al mundo XHTML es simple: las reglas.

En todo lenguaje encontraréis reglas básicas. XHTML no es un lenguaje distinto a HTML, para nada, sólo tiene unas reglas básicas que lo hacen especial. Esas reglas te permiten hacer páginas válidas. Que una página sea válida no asegura que sea buena o que solucione todos los problemas. Para ello, sólo mejor es estudiar el propósito de cada etiqueta. Esto nos permite discernir que etiquetas debemos utilizar. Esto (las reglas y los propósitos) nos permitirán no sólo crear estupendos ejemplos de código (simple, semántico y accesible) sino también páginas que validan, son fáciles de mantener y re-utilizar.

Volviendo al primer escalón de nuestro gran paso… las reglas, ¿Dónde están las reglas? En cualquier lenguaje (Ej. PHP) pueden averiguar comprando un manual, o bien, yendo a la página oficial. Para XHTML basta con acercarse a la web de W3C y buscar dicha especificación.

W3C te ofrece muchas especificaciones de XHTML. Tanto de las versiones 1.0 como 1.1, 2, básicas, por módulos, etc. No hay motivos para asustarse al ver tantas opciones. Les explicaré la razón de ello. XHTML no es un invento nuevo del HTML. Es una mejora, una revisión de lo que se hizo en el pasado. Los científicos y desarrolladores que colaboran en estos proyectos van mirando las necesidades y las nuevas posibilidades de estos lenguajes, creando así nuevas versiones con reglas cambiadas. Como HTML no satisfacía dichas condiciones, se creó XHTML, que es HTML pero con reglas principales de XML. XML es un lenguaje tan abierto y mutante que necesita reglas. Esas reglas básicas se aplicaron a HTML dando por creado XHTML. XHTML no deja de ser un HTML con unas reglas más estrictas que permiten una cierta uniformidad a la hora de hacer cosas. Esta uniformidad asegura a cualquier fabricante un margen o unos límites para sus herramientas (Ej. Un navegador). Imagínense que HTML siga siendo un lenguaje anárquico, que existan miles de etiquetas provenientes de muchos lados en donde existen reglas. En estas condiciones, no habría uniformidad, no existirían patrones de los cuales los fabricantes se puedan coger para hacer una herramienta que muestre, analice y aproveche el HTML, sino que sería el caos (muy lejos de eso no estamos todavía).

Entonces, primero las reglas. XHTML tiene unas reglas muy básicas. Citaré paso a paso las reglas del XHTML:

Regla 1: Todos los documentos XHTML necesitan especificarse con un DTD

No es válido, bajo ninguna circunstancia un documento sin un DTD. Un DTD es un Document Type Declaration. Es otro documento que especifica la naturaleza del nuestro. Por eso, todos los documento tienen que llevar por cojones esta instrucción. Esa instrucción, sirve para diferenciar el tipo de XHTML, o sea, si el documento es estricto tendrá un DTD estricto, si el documento es transitorio (que está pasando una transición a un lenguaje estricto) llevará un DTD Transitional y si el documento tiene frames o es modular llevará el que le corresponda.

Metáfora aplicable:

De la misma forma que un agente de la policía necesita una tarjeta que lo acredite como tal, un documento de XHTML necesita un DTD para presentarse ante el navegador y responder como tal.

Sin DTD, la página no valida. El navegador no sabe que tipo de documento mostrará al usuario, por lo que estará a la expectativa poniendo todo su motor y esfuerzo para mostrar el documento bien… eso lo podemos traducir en: más trabajo para el navegador.

Regla 2: El elemento raíz de cada documento deberá ser la etiqueta <html>.

Si no se encuentra esta etiqueta no hay documento de XHTML. Además esta etiqueta tiene que especificar una cosa importante: el namespace. El namespace es una dirección donde se justifican los tags que utilizaremos. Sin esto, es como si un agente de policía te mostrara su identificación y tú no veas de qué central de policía es, cómo se llama o a quién reclamarle algo.

Además, la etiqueta <html> requiere de dos atributos importantes: los idiomas. Como todos los documentos tienen que llevar un idioma especificado, éstos deben anunciarse en la primera etiqueta utilizando los atributos xml:lang="…" y lang="…" a la vez. xml:lang="…" servirá para aquellos navegadores o dispositivos (Ej. Un teléfono móvil) que soporten atributos en XML (recuerden que, XHTML es básicamente el HTML que se quiere convertir en XML). Entonces, hemos de poner este atributo que no existe en el mundo HTML pero si en XML. Luego, debemos invertir golpes de tecla en otro atributo que sí pertenece al mundo HTML y es el atributo lang="…". Este atributo ayuda a especificar en qué idioma estará escrito el documento, de la misma forma que lo hace xmlang pero escrito a la HTML.

Regla 3: Los documentos deben ser gramaticalmente correctos

Aquí viene una regla fácil de conseguir. La gramaticalidad en HTML, XML, XHTML o cualquier documento de la web la relacionaremos con la ortografía que escribiremos las etiquetas y ciertos atributos. Si escribimos mal las etiquetas o nos olvidamos de ciertos detalles, lo que ocurrirá será en forma incierta que nuestro documento no valide o el mismo navegador obvie mostrarlo.

Por ello, aplicaremos una política kosher para hacer nuestros documentos XHTML. Debemos tener en cuenta muchas cosas al escribir XHTML porque como había comentado anteriormente, los documentos son más estrictos que HTML y no nos dejan por ejemplo pasar siquiera la utilización de mayúsculas en las etiquetas de XHTML.

Los documentos tendrán que tener una característica de escritura y estar bien anidados. Anidados es otro término que confunde hasta el más experimentado en el tema. Creedme que hasta el más entrenado a veces se olvida de cerrar elementos de HTML o XHTML. Para ello, en XHTML esta regla es la más estricta de todas, no se puede uno pasar por alto nada, si empieza con una etiqueta, se debe cerrar al terminar de utilizar. Esto en HTML no es problema porque muchas equiquetas permiten el no cierre (Ej. <p>) pero en XHTML no.

Un ejemplo correcto:

<p>he aquí un <em>párrafo</em> enfatizado.</p>

Como vemos en el ejemplo, hemos comenzado con la etiqueta <p> luego en medio con <em>, terminamos de usar <em> y lo cerramos con su correspondiente </em> que luego terminamos cerrando todo con la etiqueta </p> que antes habíamos usado con <p>.

Un ejemplo mal hecho:

<p>he aquí un <em>párrafo</p> enfatizado</em>

Aquí notarán que algo no cuadra, si empezamos con <p> y luego abrimos otra etiqueta <em>, para cerrar bien debemos primero cerrar la segunda (la <em>) y no la primera. Usando </em> antes que </p> y luego sí </p>.

Otro caso común y que a cualquiera le puede pasar:

<p>he aquí un <i><b>párrafo</i></b> enfatizado</p>

Aquí el error está dentro del mismo texto. Hemos hecho bien la primera parte (abrir y terminar el párrafo con <p> y </p> pero dentro hemos abierto con <i> y cerramos con </b>. Ahí está el problema. Debería ser:

…un <b><i>párrafo</i></b> enfatizado…

Abrimos con un <b> y cerramos con un </b>. Dentro de <b>…</b> lo mismo, abrimos un <i> y cerramos con un </i>.

Debido a la naturaleza de <b> e <i> éstos pueden ir en el orden que queramos: primero el <b> o el <i>. El resultado será siempre el mismo siempre y cuando se encuentren bien anidados.

Ojo con anidar elementos que no son propios de su naturaleza o los resultados serán desastrosos. Más adelante hablaré de la naturaleza de cada etiqueta.

Regla 4: Los nombres de elementos y atributos deben escribirse en minúscula

Los documentos XHTML deben usar minúsculas para los nombres de todos los elementos y atributos HTML. Esta diferencia es necesaria porque XML es sensible a minúsculas y mayúsculas Ej. <li> e <LI> son etiquetas diferentes aunque se escriban igual. Por eso recuerden las mayúsculas para escribir XHTML no están permitidas bajo ninguna circunstancia.

Regla 5: Todas etiquetas que no sean vacías deberán cerrarse

Con HTML 4.0, basado en SGML, en algunos elementos podía omitirse la etiqueta de cierre, de tal manera que la apertura de los elementos que les sucedían implicaba dicho cierre. Esta omisión no está permitida en XHTML, basado en XML. Todos los elementos que no estén declarados en la DTD como EMPTY deben tener una etiqueta de cierre.

Ejemplo:

La etiqueta <p> como no es una etiqueta vacía como <img> requiere de una misma etiqueta <p> adaptada de cierre: </p>.

Regla 6: Los valores de los atributos deben ir entre comillas dobles (importante)

Todos los atributos usados en XHTML deben llevar comillas dobles: lang="…". Las comillas simples pueden funcionar en otros tipos de documentos, la ausencia de las comillas también, pero en XHTML es importante que cada atributo tenga comillas dobles. Sin estas, el documento nunca validará y las cosas pueden ir a mal.

Antes podíamos escribir cosas como estas:

<table cellspacing=2 cellpadding=5> o <table cellspacing='2' cellpadding='5'>

Ahora debería ser así:

<table cellspacing="2" cellpadding="5">

Regla 7: Minimización de atributos

HTML soportaba la minimización de los atributos. Por ejemplo, nowrap era un atributo que se utilizaba en las celdas (<td>) de las tablas (<table>) para que no rompieran las líneas de textos o contenidos dependiendo el ancho natural de la página. Antes podían verse cosas como:

<td nowarp>Texto</td>

Esto no funciona en XHTML, deberías escribirlo como:

<td nowrap=""> o <td nowrap="nowrap">

Regla 8: Elementos vacíos deben llevar una barra de cierre

¿Recuerdan todas esas etiquetas que no llevan una misma etiqueta de cierre? Ej.: <img>, <hr>, <input>. Bueno, todas estas etiquetas se llaman “elementos vacíos” porque no encierran contenidos sino que los referencian. Estos si o sí tienen que tener una barra de cierre /, sino el documento no valida y en algunos casos pueden obtenerse resultados no deseados:

Bien hecho:

<p>Esta es una imagen de mis vacaciones en Granada: <img src="granada.png" alt="foto" /></p>

Mal hecho:

<p>Esta es una imagen de mis vacaciones en Granada: <img src="granada.png" alt="foto" ></p>

Nótese la barra al final de la etiqueta “/>”. También podemos verla en la etiqueta <hr> de esta forma <hr />. ¿Por qué el espacio entre la barra y el nombre de etiqueta? Por motivos de compatibilidad con navegadores viejos. En un futuro, no hará falta.

Regla 9: Elementos con atributos id y name

En HTML se utilizan atributos que tienen una función muy específica: definir identificadores o nombres que señalan algo. En HTML utilizabamos name y id para espeficar muchas cosas. En XHTML el uso de name está restringido tal es que sólo está permitido en la versión XHTML 1.0 transitional, o sea que si nuestro documento no tiene una DTD transiotional cualquier uso de name hará que nuestro documento no valide.

Otro factor importante que siempre se me pregunta en las charlas, curso que imparto son, ¿qué diferencias hay entre name y id? Bueno, name especifica lo mismo que id solo que id es único en todo el documento. Es una forma de decir este es la única etiqueta con este valor sirve para diferenciar una etiqueta de otras iguales.

En XHTML 1.0 transitional los valores que tengan name deberán incluirse un id:

<td name="nombre" id="nombre">

En XHTML 1.0 estricto o XHTML 1.1 los valores que tengan name deberán ser id:

<td id="nombre">

Bajo ninguna causa pueden llevar name. id al ser único, no puede repetirse este valor, o sea:

<td id="nombre"><a id="nombre">Enlace</a></td>

Los name pueden llevar números y letras indistintamente. Los id también pero deberán comenzar con una letra de la a → z ó de la z → a y luego números. Si esto se olvida el documento no valida y los resultados pueden ser no deseados.

Regla 10: Conocer los elementos de bloque, linea y reemplazados

Cada elemento o etiqueta de XHTML y HTML tienen una naturaleza. Esta naturaleza se traduce en 3 estados conocidos como: elementos de bloque, elementos de línea y elementos reemplazados.

Los elementos de bloque son todos aquellos que en su estado natural ocupan toda una línea de pantalla, y desplazan hacia abajo a otros elementos de bloque, linea o reemplazados.

Los elementos de linea son todos aquellos que puestos en su estado natural se agolpan uno al lado del otro y se desplazan hacia abajo cuando el ancho de la pantalla no les deja hueco donde acomodarse.

Los elementos reemplazados son todos aquellos que un día fueron algo y hoy por determinada causa no lo son. Si una imagen (elemento en linea) gracias a una propiedad escrita en CSS pasa a ser un elemento en bloque, este no es un elemento en bloque sino un elemento reemplazado que cumple las características de un elemento en bloque.

Aprenderse qué elementos son de linea o bloque es una tarea esencial para no cometer errores. En la siguente regla explico porqué es importante.

Regla 11: No todos los elementos pueden ser anidados por otros elementos y viceversa

Tanto en HTML como XHTML se dan los casos que encerramos etiquetas dentro de otras etiquetas. Esto sirve para definir capas y ciertas cosas propias del documento. Ejemplo, todas las etiquetas de una página están encerradas por la etiqueta raíz <html> dada que ésta tiene esa peculiar función se le permite todas las excepciones. Pero hay casos que no, incluso por más que el navegador respete nuestra decisión de anidado de etiquetas, éstas no cumplirán ciertas reglas básicas:

a

No puede contener otros elementos a.

pre

No puede contener los elementos img, object, big, small, sub o sup.

button

No puede contener los elementos input, select, textarea, label, button, form, fieldset, iframe o isindex.

label

No puede contener otros elementos label.

form

No puede contener otros elementos form.

Por decirlo así, no debemos caer en ciertas irregularidades como:

Un elemento de linea que encierre a un elemento de bloque:

<em><p>Este es un párrafo con &eacute;nfasis.</p></em>

Mejor así:

<p><em>Este es un párrafo con &eacute;nfasis.</em></p>

Debéis tener sumo cuidado con el anidado. Esto se puede solucionar sabiendo qué elementos estáis usando, si son de línea, si son de bloque, etc.

Regla 12: Aprenderse para qué sirve cada etiqueta

Es común entre los pasantes de HTML a XHTML que comentan la típica atrocidad de utilizar etiquetas que cumplen una función básica por otra que no la cumple. Un ejemplo claro que todos pueden ver en el diario Clarín (aviso: no tengo nada contra esta gente), que utiliza HTML y CSS pero lo realiza con prácticas erróneas:

<!--/VOLANTA-->
<!-<del>TITULO</del>-><span class="tu1">
El básquet juega
con Italia por el oro</span>
<br clear="all">
<span class="sep"><br>
<br><br><br>
<br><br></span>
<!--/TITULO-->

Como podrán observar, quieren reemplazar a una etiqueta importante como lo es <h1> por una de menos importancia como lo es <span>.

<h1> sería la etiqueta correcta para aplicar a un título en una página y, con el uso debido de CSS se puede obtener el mismo resultado y con mejores prestaciones que usando <span>. <span> es una etiqueta muda e invisible en el mundo HTML, sirve para crear elementos de línea con determinada </p> función de CSS pero no para definir la estructura de un documento.

Otro caso me lo ha enviado una lectora que está trabajando en un proyecto que requiere el traspaso del antiguo HTML a XHTML:

Muchas gracias,<br />He visto la luz. Ahora lo entiendo !!!!

Es decir, mi editor, en vez de meter una <b> puede meter un <div id="negrita"> y ese id esta recogido en una CSS estandar q le aplicará el estilo apropiado.

Ya se por donde tengo q seguir mirando.

Aquí está claro, quieren reemplazar el viejo <b> (que sigue siendo válido pero a futuro no lo será) por una etiqueta <div id="negrita"> que tiene como intenciones reemplazar a la etiqueta <b>. En este caso lo correcto sería utilizar la etiqueta <strong>, porque es buena para marcar palabras y resaltarlas, tanto visualmente como auditivamente. <strong> cumple más funciones adecuadas para este caso que utilizando <span>, <div> u otra etiqueta que visualmente no se delate.

Sumo cuidado con estos cambios.

Regla 13: Que una página valide no significa que ¡ya está todo dicho!

¡No! Equivocación número uno de todos los principiantes. No se asusten, pero es fácil hacer validar una página, ¡pero eso no quita que esté mal programada!. Comprobarlo con cualquier página bien programada. Puedo hacer un documento que valide pero que por dentro utilice métodos anticuados como el caso que hemos visto del Diario Clarín. Hay que tener mano y conocimientos para hacer una página que valide y esté bien estructurada. Por ello les recomiendo las reglas anteriores y por sobretodo saber discernir para que sirve cada etiqueta y utilizarlas para su función y no para su visualización. Para la visualización utilicen CSS.

Un caso válido pero mal aplicado:

<p>Este es un párrafo y
esta es una <span class="negrita">negrita</span>.</p>

Esto puede validar perfectamente pero:

  1. Se está empleando el tag <span> por otro que tiene más relevancia en estos casos como lo es <strong>.
  2. Se está escribiendo un atributo para luego en una plantilla de CSS seguir definiendo propiedades de grosor de letra, color, etc. Cuando el tag <strong> por naturaleza no necesita definición alguna.
  3. Se está llenando el código de etiquetas con fines visuales y no estructurales.
  4. Un lector de pantalla o un dispositivo que no entienda de CSS mostrará las etiquetas mal empleadas a su manera y no a la correcta.

Bueno, estas 13 reglas de oro son simples. Saltarlas no les hará más que un daño que no tiene porqué. Se pueden obtener iguales resultados y escribir menos sabiendo qué usar y cómo. Los cambios en el futuro podrían ser menos dolorosos y no requerirán de tener que hacerlo todo de nuevo.

Cualquier duda consultar si o si estos recursos:

Con estas reglas y recursos ya puedes dar el gran paso.

« Alegría
Minid.net en la revista Magazine del diario La Vanguardia »

37 Respuestas a la entrada “13 leyes de oro para dar el gran paso”

Escrito por Salva
Agosto 28th, 2004 at 6:53 pm

http://validator.w3.org/check?uri=http%3A%2F%2Fdelavega.bitacoras.com

:P

Escrito por mini-d
Agosto 28th, 2004 at 7:03 pm

Yo realmente valido poco las páginas. Asotadme por esto, pero paso del validador sobre todo si hablamos de minid.net. Muchas veces escribo un post y pasan meses hasta que alguien valida.

Por suerte Wordpress hace bastante cosas para evitar que cierre un tag mal, o me olvide algo en el tintero. Cuando esto pasa, veo cosillas raras en el post y es ahí cuando lo reviso.

Ya les digo, validar no les asegura nada lo mejor es ser conscientes del código que han escrito. El validador es bueno para atajar determinadas cosas.

Escrito por Urban Design » Transicionando sobre XHTML
Agosto 28th, 2004 at 8:57 pm

Animado por el post de minid (100% recomendado) sobre 13 leyes de oro

Escrito por el_ja
Agosto 28th, 2004 at 9:11 pm

Validar… fue un sueño que tuve alguna vez jeje.
Pase como tres dias tratando de validar mi pagina y arreglaba una cosa y otra se descomponia, lo unico bueno fue que baje de como 500 errores a 40 y algo. la ultima vez que revise.

Escrito por Toad
Agosto 28th, 2004 at 9:12 pm

http://validator.w3.org/check?uri=http%3A%2F%2Ftoad.bitacoras.com%2F

:P

Por cierto, lo del tag / al final no es que unas etiquetas lo lleven y otras no, quiero decir, es tan válido esto:

[br][/br]

como esto:

[br /]

Pero como son etiquetas vacías, es más cómodo ponerle el / :P

Otra cosa: para que el navegador interprete el XHTML como XHTML y no como HTML hace falta poner el tipo MIME correcto, no basta con el DOCTYPE… :P

Escrito por Blog de Jaime Olmo: Print & Web Design » Guía básica para el XHTML.
Agosto 28th, 2004 at 9:24 pm

[...] — James @ 5:24 pm

Soy lector fiel del blog Minid. Hoy disfruté de esta útil guía sobre XHTML la cual se que será de gran utilidad pa [...]

Escrito por PaToRoCo
Agosto 28th, 2004 at 9:34 pm

Buen manual, si señor, voy a enlazarte :D

Escrito por alberto bastos
Agosto 28th, 2004 at 10:33 pm

Bueno, para no tener ni idea de XHTML, por lo menos la mitad de las reglas ya las aplicaba…

Me he hecho un pequeño txt con lo básico y lo tendré muy en cuenta cuando vuelva a poner patas arriba mis páginas.

Por cierto, entonces, en el caso de id utilizado para aplicar css… ¿no puedo utilizar el mismo valor de id en dos elementos? Por ejemplo, si para los párrafos que contienen una anotación quiero utilizar el estilo “post”, es más correcto:

p.post {
…
}

Que:

p#post {
…
}

Verificamelo, que eso es algo que nunca he entendido del todo.

Otro buen trabajo, Diego. ¡Saludos!

Escrito por Martín
Agosto 28th, 2004 at 10:51 pm

Un detalle: la etiqueta <em> no es para poner en cursiva, y <strong> no es para poner en negrita. Son, respectivamente, para enfatizar, y para enfatizar más aún. La representación que se haga de ellas depende del navegador, que, aunque normalmente sea negrita y cursiva, no tiene por qué ser así.

Así que para escribir cosas como por ejemplo ironías, palabras con doble sentido… no debería utilizarse <em> (en mi opinión), sino un span con clase “cursiva”, “ironia”, o lo que proceda.

Escrito por Douch
Agosto 28th, 2004 at 11:00 pm

Hay una cosilla que no me ha quedado clara en el ejemplo de la lectora en el punto 12. Si lo que yo quiero es resaltar una palabra en negrita y además darle un color determinado mediante CSS, ¿lo que debería escribir es algo como ésto?:

… <span class=”colorear”><strong>saludos </strong></span>

Por cierto, muy buen post, me ha ayudado mucho.

Escrito por stan
Agosto 28th, 2004 at 11:25 pm

Me gusta mucho volver a leer cosas como estas minid, creo que mencionaste algo que me llego..

y fue que “no por que validen quien decir que estan bien”

Un saludo y suerte a Argentina.

Escrito por Jaime Olmo
Agosto 28th, 2004 at 11:32 pm

Gracias Diego. Execelente guía.

Escrito por NetDancer
Agosto 29th, 2004 at 12:50 am

Estupendo post. Muy práctico y bien condensado, como casi todos estos mini-tutoriales a los que nos tienes -mal- acostumbrados ;-)

Escrito por Joan
Agosto 29th, 2004 at 1:34 am

Muchas gracias por tu tutorial. Ando metido de lleno en la realización de un proyecto web en el que intento dar el salto del HTML al XHTML/CSS, me viene de maravillas.

P.D. (Fuera de contexto) Las fotos del Camp Nou ¿las has hecho con la F717?

Escrito por Hosting Lmi - Alojamiento web » XHTML en 13 pasos
Agosto 29th, 2004 at 8:22 am

[...] saben cómo entrar en el mundo XHTML, este post quizás les aclare algunas cosas. El gran paso al mundo XHTML es simple:

Escrito por Miquel
Agosto 29th, 2004 at 10:02 am

Pero no es lo mismo validar una página como mini-d.net que otra donde sea interesante la validación pero no haya participación exeterna (léase, por ejemplo, contenidos). Puedes matarte a validar, y que la página de un post concreto tenga comentarios mal hechos. Más que validar en el sentido específico, se trata de hacerlo bien, digo yo. Si fuera una página plana, o donde sólo pudieras publicar tú, entonces el proceso sería algo más fácil (en el caso de la portada, por ejemplo, aunque aún así, en cualquier post se te puede ir la mano :D).

¿Azotarte? Acaso estoy visitando el blog de un sadomasoquista y aún no me había dado cuenta? xDD

Escrito por Orchard
Agosto 29th, 2004 at 12:10 pm

Muy Bueno Thx!!

Escrito por mini-d
Agosto 29th, 2004 at 2:08 pm

Alberto, estás en lo correcto.

Para referenciar en una hoja de estilos ID debes utilizar el prefijo #:

div#post { } o bien el método corto #post {}

Siempre y cuando, sepas que (en este caso) la div con ID “post” se utilizará una sola vez en la página y no varias. Para ello, debes recurrir mejor a una clase que te permite utilizarla cientos de veces, en cientos de lugares y etiquetas diferentes:

div.post {} y también p.post {} y también table.post {} etc.

Escrito por mini-d
Agosto 29th, 2004 at 2:16 pm

Martín deja que te diga que es lo que pienso sobre el tema <em> y <strong>. Si cuando escribes a máquina o mejor aún, lees un libro, notarás que encotrarás millones de expresiones escritas con negrita y cursiva.

em, el énfasis se puede expresar visualmente de dos formas: con una inclinación de las letras o con una subida de peso de la tipografía (caso negrita).

Ahora, tanto em como strong, son variantes auditivas de <i> e <b> que son visuales. Por supuesto, con CSS podemos incluso sacarlas de ese contexto, pero auditivamente no (salvo que utilicemos CSS Aural).

Por ello, siempre conviene dar el sentido auditivo a nuestros textos, porque éstos pueden ser leídos por cualquier lector. Visualmente tienes más probabilidades de no dar en el clavo que auditivamente.

Si quiero hacer énfasis de un texto cargado de ironía, lo haría con <em> porque: suena mejor y visualmente es lo mismo (por defecto) que <i>. Lo mismo para <b> usando <strong>.

Escrito por mini-d
Agosto 29th, 2004 at 2:24 pm

Douch,

Es una pregunta interesante. Veo que muchos se han ensañado con los <span>. Antes de usar span, porqué mejor no hacer una clase “universal” para dar un color determinado al elemento que quieras.

Imagínate este escenario, quieres colorear un <strong> o un <em> determinado, o hacer una negrita en determinadas etiquetas… el sistema es más fácil y corto que usando <span>:

Primero, has de crear una clase universal en CSS:

.negrita {
font-weigth: bold;
}

Ahora, como tienes una clase universal (me refiero a que la puedes usar en cualquier etiqueta) has de utilizarla a gusto en tu XHTML.

Mientras escribes si una palabra quieres que lleve negrita, escribes <strong> pero si quieres que una palabra que tenga <em> (cursiva + énfasis) pero además sea en negrita escribe esto:

<em class=”negrita”>este es un texto en negrita + cursiva</em>

¡Magia!

Escrito por mini-d
Agosto 29th, 2004 at 2:32 pm

Pero no es lo mismo validar una página como mini-d.net que otra donde sea interesante la validación pero no haya participación exeterna (léase, por ejemplo, contenidos). Puedes matarte a validar, y que la página de un post concreto tenga comentarios mal hechos. Más que validar en el sentido específico, se trata de hacerlo bien, digo yo.

Miquel, tienes razón aquí. Pero, te doy un consejo: limita el uso de los comentarios a una cierta cantidad de etiquetas. Esto reduce el márgen de errores por página.

Escrito por Weblog
Agosto 29th, 2004 at 7:10 pm

[...] 13 leyes de oro para dar el gran paso

Me ha interesado mucho este artículo de minid: 13 leyes de oro para dar el gran paso. N [...]

Escrito por Reflejos
Agosto 29th, 2004 at 9:10 pm

minid: 13 leyes de oro para dar el gran paso
Me ha interesado mucho este artículo de minid: 13 leyes de oro para dar el gran paso. No estoy seguro de que sea un gran paso el dejar HTML y

Escrito por a-css » 13 bones pràctiques per l’XHTML
Agosto 29th, 2004 at 10:06 pm

[...] 13 bones pràctiques per l’XHTML
29/08/04 En minid sintentitzat 13 bones pràctiques a l’hora de treb [...]

Escrito por a-css » 13 bones pràctiques per l’XHTML
Agosto 29th, 2004 at 10:07 pm

[...] 04 En minid sintentitzat 13 bones pràctiques a l’hora de treballar amb XHTML. En Toad comenta una mancança qu [...]

Escrito por berto
Agosto 30th, 2004 at 12:03 am

para mi una herramienta imprescindible, todos los tutoriales y referencias de ZVON en un solo fichero chm (formato ayuda de windows), aqui la podeis descargar:

http://www.zvon.org/Output/chm/chm_list.html

para leer ficheros chm en linux:

Xchm

GnoCHM (para Gnome)

Escrito por TRAZAS » minid.net » salto al XHTML
Agosto 30th, 2004 at 11:42 am

[...] 30/8/2004 nº123 minid.net » salto al XHTML

minid.net » 13 leyes de oro para dar el gran paso [...]

Escrito por BenKo
Agosto 30th, 2004 at 1:43 pm

Muy bueno el artículo :D

Pero tengo una dudilla respecto a ID y a NAME. ¿Qué hay de los formularios? Si se usa sólo ID no funciona (al menos en una pequeña prueba que he hecho) y hay que utilizar también el NAME. ¿No hay alguna otra manera de englobarlos o debemos utilizar los dos?

Escrito por a-css » Marcat semàntic
Agosto 30th, 2004 at 4:43 pm

[...] Marcat semàntic
30/08/04 En minid ha fet un altre article complementant el de 13 leyes de oro para dar el gran [...]

Escrito por a-css » Marcat semàntic
Agosto 30th, 2004 at 4:43 pm

[...] Marcat semàntic
30/08/04 En minid ha fet un altre article complementant el de 13 leyes de oro para dar el gran [...]

Escrito por Black Clouds: The Rainy Blog
Agosto 30th, 2004 at 6:34 pm

Para iniciarse en XHTML
MiniD se mandó un excelente artículo sobre como iniciarse en XHTML. Habiendo escrito sobre estándares en posts anteriores, hacer referencia a este post me es obligación. Al final también hay algunos enlaces con más documentación ¡y en castellano! “Yey…

Escrito por Urban Design » El tintero de Diego
Agosto 30th, 2004 at 8:53 pm

[...] go
Bolg — La red @ 10:52 pm —
Parece que después de el artículo de [...]

Escrito por :: Nordic Design :: Un blog de Alejandro Lillo. Diseño, estándares web y vida en general
Septiembre 5th, 2004 at 8:42 pm

[...] mucho de XHTML, HTML, etc. En Minid tenéis un excelente tutorial-guía de normas y buenas maneras en XHTML, en Le [...]

Escrito por Guti
Septiembre 5th, 2004 at 11:48 pm

Excelente introducción.

Escrito por Digital
Septiembre 30th, 2004 at 9:35 am

Y alguién sabe como validar cuando se usan páginas dinámicas?.

Porque hasta ahora sí que he podido reemplazar &(&amp;), etc cuando
tú controlas los enlaces y el url a enviar, pero tengo el problema de la
validación cuando uso las sesiones, por ejemplo, en PHP.

Ya que el SID de sesión se manda automático
con cada enlace de esta forma: http://pagina.php?loquesea=dato más el SID:
&SIDcomosea=id

y tenemos 2 carácteres no válidos por lo tanto.

Bueno, excelente trabajo minid,
no me cansaré de visitar este blog, sé que no es un foro de ayuda,
como otros por ahí, pero me vendría bien algo de información al respecto.
Un saludo.

PD: Excelente artículo.
Me habré pasado con el formato??, ;D

Escrito por Roberto
Abril 30th, 2005 at 3:28 am

Hola, encontré un pequeñísimo error, al final de este párrafo dice transiotional en lugar de transitional.

Regla 9: Elementos con atributos id y name

En HTML se utilizan atributos que tienen una función muy específica: definir identificadores o nombres que señalan algo. En HTML utilizabamos name y id para espeficar muchas cosas. En XHTML el uso de name está restringido tal es que sólo está permitido en la versión XHTML 1.0 transitional, o sea que si nuestro documento no tiene una DTD transiotional

Escrito por volldamm.net » Recull d’articles per aprendre XHTML i CSS
Marzo 16th, 2006 at 11:25 am

[...] 13 leyes de oro para dar el gran paso [...]