Logo de Mosaic
CSS
Diseño, composición y presentación de formularios con CSS

34. Diseño, composición y presentación de formularios con CSS

Ben Henick. 26 de septiembre del 2008. Última modificación: 2 de agosto de 2017 (equipo docente del grado de Multimedia). Publicado en: alineación, seleccionar, tercios, composición, cuadrículas

El apartado de formularios HTML os presentó los conceptos básicos de creación de formularios y estilos. Este apartado continúa donde acabó el otro y ofrece más detalles sobre los elementos y estilos de formulario, así como sobre de qué modo se incluyen los formularios en los diseños de aplicación web del mundo real.

Nota

Podéis descargaros el fichero de código de ejemplo completo "styling_forms_code.zip" para que podáis jugar con él en vuestro ordenador. Además, en varios puntos del apartado se ofrecen enlaces a los ficheros de ejemplo.

Descargad el fichero de código de ejemplo completo en: "Styling forms code examples"

Los contenidos de este apartado son los siguientes:

34.1. Conceptos nuevos que presenta este apartado

En este apartado encontraréis información sobre la implementación de formularios y la composición de interfaces.

34.1.1. Sobrecarga de reglas y etiquetas

Se puede decir que si se utilizan muchas etiquetas class e id, se incumple el principio KISS. Sin embargo, las composiciones exigentes a menudo provocan conflictos en la cascada, conflictos que se pueden resolver muy fácilmente añadiendo etiquetas y redactando reglas de hoja de estilo que contengan varios selectores.

Ved también

El principio KISS se explica en el apartado 30 de este módulo.

Las composiciones más exigentes están llenas de casos límite, que es mejor solucionar asignando un id a los elementos que definen un contexto muy concreto y especial.

34.1.2. Elementos de campo de formulario nuevos

Un formulario efectivo a menudo debe ser algo más que un conjunto de botones y campos de introducción de texto porque es habitual estructurar las respuestas del usuario en términos de opciones. El HTML proporciona varias opciones para los diseñadores que se encuentren con este requisito.

34.1.3. Principios del diseño de formularios

Los formularios de un sitio web son normalmente puntos centrales para la interacción con el usuario y la obtención de datos. Por lo tanto, suelen ser fundamentales para el éxito de una web, que exige diseñarlos con todo el cuidado posible.

34.1.4. La regla de los tercios

Los usuarios suelen centrar su atención en cuatro puntos de un lienzo (y en las líneas que los atraviesan). Este apartado presenta este fenómeno al lector y ofrece sugerencias para aprovecharlo al máximo con el CSS.

34.1.5. Cuadrículas

En apartados anteriores ya se ha explicado cómo garantizar unas tipografías consistentes y sacar el máximo provecho del espacio en blanco. Este apartado va un poco más allá y explica cómo se pueden utilizar las unidades em para aplicar un grado de consistencia a la composición que sería imposible sin CSS.

Ved también

Podéis ver cómo garantizar unas tipografías consistentes en el apartado 29 de este módulo y cómo sacar el máximo provecho del espacio en blanco en el apartado 10 del módulo "Conceptos de diseño web".

34.1.6. Capas de soporte de plataforma

Un requisito habitual de los proyectos comerciales es la representación casi exacta del diseño aprobado de la web en uno o más navegadores. En este apartado, se tratarán brevemente las causas, los efectos y los procesos relacionados en el cumplimiento de este requisito.

34.2. Un formulario de contacto sencillo

Los formularios de contacto con los que los visitantes de una web pueden enviar un correo electrónico directamente a una cuenta de correo son muy habituales por razones obvias: son accesibles a cualquier persona que tenga una dirección activa de correo electrónico y son fáciles de filtrar en una carpeta de correo específica.

Ved también

Podéis ver los formularios de contacto en el apartado 20 del módulo "El texto central de HTML".

El etiquetado que se ha utilizado en un módulo anterior sobre formularios utiliza uno de estos formularios, que se ha decorado mucho.

Ved también

Podéis ver el apartado 20 del módulo "El texto central de HTML".

34.2.1. Etiquetado

<form id="contactForm" method="post" action="/cgi-bin/service_email_script.php">
<ul>
   <li id="nameField" class="required"><label for="realname">Name:</label>
   <input type="text" name="name" value="" class="medium" id="realname" />
   <span class="note">required</span></li>
   <li id="addressField" class="required"><label for="address">Email:</label>
   <input type="text" name="email" value="" class="medium" id="address" />
   <span class="note">required</span></li>
   <li id="subjectField"><label for="natureOfInquiry">General
    subject:</label>
      <select name="subject" class="medium" id="natureOfInquiry">
         <option value="support">Support</option>
         <option value="billing">Accounts & billing</option>
         <option value="press">Press</option>
         <option value="other_q">Other questions</option>
      </select>
   </li>
   <li id="acctTypeField"><label for="acctNone">Account type:</label>
      <fieldset>
         <label for="acctGold">Gold</label><input type="radio"
          name="acct_type" id="goldAcct" class="rInput" />
      <label for="acctSilver">Silver</label><input type="radio"
       name="acct_type" id="acctSilver" class="rInput" />
      <label for="acctBronze">Bronze</label><input type="radio" 
       name="acct_type" id="acctBronze" class="rInput" />
      <label for="acctNone">None</label><input type="radio" name="acct_type" 
       id="acctNone" class="rInput" checked="checked" />
      </fieldset>
      <span class="note">required</span>
   </li>
   <li id="availabilityField">
      <label for="availability">My account is unavailable:</label>
      <input type="checkbox" name="is_down" id="availability" 
       class="rInput" /></li>
   <li id="messageField"><label for="messageBody">Comments:</label>
   <textarea name="comments" cols="32" rows="8" class="long"
    id="messageBody"></textarea></li>
   <li class="submitField"><input type="submit" value="Send"
    class="submitButton"  /></li>
</ul>
</form>

34.2.2. Cambios con respecto al formulario anterior

Además de incluir varios elementos nuevos, se han añadido algunas clases e ID al etiquetado a las que se puede hacer referencia desde la hoja de estilo. De esta manera, se puede hacer referencia a cada formulario, pareja de campo/valor y campo de manera individual sea cual sea el contexto.

Los nuevos identificadores también hacen que sea más fácil que el diseñador pueda distinguir los campos que se deben llenar obligatoriamente de los que no.

Para terminar, hay algunas clases nuevas que ofrecen sugerencias de la cantidad y tipos de información que deberían mostrar los elementos de formulario donde están adjuntados. Estas clases permiten aplicar detalles de composición a elementos arbitrarios múltiples de manera simultánea.

34.2.3. Defectos aparentes

Como se supone que el formulario de demostración es el contenido principal, la legend (leyenda) utilizada en formularios anteriores se ha sustituido por un título.

Las leyendas son muy adecuadas en los fieldsets (conjuntos de campos) en vez de las labels o etiquetas (que pueden identificarse con controles únicos). En este caso, el elemento legend se ha omitido completamente porque es difícil aplicarle estilos.

Hay que destacar también que es mejor colocar las etiquetas "obligatorio" sobre los campos a los que les corresponda antes que el campo en el código fuente para facilitar las cosas a los usuarios con software de lector de pantalla. No obstante, la propiedad position (de la que no hablaremos en este apartado) es necesaria para disponer estos elementos de manera adecuada. Por lo tanto, las etiquetas "obligatorio" se han colocado después de sus controles asociados en el código fuente (aunque en el mismo contexto).

34.2.4. ¿Campos de formulario nuevos? ¿Qué es eso?

En el apartado anterior ya se habló de los campos de texto y de los controles de envío. Como ya se ha mencionado anteriormente, hay varios casos de uso que requieren que el usuario pueda seleccionar una de dos o tres opciones. Estos elementos se describen brevemente a continuación:

Elegir descripciones: input type="checkbox"

...
<label for="availability">My account is unavailable:</label>
<input type="checkbox" name="is_down" id="availability" class="rInput" />

Las preguntas de participación o no participación suelen gestionarse con uno de estos controles. Otro caso en el que se utilizan es cuando hay que elegir arbitrariamente entre varias opciones, como, por ejemplo, una lista de intereses personales.

Elegir uno de dos posibles estados mutuamente exclusivos: input type="radio"

<label for="acctNone">Account type:</label>
<fieldset>
   <label for="acctGold">Gold</label><input type="radio" 
    name="acct_type" id="goldAcct" class="rInput" />
   <label for="acctSilver">Silver</label><input type="radio"
    name="acct_type" id="acctSilver" class="rInput" />
   <label for="acctBronze">Bronze</label><input type="radio"
    name="acct_type" id="acctBronze" class="rInput" />
   <label for="acctNone">None</label><input type="radio" 
    name="acct_type" id="acctNone" class="rInput" checked="checked" />
</fieldset>

Un grupo de éstos permite presentar varias opciones la una al lado de la otra y de las que sólo se puede elegir una. Un buen ejemplo de caso de uso de un conjunto de controles de radio (elección de un elemento entre varios) es la asignación de una nota en una escala de 1 a 5 o de 1 a 10.

Al contrario que otros controles de formulario, los controles de radio no sólo permiten sino que, de hecho, requieren que los controles asociados tengan el mismo name (nombre).

Estos elementos toman su nombre de una interfaz habitual en los aparatos de radio de coche sintonizados mecánicamente. Al contrario que los canales programables típicos de los aparatos de sintonización digital, los botones mecánicos de memoria, cuando se pulsan, suelen centrar el receptor en una gama de frecuencias de la banda que se está sintonizando.

Los controles de checkbox (casilla de selección) y radio permiten un atributo checked (comprobado) que, si se aplica, activa el control por defecto la primera vez que se representa.

Antes de responder a la pregunta de si utilizar controles de radio en lugar de controles de checkbox, hay que tener en cuenta varios factores. Si queréis que el usuario confirme una decisión subjetiva (como por ejemplo ser miembro de una lista de correo), probablemente serán mejores los controles checkbox. Si preferís que el usuario elija entre dos opciones objetivas (como, pongamos por caso, el género), es mejor utilizar los controles de radio.

Cuando hay demasiadas opciones para elegir: select/option

...
<label for="natureOfInquiry">General subject:</label>
   <select name="subject" class="medium" id="natureOfInquiry">
      <option value="support">Support</option>
      <option value="billing">Accounts & billing</option>
      <option value="press">Press</option>
      <option value="other_q">Other questions</option>
   </select>

Los elementos select y option ofrecen resultados parecidos a los proporcionados por una serie de controles de radio, pero ocupan mucho menos espacio. Elegir un elemento select en lugar de una serie de controles de radio suele ser una cuestión de cómo se utiliza el espacio en la interfaz de usuario; una lista larga de zonas geográficas o departamentos en una web de comercio electrónico suele ser más adecuada para elementos select, mientras que una serie más corta de opciones (como sí/no, verdad/mentira, gama de edad, gama de ingresos) debería establecerse como una serie de controles de radio.

Si ponemos a prueba de manera meticulosa nuestra creación, comprobaremos que el nivel de control motriz necesario para manipular una lista select es elevado, pero aumenta ligeramente en proporción con el número de options que incluye. El resultado práctico es que a las listas cortas de opciones mutuamente exclusivas es mejor aplicarles un formato como una serie de controles radio con labels bien escritas.

Agrupar series de controles: fieldset

La función principal del elemento fieldset es asignar un único contexto a una serie de controles íntimamente relacionados (controles text para un número de teléfono, elementos select para una fecha, etc.).

34.3. De cero hasta un formulario completo

Ahora que ya hemos presentado brevemente el material nuevo de este apartado, ha llegado el momento de ver este material en acción: las doce demostraciones que siguen progresan a través de varios conceptos de diseño y retos de aplicar estilos que se pueden encontrar a la hora de crear formularios web.

Se recomienda a los lectores que guarden el material de demostración en su disco duro y que hagan pruebas con las reglas de hoja de estilo.

Nota

Estas demostraciones avanzan por orden de código fuente en lugar de por el orden de creación de la hoja de estilo. Más adelante en este apartado se habla de los motivos y las implicaciones de esta divergencia.

34.3.1. Demostración 1

Si empezamos con una regla como: html {margin: 0; padding: 0; }, el primer paso es configurar el body (texto central) de la página.

body{
   margin: 0;
   padding: 1.714em;
   background-image: url(images/bg_grid.gif);
   font-size: 14px;
   font-family: Helvetica,Arial,sans-serif;
   line-height: 1.714em;
}

Archivo fuente de: "Página sin demasiados estilos"

Archivo fuente de: "Página con estilos body aplicados"

34.3.2. Demostración 1: consideraciones previas

34.3.3. Demostración 2

Ahora que hemos hablado de los contenedores de la página, los próximos dos pasos modifican o eliminan los estilos de agente de usuario.

h3 {
   margin: 0 0 1.2em 0;
   border-bottom: .05em solid rgb(0,96,192);
   font-size: 1.429em;
   line-height: 1.15em;
}
form {
   width: 35.929em;
   margin: 0;
}
ul {
   margin: 0;
   padding: 0;
   list-style-type: none;
}

Archivo fuente de: "Aplicar estilo al título principal y eliminar los canales no deseados"

34.3.4. Demostración 2: consideraciones previas

(((14 × 1.429) × 1.15) + (20 × .05)) ≈ 24
14 * 1.429 ≈ 20; 20 * 1.15 == 23; 20 * .05 == 1;

(20 × 1.2) = 24

34.3.5. Demostración 3

Pasemos ahora a establecer los contenedores de los elementos del formulario.

li {
   clear: both;
   height: 1.714em;
   margin: 0;
}
fieldset {
   height: 1.429em;
   margin: 0 0 -.143em 0;
   border: 0;
}

Archivo fuente de: "Elementos de la lista de estilo (contenedores de la pareja de etiqueta/valor) y del fieldset"

34.3.6. Demostración 3: consideraciones previas

34.3.7. Crear una cuadrícula

Uno de los puntos más significantes del buen diseño gráfico (y, de paso, del buen diseño de interfaces) es que los elementos se disponen a intervalos regulares. A estos intervalos se les suele denominar la cuadrícula (o grid, en inglés).

Como ya se ha mencionado anteriormente, la unidad atómica de cuadrícula del formulario de demostración son 24 píxeles cuadrados, pero la composición coherente va más allá de garantizar que los elementos de diseño se sitúen a intervalos pequeños pero regulares. Una cuadrícula realmente efectiva tiene las características siguientes:

Las composiciones que manifiestan estas características son más atractivas y fáciles de seguir, lo que contribuye a que el sitio sea más usable.

Crear la estructura de una cuadrícula en una composición

La herramienta que utilizan la mayoría de los profesionales para crear composiciones para la web es Adobe Photoshop, y una de las ventajas que tiene es el fácil acceso a las líneas de cuadrícula que ofrece. Para visualizar una cuadrícula atómica con Photoshop, se puede seleccionar View (vista) → Show (mostrar) → Grid (cuadrícula), con lo que se mostrarán las líneas de la cuadrícula en los intervalos establecidos en Guides & Grid Preferences (guías y preferencias de cuadrícula).

Superponer guías para elementos como las columnas se consigue seleccionando View (vista) → Rulers (reglas), cambiando a la herramienta Move (mover) y arrastrando el puntero desde la regla como sea necesario.

Aplicar la cuadrícula a la hoja de estilo

Como se comenta en el apartado de los estilos de texto, y refuerzan algunas de las reglas que se incluyen en la hoja de estilo de demostración, la mejor manera de aplicar una cuadrícula atómica en una composición es la de confiar en las unidades em. Sin embargo, sólo con eso no es suficiente; el especialista en estilos también debe mantener la corrección de las conversiones de fracciones a decimales cuando trata con otros tamaños de tipografía, canales y márgenes.

En la hoja de estilo de la demostración se puede ver otra técnica para aplicar cuadrículas: la provisión de etiquetas class (clase) que pueden hacer referencia a varios tamaños de elementos y columnas de un documento. Cuando se utiliza de manera consistente, estas etiquetas se encargan de casi todo el proceso de aplicación de la cuadrícula.

34.3.8. Demostración 4

Mantener los elementos alineados en una cuadrícula significa asignar propiedades de composición en las etiquetas y controles de formulario.

label {
   display: block;
   float: left;
   clear: left;
   width: 10.286em;
   overflow: auto;
   padding-right: 1.714em;
   text-align: right;
}
input {
   height: 1.143em;
   border: .071em solid rgb(96,96,96);
   padding: .071em;
   line-height: 1;
}

Archivo fuente de: "Alinear las dos columnas principales"

34.3.9. Demostración 4: consideraciones previas

34.3.10. La regla de los tercios

Una escena de principios de primavera en la zona norte de Pioneer Square, en Portland, Oregon, con unas líneas superpuestas que dividen la foto en nueve partes más o menos iguales.

Figura 1. Una escena de principios de primavera en Portland, Oregon. Sobre esta foto se han superpuesto unas líneas para demostrar la regla de los tercios; fijaos en que la intersección inferior derecha y las líneas que la forman contienen toda la actividad visible. Foto © 2000 del autor; todos los derechos reservados.

Si se quiere conseguir una buena composición, hay un recurso casi universal: si dividís en tercios una disposición o ilustración, descubriréis que el observador centra la mirada en las líneas (y sobre todo en las intersecciones de las líneas) que señalan estas divisiones. Si no se aprovecha esta extraña tendencia de la vista, la composición quedará desequilibrada.

La explicación más sencilla de este fenómeno es que estas cuatro líneas se adaptan prácticamente a la perfección a la cuadrícula que sigue la sección áurea, una proporción próxima a un sexto. La sección áurea suele encontrarse en diferentes campos de las matemáticas y en el mundo natural.

Captura de pantalla de msnbc.msn.com con los primeros siete rectángulos áureos superpuestos

Figura 2. Una captura de pantalla de msnbc.msn.com con los primeros siete rectángulos áureos superpuestos. Las dimensiones del cuarto y quinto rectángulo uno al lado del otro aclaran el carácter de la cuadrícula de composición de página en general.

El formulario de demostración se ha dispuesto de manera que los controles del formulario queden justificados en el margen izquierdo situado a un tercio de la distancia del margen derecho del formulario en conjunto; fue una decisión tomada a propósito. Mucho menos a propósito es la composición vertical del formulario porque, cuando se tiene en cuenta el título, los campos de texto cortan las dos líneas descritas en el párrafo anterior. Y aunque no se tenga en cuenta el título, los campos obligatorios cortan la parte superior de estas líneas.

El punto principal para un especialista en estilos es que si la sección áurea y la cuadrícula se tienen en cuenta antes de empezar a crear una hoja de estilo, el hecho de normalizar la hoja de estilo se puede simplificar de manera considerable.

34.3.11. Demostración 5

Para garantizar que la cuadrícula que queremos crear se conserve vertical y horizontalmente, se deben tener en cuenta algunos detalles. Estos cambios son casi del todo estéticos.

textarea {
   height: 4.714em;
   margin-bottom: .286em;
   border: .071em solid rgb(96,96,96);
   padding: 0;
}
select {
   display: block;
   float: left;
   height: 1.571em;
   font-family: Futura,'Century Gothic',sans-serif;
}
option { font-size: 100%; }

Archivo fuente de: "Retocar la presentación de los controles textarea y select"

34.3.12. Demostración 5: consideraciones previas

34.3.13. Demostración 6

La demostración previa manipula algunas representaciones de tipografía, de modo que ahora es el momento de acabar de redondear el trabajo.

input, textarea {
   display: block;
   float: left;
   overflow: hidden;
   font-family: Futura,'Century Gothic',sans-serif;
   font-size: 1em;
}
input, textarea, select {
   margin-top: 0;
   font-size: 100%;
}

Archivo fuente de: "Normalizar la presentación de los controles de texto y ajustar el efecto de la cascada en el texto de control de select"

34.3.14. Demostración 6: consideraciones previas

34.3.15. Demostración 7

Las anchuras de los distintos controles de texto se deben cambiar desde sus valores por defecto.

.medium { width: 11.714em; }
select.medium { width: 12em; }
.long { width: 20.429em; }
.rInput { border: 0; }

Archivo fuente de: "Modificar las anchuras de los controles de texto para hacerlas más usables o, como mínimo, más consistentes"

34.3.16. Demostración 7: consideraciones previas

34.3.17. Demostración 8

El botón "enviar" del formulario decae...

.submitButton {
   display: block;
   clear: both;
   width: 7.2em;
   height: 2em;
   margin: 0 0 0 16.8em;
   border: 1px solid rgb(128,128,128);
   padding: 0;
   font-size: 10px;
   text-align: center;
}

Archivo fuente de: "Ajustar con precisión la composición del botón 'enviar' del formulario"

34.3.18. Demostración 8: consideraciones previas

34.3.19. Demostración 9

Ponemos las etiquetas "required" (necesario) donde correspondan.

li.required span.note {
   display: block;
   width: auto;
   float: right;
   color: rgb(128,128,128);
   font-size: .714em;
   line-height: 2.4em;
   font-style: italic;
}

Archivo fuente de: "Mover las etiquetas 'required' de manera que queden tocando en el margen derecho teórico del formulario y cambiar sus propiedades de texto"

34.3.20. Demostración 9: consideraciones previas

34.3.21. Demostración 10

Finalmente, ha llegado el momento de establecer las colisiones de los controles radio con los campos que hay debajo en el orden de las fuentes.

fieldset label {
   margin-right: .25em;
   padding-right: 0;
   line-height: 1;
}
fieldset .rInput { margin-right: .75em; }
fieldset label, fieldset .rInput {
   width: auto;
   display: inline;
   float: none;
   font-size: .857em;
}
li.required fieldset {
   width: 18.857em;
   float: left;
}

Archivo fuente de: "Alinear los controles radio y sus etiquetas horizontalmente"

34.3.22. Demostración 10: consideraciones previas

34.3.23. Demostración 11

Finalmente, para acabar como unos señores y conseguir que los últimos detalles queden alineados como es debido...

#acctTypeField fieldset {
   padding: .286em 0 0 0;
   line-height: normal;
}
#acctTypeField .rInput { margin-top: .167em; }
#availabilityField label {
   height: 3.143em;
   padding-top: .286em;
   line-height: normal;
}
#availabilityField .rInput { margin-top: .286em; }
#availabilityField, #messageField {
   height: 1%;
   overflow: auto;
}

Archivo fuente de: "Retocar los últimos detalles en varios controles"

34.3.24. Demostración 11: consideraciones previas

34.3.25. Demostración 12

Todos los estilos anteriores se han desarrollado para Opera o Safari (elegid el que queráis, ambos se comportaron bastante bien). Los que se mencionan a continuación son específicos de Internet Explorer, especificados en un fichero CSS enlazado con link en un bloque de comentario condicional.

h3 { margin-bottom: 1.2em; }
li { margin: 0 0 -.214em 0; }
   select { height: 1.429em; }
   textarea { height: 4.571em; }
fieldset {
   height: 1.583em;
   padding-top: .417em;
}
.medium { width: 13.429em; }
select.medium { width: 13.714em; }
.long { width: 20.286em; }
fieldset .rInput { border: 0 !important; }
#subjectField { margin-bottom: -.214em; }
#availabilityField .rInput { margin-top: .286em; }
#messageField { padding-bottom: .286em; }
input.submitButton { margin-top: .15em; }
* html input, * html textarea { float: left; }
* html select { font-size: .643em; }
* html select.medium { width: 21.364em; }
* html textarea { height: 4.643em; }
* html #subjectField {
margin-top: .071em;
margin-bottom: 0;
}
* html #availabilityField label { padding-top: 0; }
* html input.submitButton { margin: .1em 0 0 7em; }

Archivo fuente de: "Página completa"

34.3.26. Demostración 12: consideraciones previas

34.4. Establecer capas de soporte de plataforma

El último subapartado de demostraciones presenta el tipo de estilos reservados para Internet Explorer 6 y 7 y nos lleva a hablar de cómo un buen equipo de diseño trata navegadores de muy diferentes tipos.

La realidad de la web es que los usuarios utilizan una amplia variedad de navegadores en toda clase de entornos. Algunos son antiguos y otros son de rabiosa actualidad. Los hay que funcionan en ordenadores convencionales y los hay que funcionan en aparatos portátiles como teléfonos móviles. Todos ellos se desarrollan con sistemas operativos específicos y después se adaptan a otros con diferentes niveles de aceptación de estándares. Excepto Opera, todos los fabricantes de navegadores venden productos pensados para ser utilizados junto con otros títulos de una gran gama de productos, un requisito de producto que hace que los navegadores sean más complejos de lo necesario sólo para navegar por la Web.

Como si no hubiera bastante con pensar en las múltiples y variadas ventajas y desventajas de los navegadores, también se deben tener en cuenta los errores: errores de seguridad, errores de componentes y, sobre todo, los errores de representación. Los usuarios de Safari 3.x han descubierto que, en un punto, el documento de demostración descubre un molesto error de representación en su propio navegador.

La mejor manera de solucionar estos problemas es definir capas de soporte. El primero en promulgar este método fue el equipo de desarrollo de interfaz de Yahoo!, que lo denomina Graded Browser Support.

Por norma general, las capas de soporte se dividen en cuatro grandes categorías:

  1. El sitio web se representa tal como se diseñó originalmente dentro de los límites de las capacidades de estos navegadores y acepta todas las funciones. La plataforma de desarrollo define lo que en ocasiones se llama el nivel "A+".

  2. La desviación respecto de la composición preferente es evidente, quizá hasta un nivel destacado; sin embargo, el sitio web aún se puede utilizar y acepta la mayoría o todas las funciones del sitio.

  3. El sitio web que se presenta a los usuarios de estos navegadores es el más sencillo que se puede hacer sin estropear la marca del propietario del sitio, y es posible que determinadas funciones del sitio queden inactivas. Estos navegadores tienen unas bases de instalación comparativamente pequeñas, y se los considera anticuados, inestables o faltos de funciones.

  4. Este nivel de aceptación, que en la documentación de Yahoo! se denomina "X Grade" o de grado X, se reserva para las plataformas sin comprobar, es decir, habitualmente para los navegadores más nuevos con bases de instalación pequeñas (generalmente Opera, claro). Una vez probados, estos navegadores promocionan a una capa superior.

Los detalles del proceso de recopilación de requisitos que informan la definición de los niveles de soporte y asignan navegadores tienden a ser larguísimos y muy aburridos y, por lo tanto, se omiten de este apartado, que ya es bastante largo.

34.5. Composiciones de formulario complejas en la práctica (... en lugar de en teoría)

Entre las consideraciones previas proporcionadas anteriormente, se ha afirmado que las demostraciones se han organizado por el orden del código fuente de la hoja de estilo en lugar de por el orden en el que de hecho se añadieron las reglas a la hoja de estilo. Los motivos para hacerlo son:

El programa Opera 9.6 para OS X fue el agente de usuario que se utilizó para el desarrollo; con esta advertencia y las anteriores, a continuación se presenta el orden general en que se hicieron los cambios y las añadiduras en la hoja de estilo:

  1. Se aplican los estilos del documento (es decir, body).

  2. Se restablecen los valores predeterminados de lista, formulario y fieldset.

  3. Se especifica la tipografía.

  4. Se limita y se aplica clear a los elementos de la lista.

  5. Se aplican las labels en general.

  6. Se especifica y normaliza la composición de los controles del formulario (sobre todo los tamaños).

  7. Se crea el botón de enviar.

  8. Se aplican los casos límite.

  9. Se prueba Safari y Firefox y se cambian los valores de la hoja de estilo para reflejar los compromisos (allí donde se puede).

  10. Se prueba Internet Explorer 6 y 7 y se les suministran ajustes de propiedad/valor en una hoja de estilo condicional.

El proceso que se acaba de describir empieza con las reglas más generales y va pasando a las más concretas hasta llegar a solucionar los pequeños problemas específicos de navegadores determinados... de manera muy parecida al orden del código fuente de la hoja de estilo en sí. Sin embargo, los resultados no se correlacionan a la perfección. Esto sucede porque los diferentes motores de representación y las peculiaridades de elementos como el contexto float conllevan consecuencias imprevistas cuando se mezcla todo, de modo que el proceso real va más allá de realizar unas cuantas comprobaciones, retoques y reconsideraciones.

Resumen

Este apartado proporciona una base completa para aplicar estilos y composición en los formularios, pero es posible ir más lejos todavía. Las dificultades que plantean los sistemas operativos (cuyos componentes se utilizan para crear los controles de formularios web) y las diferencias entre motores de representación aumentan el reto que supone para un especialista en estilos crear un formulario web según una serie de especificaciones. Este apartado deja la puerta abierta a la experimentación con la multitud de pequeños problemas asociados con esta tarea y muestra la manera de conseguir un buen nivel de dominio en uno de los aspectos más complicados del arte de diseñar webs.

Preguntas de repaso

Preguntas a las que deberíais poder responder:

  1. ¿Cuál es el tipo de flujo de los controles de formulario que acepta datos introducidos por el usuario y cuáles son las dos características que los hacen destacables en cuanto a la composición?

  2. ¿Qué dos atributos aparte de value (valor) y disabled (desactivado) manipulan la configuración de los controles de formulario de antemano de la interacción con el usuario y a qué elementos se aplican?

  3. Este apartado de demostraciones os proporciona los campos obligatorios. Escribid como mínimo una regla de estilo que, de una vez, pueda cambiar el aspecto de un campo que incluya un error u omisión de introducción de datos del usuario.

  4. Describid un caso de uso del elemento select, del control checkbox y del control radio. Confirmad cada descripción con una explicación de las ventajas que ofrece vuestra elección comparada con otras opciones posibles.

  5. Utilizando una referencia en línea elegida por vuestro instructor, encontrad y describid brevemente alternativas a input type="submit".

  6. Cread un elemento select que permita seleccionar múltiples options añadiendo la pareja atributo/valor de multiple="multiple". Después de examinar el comportamiento de este elemento, explicad por qué casi no se lo encuentra nunca en los lugares de producción.

Tabla: conversiones de fracciones a decimales

En la tabla de conversiones de fracciones a decimales que os presentamos aquí, los dígitos que se incluyen entre paréntesis con un asterisco detrás se repiten hasta el infinito; por ejemplo, 0,2(6*) es equivalente a 0,266666666666666... (el 6 es periódico).

Los valores más próximos a cero se encuentran a la izquierda de la tabla y avanzan hacia el uno leyendo la tabla de izquierda a derecha.

Lecturas complementarias

Logo Creative Commons
Los contenidos recogidos en este artículo están sujetos a una licencia Creative Commons
Reconocimiento, No comercial - Compartir bajo la misma licencia 3.0 No adaptada.
: Ir al índice :