Facilitant la web

Els que ens dediquem a sistemes client-servidor, més específicament, a sistemes basats en web,  sovint ens trobem amb la necessitat de construir formularis que executin accions a partir d’una entrada. És ben normal, que un client o un funcional proclami:

• Vull que el número d’identificació sigui obligatori!
• El correu electrònic ha d’estar en el format correcte!

O altres típics requeriments que requereixin de fer una validació del formulari.

Davant d’aquest escenari, el primer que ens ve al cap és fer les validacions amb JavaScript a la capa client. Bé, no està malament. Fer les validacions a la capa de client, és ràpid en temps de computació, senzill (normalment) i proporciona una resposta ràpida a l’usuari, fet pel qual assegurem una bona experiència d’usuari mentre introduïm dades. Una de les primeres normes de la usabilitat a formularis és: com més aviat sàpiga l’usuari que s’ha equivocat, més aviat podrà reaccionar-hi (compte amb la interpretació d’aquesta frase made-by-me!). Però mai hem d’acabar aquí!

Fer les validacions només a la capa client és una decisió completament errònia. On de debò s’han de fer aquestes comprovacions és a la capa servidor. Allà és on s’ha de mirar si cert camp existeix, si el format de tal camp és el correcte, de si la relació entre dos camps és correcta, etc. És a la capa servidor on tot aquest algorisme s’ha d’executar per prevenir qualsevol error que pugui tenir l’aplicació. És allà on s’executa la lògica de l’aplicació i on les validacions, com part d’aquesta lògica que són, s’han d’executar. Si només ho féssim a client, què passaria si no tinguéssim disponible el JavaScript? Quin seria el comportament de l’aplicació? Possiblement, acabéssim en un estat d’inconsistència no desitjat per ningú.

Sovint quan es planteja aquest argument (validacions dobles a capa client i servidor), molts arquitectes d’aplicacions (remarco la paraula perquè és el títol que es posen ells, no el que els hi posaria jo) posen el crit al cel i diuen la del porc argumentant que s’està fent una tasca dues vegades i que el rendiment de l’aplicació en general es veu ressentit. Si alguna vegada us trobeu davant d’això, només heu de dir:

D’acord, llavors, les validacions que es facin només a la capa de servidor!

Veureu com els hi canvia la cara

Cal tenir ben presents quines són les implicacions de deixar un processament de dades a una capa tan fràgil com pot ser un navegador, i la nostra tasca és argumentar i deixar ben clar el per què a client no és lloc per fer aquest tipus de processament.

Tingueu aquest consell sempre ben present perquè segur que al llarg de la vostra vida professional us caldrà utilitzar-lo més d’un cop.

Sovint ens interessa amagar contingut de la nostra pàgina a l’ull humà com pot ser el cas dels menús per a saltar a continguts de la pàgina, en l’ús de tècniques de reemplaçament de contingut per imatges o per ocultar capçaleres o elements estructurals de la pàgina. És veritat que ens interessa amagar-ho de l’ull humà, però el que no volem de cap de les maneres, és amagar-ho dels lectors de pantalla.

El típic error

Si donem una volta per la xarxa, el que sovint trobem escrit i recomanat, és l’ús de la propietat display: none per a ocultar elements. Amb això satisfem la nostra voluntat de que l’ull humà no percebi el contingut, però el problema és que sovint, els lectors de pantalla tampoc n’interpreten res.

Podríem dir que display: none significa que l’element no existeix: ni es mostra, ni s’imprimeix, ni es llegeix el seu contingut.

La solució

Una tècnica alternativa que es pot considerar és la de posicionar l’element que volem amagar de forma absoluta fora del viewport. Així, l’element existeix però no es percep per l’ull humà. El CSS que podem usar és:

.access {
    left: -9999px;
    position: absolute;
}

Amb això aconseguim el mateix efecte visual però sense ignorar a una part dels usuaris.

Tot això no és pas invenció meva, sinó que és una adaptació d’un article que vaig llegir fa uns dies.

Per temes de feina avui he hagut de fer un llistat d’arguments a favor i en contra de l’ús d’iframe en un desenvolupament web i m’he decidit a fer-la pública perquè tothom que vulgui pugui opinar-ne.

A favor

• Integració d’aplicacions. Permet integrar aplicacions externes a dins de la nostra pàgina.
• Disminució de peticions a servidor. Si tenim una part de la nostra pàgina que és costosa de construir (dins d’un entorn de pagines dinàmiques), podem posar-la dins d’un /iframe fent que no s’hagi de refrescar cada cop que canviem de pàgina (seguint una mica el model del ja deprecat element /frame).

En contra

• Forat negre. Al poder-hi posar tot el que vulguem, un /iframe pot arribar a ser un problema de seguretat si no som nosaltres els creadors del seu contingut.
• Accessibilitat. Existeixen navegadors que no suporten l’ús de l’element iframe.
• Lectors de pantalla. Hi ha navegadors que per defecte donen el focus al iframe en el moment de carregar la pàgina. Això és un problema per a la correcta lectura del document pels lectors de pantalla.
• Cercadors. Les aranyes dels cercadors no saben navegar correctament per les pàgines que usen marcs. Per tant, pot ser que el nostre lloc no sigui correctament indexat.
• Estructura del contingut. L’ús de l’element iframe trenca l’estructura lògica del contingut de la pàgina.
• Gran confusió al interactuar amb el navegador. Diverses interaccions de l’usuari amb el navegador es veuen greument modificades per l’ús de l’element iframe en una pàgina:
  • URL. La URL que es veu al navegador no és sovint la que correspon a la d’una pàgina creada amb marcs: si anem navegant dins del marc, la URL del navegador no canvia, però en canvi, la de la pàgina que estem veient sí que “ha canviat”.
  • Adreces d’interès. Lligat amb el punt anterior, si volem desar l’adreça de la plana, la que desarem serà la que es veu al navegador. Al tornar-hi veurem  que no és pas la mateixa plana que havíem desat (haurem perdut la navegació dins del marc). Tot i que hi ha navegadors que ens donen la possibilitat d’esbrinar l’adreça d’un marc, pot ser que l’usuari sigui no especialitzat i per tant, no sàpiga de l’existència d’aquesta possibilitat. Igualment, un usuari de la plana no ha de saber com està feta la pàgina, i per tant, saber com ha de fer-s’ho per desar l’enllaç  “correcte” a la plana en qüestió.
  • Resultats d’una cerca. Si accedim a una pàgina feta amb marcs des d’un resultat d’un cercador extern, pot dur-nos a una adreça  “incorrecte”: podem anara a l’adreça d’un marc, on veurem el contingut d’aquest però sense el contingut del seu “pare”.
• Alçada fixa. Un iframe té alçada fixa, i per tant, pot ser que ens aparegui una barra de desplaçament lateral en cas que el contingut ocupi més espai del reservat per l’atribut @height del marc.

Alternatives

En cas que usem marcs només per temes estètics no tenim excusa per abandonar-los, ja que el seu aspecte es pot replicar 100% amb CSS.

Si usem marcs per tal de poder deixar una part de la nostra pàgina fixa mentre fem scroll de la pàgina, podem usar la propietat position: fixed de CSS tal i com s’explica en aquest article.

En canvi, si el que volem és que cert contingut de la pàgina tingui una barra lateral per poder navegar dins seu, podem usar la propietat overflow tal i com s’explica en aquest altre article.

Conclusions

A data d’avui, i a no ser que sigui algun motiu de rendiment o d’integració, l’ús de marcs no està justificat en un inici, ja que provoca més desavantatges que no pas avantatges. Sovint la necessitat d’aquest element recau més per un tema gràfic que no pas per un tema funcional, cosa que com ja hem vist, es pot resoldre amb l’ús de fulls d’estils.

Hi ha moments a la vida d’un programador d’interfícies web (mal anomenats sovint com a maquetadors) que vol crear un component que tingui una certa aparença segons si el navegador amb que es visualitza té el javascript habilitat o inhabilitat.

Posem un exemple. Imaginem-nos que estem creant un botó d’imprimir “especial”. El que volem aconseguir és que al fer clic a la icona d’exportació de la nostra pàgina, es desplegui un menú d’opcions on ens permeti obtenir la vista actual en PDF, en XML o en HTML sense estils (per posar un exemple). Com som bona gent i ens preocupa de debò l’accessibilitat, volem que, en cas de tenir el javascript inhabilitat o no disposar de suport per aquest, el que es visualitzi sigui el literal “Exportar a “, i la llista d’opcions que he explicat abans, una darrera l’altra. Total, que el nostre component ha de tenir dues representacions diferents, és a dir, dos conjunts d’estils ben diferents.

I com fer que un component tingui dues representacions? Doncs bé, jo explicaré aquí la tècnica que jo uso al meu dia a dia.

El que farem serà marcar el document amb una classe en cas que tinguem javascript habilitat, i així, des del nostre full d’estils, podrem diferenciar entre una representació i l’altra de la següent forma:

.element-que-interessa {
    /* Aquí van els estils per l'element en cas de no disposar de suport javascript */
    ...
}

.marca-document .element-que-interessa {
    /* Aquí van els estils per l'element en cas de disposar de javascript */
    ...
}

Una vegada explicada la idea, anem a l’acció. Personalment, el que jo faig és marcar l’etiqueta /html amb la classe js al principi del fitxer javascript:

document.documentElement.className = "js";

I llavors, al full d’estil, usar aquesta classe per a diferenciar-ho. Aplicat al nostre exemple:

.menu-exportacio {
    /* estils de la representació quan no hi ha javascript */
}

.js .menu-exportacio {
    /* estils per a la representació amb javascript */
}

Cal tenir present que aquesta tècnica pot ser útil quan, per exemple, volem amagar alguna porció del nostre document en cas de disposar de javascript (per exemple les àncores al contingut, barra lateral i demés) o fins i tot, per a diferenciar els estils que s’aplicaran a elements introduïts al document de forma dinàmica mitjançant javascript.