Entrades etiquetades ‘html’

Separar la forma del contingut (nom de les classes)

dilluns 29 juny 2009

Es ben sabut per tots els que ens dediquem a la programació d’interfícies web (també anomenats maquetadors o programadors front end) que cal tenir ben present que sempre s’ha de separar el document (HTML) de la seva presentació en un medi concret (CSS) i dels components amb comportament que pugui tenir (JavaScript). Així, és fàcil veure que el següent fragment d’un document és completament incorrecte pel que fa a aquests cànons:


<div style="margin: 5px;">
    <em>Aquest contingut el vull en lletra cursiva</em>
    <small><a onclick="window.location='/lipsum'" href="http://www.example.com">Lorem ipsum dolor</a></small>
</div>

Normalment la majoria de programadors som ben conscients de la incorrecció del fragment anterior, però sovint ens trobem incorreccions d’aquest tipus completament encobertes, i sempre seguint el mateix patró: el mal ús dels noms de classe dels elements.

Usaré exemples de la xarxa per a il·lustrar el que vull dir. Si anem a la portada de la pàgina d’una institució molt important del país podem trobar coses així (canvio els texts per centrar l’atenció):


<ul id="ul_home">
	<li><a class="vermell_nobullet_2" href="http://www.example.com">Ipse quat erimo</a></li>
	<li><a class="vermell_nobullet_2" href="http://www.example.com/dog">Sailer due rit</a></li>
</ul>

<div class="marge_superior">
    <h2><span id="actualitat" class="titol_seccio">Lorem ipsum</span></h2>
</div>
<div id="altres_serveis" class="border_top">
    <div class="border_bottom">
        <a class="text_gris" href="http://www.example.com/bird">Dolor et sumum</a>
    </div>
</div>

El valor de l’atribut @class d’alguns dels elements ja ens dóna informació de com s’estilitzaran al veure-ho associat al seu full d’estils.

Però sovint no es veu tan fàcilment la incorrecció a l’assignació dels noms de les classes. Per exemple, és ben normal trobar-nos sempre al fragment de descripció de l’organització d’un document, classes del tipus:


<body class="3-columnes">
    <div class="columna-esquerra">
        Lorem ipsum
    </div>
    <div class="columna-central">
        Dolor set
    </div>
    <div class="columna-dreta">
        Icse et luopir
    </div>
</body>

Hi veieu res d’estrany? Per saber si les classes són reveladores de la forma final, només cal que us feu la següent pregunta: podríeu saber quina és la forma final de la pàgina només llegint l’HTML? Si la resposta és sí, les classes són errònies. Si és no, doncs la cosa ja està millor.

Per exemple, una forma correcte de fer la divisió del document podria ser:


<body class="layout-complet">
    <div class="contingut-primari">
        Lorem ipsum
    </div>
    <div class="contingut-secundari">
        Dolor set
    </div>
    <div class="contingut-terciari">
        Icse et luopir
    </div>
</body>

Oi que ara ja no us espereu com serà el document final?

Per tant, cal anar amb compte a l’hora d’assignar els noms a les classes. Sempre cal tenir ben present de separar la forma o presentació del contingut i anar una mica amb peus de plom a l’hora de cercar els valors. Així aconseguirem que els nostres documents siguin 100% independents de la forma en que es visualitzen.

Arguments a favor i en contra de l’ús d’iframes

dimarts 31 març 2009

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.