• 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.

Si necessitem saber si una variable ha estat declarada però sense valor assignat, podem comparar-la amb el “valor” undefined. Així podem veure:

var x;
// x === undefined retornaria cert
x = 5;
// x === undefined retornaria fals

Però si el que de debò volem fer és comprovar si aquesta variable ha estat definida en algun punt del script, no podem fer aquesta comprovació, ja que al intentar cercar el símbol “x” a la seva taula de noms, ens donaria un error de referència. Llavors, podem fer-ho o no? La resposta és sí! Només cal comprovar el seu tipus: si no té un tipus definit, vol dir que no està definida dins la taula de noms. Total, que podem fer:

// typeof(y) === undefined retornaria cert
var y;
// typeof(y) === undefined retornaria fals

I ja per acabar amb nota: com fer per saber si certa variable està definida directament en l’àmbit global de l’script? Doncs bé, com bé sabem, qualsevol variable definida a l’espai global, està també definida com un camp de l’objecte global. Llavors, els que ens dediquem a la programació web, i per tant tenim l’objecte window com a objecte global, podem fer la comprovació:

window.z === undefined
// retornaria cert si la variable z no ha estat definida

Doncs res, aquest ha estat el truc del dia. Espero que us sigui útil!

Cap allà als mitjans dels noranta, Internet Explorer 4.0 introduí aquest event no estàndard, però a diferència d’altres ocasions, aquest cop feu una cosa útil i els navegadors amb motor Gecko ho acabaren introduint a la versió 1.7 de Mozilla (Firefox 1.0).

Aquest event, tal i com resa el seu nom, es dispara just abans de l’event onunload, és a dir, abans que es descarregui el contingut actual de la pàgina, i per tant, ens permet executar algun tipus d’acció en aquest moment.

A diferència dels altres events, aquest funciona força diferent: per tal de mostrar un missatge a l’usuari abans de descarregar la pàgina, el que cal fer és retornar una cadena amb el missatge que es vulgui mostrar. Un exemple podria ser:

window.onbeforeunload = function(e) {
  return "No heu enviat el formulari. Si tanqueu la pàgina perdreu tots els canvis fets fins ara.";
}

Així, en cas d’abandonar la pàgina, se’ns mostraria un quadre amb el missatge:

Esteu segur que voleu sortir d’aquesta pàgina?

No heu enviat el formulari. Si tanqueu la pàgina perdreu tots els canvis fets fins ara.

Premeu D’acord per a continuar, o cancel·la per a romandre a la pàgina actual

Les frases que hi ha just abans i després de les nostres les posa el navegador (en aquest cas Firefox) i no es poden eliminar, substituir ni evitar de cap tipus de les maneres.

Val a dir que en cas que el navegador no tingui implementat aquest event, aquests simplement l’ignoraran i no mostraran pas el missatge a l’usuari.

Pàgines protegides

Recapitulem. La raó principal d’aquest article és que fa poc a la feina em varen demanar que implementés una funcionalitat per a protegir pàgines: volien poder mostrar un missatge quan un usuari intentés abandonar la pàgina enmig d’un formulari dins d’un procés amb un cert flux o bé intentés abandonar una pàgina, la construcció de la qual fos molt costosa. Un exemple ideal per a treure l’event onbeforeunload de la nostra cartera de recursos. Anem a construir-ho.

Per tal de poder marcar si una pàgina la tractem com a protegida o no, és a dir, si registrem l’event onbeforeunload per mostrar un missatge a l’usuari en cas d’abandonar la pàgina, afegirem la classe protected a l’element /body de la pàgina:

<body class="protected">

Així, si usem jQuery, podem afegir les següents línies de codi per a tenir-ho fet:

$('body.protected').each(function () {
  window.onbeforeunload = function(e){
    return "Si abandones, ho perdràs tot per sempre!";
  };
});

Però tenim un petit inconvenient: si fem clic en un enllaç o si enviem el formulari fent clic a un botó, se’ns mostrarà el missatge, cosa que volem evitar. Això es pot resoldre inhabilitant l’event en cas de fer clic a certs elements:

$('body.protected p.botons input, body.protected a.sense-onbeforeunload', context).click(function () {
  window.onbeforeunload = null;
});

I així de fàcil obtenim el que busquem. Fàcil, oi? I segur que a més d’un li sembla útil, i fins i tot, més que necessari en alguna situació quotidiana.

Recursos

• Onbeforeunload event. Internet Explorer Developer Center
• Window.onbeforeunload. Mozilla Developer Center
• onbeforeunload: tiende una mano al usuario

Per a exemplificar la construcció, crearem un petit giny per a construir contingut tabulat en pestanyes.

Partim d’un fragment HTML com el següent:

<div class="pestanyes">
  <h2>Pestanya 1</h2>
  <div>
    ...contingut...
  </div>
  <h2>Pestanya 2</h2>
  <div>
    ...contingut de la segona...
  </div>
  <h2>Pestanya 3</h2>
  <div>
    ...i una mica més...
  </div>
</div>

Si ens centrem en el giny, podríem redactar una petita explicació funcional com la següent:

• En estat de repòs, es mostren les pestanyes amb la primera activa i només es mostra el contingut relacionat amb aquesta.
• Una vegada cliquem a una pestanya, aquesta passa a ser l’activa i el contingut que es mostra passa a ser el relacionat amb aquesta.

Ara només falta traduir això a codi JavaScript.

Comencem creant l’estructura general del plugin:

$('.pestanyes').each(function() {
  ...
});

I les estructures necessàries per a crear el giny. Primer de tot caldrà amagar les capçaleres i el contingut d’aquestes i crear l’estructura per a les pestanyes que a nosaltres ens sigui còmode de treballar-hi. Per exemple una d’ideal seria una senzilla llista <ul><li>...</li></ul>.

Anem a passar tot això a codi JavaScript:

$('div.pestanyes').each(function () {
  // creem una referència a les capçaleres i al contingut de les pestanyes
  var $headings = $('h2', this);
  var $content = $headings.next();

  // amaguem les capçaleres i els continguts
  $headings.hide();
  $content.hide();

  // creem l'estructura de les pestanyes
  var tabHtml = '';
  $headings.each(function() {
    tabHtml += '<li>' + $(this).text() + '<\/li>';
  });

  // i l'afegim al document
  $(this).prepend('<ul class="tabs">' + tabHtml + '<\/ul>');
}

Una vegada creada l’estructura, només queda marcar l’estat inicial amb la primera pestanya i el seu contingut relacionat com a actius:

var $tabs = $('ul.tabs li');
$tabs.eq(0).addClass('active');
$content.eq(0).show();

Ara només ens queda centrar-nos en la interacció amb les pestanyes. Quan un usuari faci clic en una pestanya, cal resetejar l’estat actual (eliminar la marca d’actiu) i marcar la pestanya que s’ha clicat com a activa, juntament amb el seu contingut relacionat.

$tabs.click(function() {
  // eliminem la classe i amaguem el contingut
  $tabs.removeClass('active');
  $content.hide();

  // marquem la pestanya activa i mostrem el contingut que calgui
  $(this).addClass('active');
  var tabIndex = $tabs.index(this);
  $content.eq(tabIndex).show();
});

Si ho posem tot junt, podem veure el resultat i una aplicació a un cas a l’exemple.

Però fins aquí no hem fet res de res per construir un plugin. Posem-nos a treballar-hi.

Adaptació del codi per a ser un plugin vàlid

Quan pensem en crear un plugin jQuery, el que ens ve al cap és crear una funcionalitat reutilitzable dins del domini d’un objecte jQuery, és a dir, estendre l’objecte. Així, si ens centrem en el nostre exemple, la idea és acabar creant un codi tal que per poder crear un contingut tabulat, hàgim d’escriure simplement:

$('div.pestanyes').tabs();

Si el que volem és estendre l’objecte jQuery el que haurem de fer, igual que en qualsevol altre objecte JavaScript, és afegir una nova propietat al seu objecte prototype. Així, una cosa d’aquest tipus seria vàlid:

$.prototype.tabs = function () {
  // el nostre codi
}

Però si hagués decidit fer-ho així, ja s’hauria acabat l’entrada, i aquesta no és pas la idea.

Si mirem les primeres línies de la biblioteca jQuery, podem veure la creació d’un alies força interessant:

jQuery.fn = jQuery.prototype

Així, si volem usar aquesta notació, podem ampliar directament l’objecte tot fent:

$.fn.tabs = function () {
  // el meu codi
  return this;
}

S’ha afegit el retorn del propi objecte per a poder permetre l’encadenament de crides:

$('#element')
  .tabs()
  .mesCoses();

El plugin que estem construint és força senzill, però què passaria si tinguéssim variables globals, funcions auxiliars i demés? Alguna cosa com aquesta:

var foo = 0;
$.fn.myPlugin = function () {
  foo += 5;
  myMethod();
  return this;
}
function myMethod() {
  ...
}

Amb aquest escenari, algú sense gaires llums (o amb ganes de tocar la pera) podria usar el plugin des la següent forma (i des de l’espai global de noms):

var myMethod = 'bar';
$('#element').myPlugin();

Però per sort, nosaltres tenim un as sota la màniga anomenat closure. Així, podem englobar tot el codi del nostre plugin dins d’una funció anònima:

(function () {
  var foo = 0;
  $.fn.myPlugin = function () {
    foo += 5;
    myMethod();
    return this;
  }
  function myMethod() {
    ...
  }
}) ();

Sembla que tot ja està fet, no? Queda un últim punt. Per a assegurar la compatibilitat amb d’altres biblioteques, no podem usar l’àlies de l’objecte jQuery $ així com així, sinó que hauríem d’usar jQuery com a mètode d’accés a l’objecte. Però això no és gaire còmode, no? Tranquils! Aprofitant que tenim la funció anònima englobant el nostre codi, podem crear un àlies segur per a jQuery fàcilment passant-lo com a paràmetre d’aquesta:

(function($) {
  ...
})(jQuery);

Ara ja estem en condicions de crear el nostre primer plugin. Podeu veure el codi resultant a l’exemple.

Ampliacions

Una vegada que tenim el plugin funcionant, ens podem centrar en fer-lo més real. El primer que ens podem preguntar és: què és un plugin sense opcions? Doncs si en volem, només cal donar-li un parell de voltes i fet.

Considerem dues opcions de configuració:

• Pestanya activada per defecte, que serà un enter (per defecte 0) que indicarà l’index de la pestanya (activatedIndex)
• Efecte visual al canviar de pestanya, que serà el nom d’una funció (per defecte null) dins l’espai de noms de l’objecte jQuery (animation)

I si ho afegim al codi que ja tenim:

$.fn.tabs = function (options) {
  var config = $.extend({
    activatedIndex: 0,
    animation: null
  }, options || {});

  ...
}

Ara el mètode tabs accepta un paràmetre que és un objecte de configuració. S’usa el mètode $.extend per tal d’estendre un objecte amb els valors per defecte amb els passats com a paràmetre.

Ara, els únics canvis que cal fer són força trivials. Pel cas de l’índex de la pestanya a activar:

// marquem la pestanya i el contingut desat a la configuració com actiu
var $tabs = $('ul.tabs li');
$tabs.eq(config.activatedIndex).addClass('active');
$content.eq(config.activatedIndex).show();

I pel cas de l’animació al canviar de pestanya:

if(config.animation) {
  $content.eq(tabIndex)[config.animation]();
} else {
  $content.eq(tabIndex).show();
}

I per acabar, només falta veure-ho tot ajuntat i funcionant al seu exemple corresponent.

Fonts

No creieu pas que sóc un geni. Ni molt menys. Aquesta entrada està basada en una de molt millor del meu amic Choan, el qual em va iniciar en el meravellós món del JavaScript. Només he volgut explicar-ho des de la meva òptica, usant alguna que altra alternativa de notació i amb un exemple ben diferent.

<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.

Si treballem amb JavaScript d’una forma intensiva és normal usar alguna biblioteca que ens ajudi en algunes tasques del dia a dia d’interacció amb DOM, events i demés; i una de les biblioteques més populars actualment és jQuery (que és també la que uso jo normalment als meus projectes).

El cas que ens ocupa és una de les funcions de principals de manipulació del DOM: append. Imaginem-nos que tenim un codi semblant a aquest:

$('div.el-que-interessa').append('<span class="foo">');

Doncs bé, des de Firefox, per exemple, l’element /span sí que serà afegit, però en canvi a Internet Explorer no ho serà pas. Aquest darrer requereix que el fragment que es vulgui afegir mitjançant aquesta funció sigui XHTML. Així hauria de quedar una cosa com aquesta:

$('div.el-que-interessa').append('<span class="foo"><\/span>');

No sembla pas una cosa gaire complexa de detectar i solucionar, oi? Doncs donem-li una volta més de rosca…

Imaginem-nos que volem afegir opcions a una llista desplegable de forma dinàmica, i tenim un codi com el següent:

$.each(opcions, function(clau, valor) {
    $llista.append(new Option(valor, clau));
});

És correcte o no és correcte aquest codi? Per saber-ho, hauríem de modificar la pregunta i fer-la més o menys així: quin HTML ens retorna el constructor de la classe Option?

var opt = new Option('Catalunya', 'CT');
// opt: <option value="CT">Catalunya

Doncs bé, com podeu veure, el codi retornat per l’objecte no és pas en format XHTML, i per tant, no funcionarà a Internet Explorer. Per aconseguir el correcte funcionament, no tenim cap més opció que inserir l’opció en format text:

$.each(opcions, function(clau, valor) {
    $llista.append('<option value="' + clau + '">' + valor + '<\/option>');
});

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.

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.

* {...}
e {...}
e f {...}
e > f {...}
e, f {...}

Però dins l’àmbit de selectors, hi ha tot un món de possibilitats que ens poden ajudar molt al nostre dia a dia (sinó, doneu-li un cop d’ull a l’apartat de selectors de l’especificació de CSS2¹ o de CSS3).

Del gran conjunt de selectors, en aquesta entrada vull parlar una mica i posar diversos exemples de com treure-li profit als selectors d’atribut. Abans de continuar, i per variar una mica, aquest tipus de selectors no funcionen en Internet Explorer 6 o anterior.

Els selectors d’atribut són els següents:

Per exemplificar l’ús d’aquest tipus de selectors, prendrem com a cas d’ús la personalització d’enllaços en diferents situacions.

Per exemple, i tal i com es fa en aquest bloc amb els enllaços, podríem voler adjuntar de forma visible pel lector quin és l’idioma de la pàgina enllaçada. Aquí ho fem amb la següent regla:

a[hreflang]:after {
  content: " ["attr(hreflang)"]";
  font-size: 0.8em;
}

Seguint l’exemple dels idiomes, podríem voler marcar l’enllaç d’un cert idioma amb una icona gràfica al seu voltant. Per exemple, en el cas del català, ho podríem fer de la següent manera:

a[hreflang="ca"] {
  background: url(icona-catala.png) no-repeat right center;
  padding-right: 1em;
}

Seguint amb aquests exemples, imaginem-nos que tenim un enllaç on el seu atribut rel té el conjunt de valors friend met co-worker muse i volem caracteritzar els amics amb una icona especial al costat de l’enllaç. Doncs bé, ho podríem fer amb el següent codi:

a[rel~="friend"] {
  background: url(icona-amic.png) no-repeat right center;
  padding-right: 1em;
}

Si ens interessés destacar amb alguna icona, tots els enllaços que tinguessin com a destí el W3C, podríem fer servir el següent codi:

a[href^="http://www.w3c.org"] {
  background: url(icona-w3c.png) no-repeat right center;
  padding-right: 1em;
}

O per exemple, si volguéssim posar-li una icona del format del fitxers enllaçat, podríem usar el següent codi pel cas del PDF:

a[href$=".pdf"] {
  background: url(icona-pdf.png) no-repeat right center;
  padding-right: 1em;
}

Seguint amb tot això, si volem tenir un enllaç caracteritzat si el seu atribut title o l’href conté la paraula “css”, podem usar el següent codi:

a[title*="css"][href*="css"]:after {
  color: #000;
  content: " (enllaç sobre CSS)";
  font-size: 0.8em;
}

I per acabar amb el darrer selector i tornant amb els exemples de la caracterització d’enllaços segons el seu idioma, podríem voler caracteritzar tots els enllaços en anglès amb una icona, independentment de si és anglès americà (en-US) o el general (en):

a[hreflang|="en"] {
  background: url(icona-angles.png) no-repeat right center;
  padding-right: 1em;
}

Amb tots aquests exemples, es pot veure que gràcies a aquest selector, se’ns obra tot un món de possibilitats a l’hora de caracteritzar diversos elements.

div#contenidor {
  /* estils per a IE6 i anteriors */
}

div[id="contenidor"} {
  /* estils per als altres navegadors */
}

Com a la majoria de llenguatges de programació, en javascript pots declarar una variable com a global, definida en tot l’àmbit del codi javascript, o com a local, definida només dins de l’àmbit de la funció que la defineix.

var a = 0;        // variable global
function foo() {
  var b = 1;      // variable local
}

Cal tenir sempre en compte que una variable local sempre té precedència davant d’una variable global, és a dir, si una paràmetre d’una funció o una variable declarada dins del seu àmbit té el mateix nom que una variable global, aquesta darrera queda oculta per la nova declaració.

var ambit = 'global';    // Declarem una variable global
function foo() {
  var ambit = 'local';   // Declarem una variable local
  document.write(ambit); // Usem la variable local
}
foo();                   // Imprimeix 'local'

Fins aquí tot força senzill, no? Però si us fixeu, encara no he dit res sobre la paraula reservada var.

Javascript ens deixa usar variables sense haver-les de definir amb la paraula var, però què passa si no ho fem? Doncs bé, si l’interpretador troba que s’està assignant un valor en una variable que no està declarada, la declara com a global i llavors li assigna el valor. Llavors cal tenir en compte que sempre que vulguem declarar una variable local, hem d’usar var.

ambit = 'global';              // Declarem una variable global (sense var)
function foo() {
  ambit = 'local';             // Ostres! Hem canviat el valor de la variable global!
  document.write(ambit);       // Usa la variable global
  nou_ambit = 'local';         // Declarem una nova variable global
  document.write(nou_ambit);   // Usa la nova variable global
}
foo();                         // Imprimeix 'locallocal'
document.write(ambit);         // Imprimeix 'local' (el valor s'ha canviat dins la funció)
document.write(nou_ambit);     // Imprimeix 'local' (la variable s'ha creat a la funció però amb àmbit global)

En general, una funció no sap quines variables estan definides en l’àmbit global i quines no. Així, si una funció usa una variable global en comptes d’una local sense saber-ho, pot estar modificant un valor que pot afectar a d’altres parts del programa. Per sort, la solució a tota aquesta problemàtica és ben senzilla: declareu sempre totes les variables amb var.

Però si seguim estirant del fil, podem trobar altres coses curioses relacionades amb l’àmbit de variables.

A diferència d’altres llenguatges de programació, javascript no defineix l’àmbit d’una variable a nivell de bloc (només existeixen àmbits a nivell global o local!). Així, totes les variables declarades dins d’una funció, sigui on sigui, estan definides a nivell de tota la funció. Si mirem el següent codi podrem entendre-ho:

function foo(a) {
  var i = 0;                       // i està definida a tota la funció
  if (a == 5) {
    var j = 23;                    // j està definida a tota la funció, no només en aquest bloc
    for(var k = 0; k < 20; k++) {  // k està definida a tota la funció, no només en aquest bucle
      document.write(k);
    }
    document.write(k);             // k està definida, i té valor 20
  }
  document.write(j);               // j està definida però pot ser que no estigui inicialitzada
}

Cal tenir en compte que el fet que una variable declarada dins d’una funció està definida per tota la funció pot donar-nos alguna que altra sorpresa. Per exemple:

var ambit = 'global';
function foo() {
  alert(ambit);          // Mostra 'undefined', no pas 'global'
  var ambit = 'local';   // Variable inicialitzada aquí, però definida en tot l'àmbit de la funció
  alert(ambit);          // Mostra 'local'
}
foo();

Pot semblar-nos que el primer cop que es crida a la funció alert() hauria de mostrar-nos “global” ja que la declaració de la variable local encara no s’ha executat. Però si tenim en compte les regles d’àmbit que he anat explicant, la variable local està definida en tot l’àmbit de la funció, ocultant la variable global que du el mateix nom. Però igualment, encara que la variable local està definida, aquesta no està inicialitzada fins que no s’executa la sentència var. Així, la funció foo() anterior és equivalent a la següent:

var ambit = 'global';
function foo() {
  var ambit;             // La variable local es defineix a l'inici de la funció
  alert(ambit);          // En aquest punt existeix, però té valor 'undefined'
  var ambit = 'local';   // En aquest punt la inicialitzem i li donem un valor
  alert(ambit);          // Aquí ja té valor!
}

Amb aquest exemple il·lustra perfectament el perquè és una bona pràctica el declarar totes les variables a l’inici de cada funció.