Skip to main content

Aggiungere un namespace a un foglio di stile per evitare conflitti tra file CSS

La crescente necessità di sviluppare siti responsive nel più breve tempo possibile ha provocato la comparsa e la diffusione, nel corso degli ultimi anni, di una serie di framework e/o boilerplate CSS avanzati come Bootstrap, Foundation, GumbyYAML, Skeleton solo per citare alcuni tra i più noti. Ciascuno di essi mette a disposizione dello sviluppatore un ampio ventaglio di classi predefinite che consentono di ottenere rapidamente lo scopo: rendere il proprio sito adatto alla visualizzazione su qualsiasi piattaforma e dispositivo mantenendo la piena compatibilità con tutti i browser desktop.

Un traguardo ideale… a patto che le classi non entrino in conflitto tra loro e/o con classi già definite all’interno altri fogli di stile.

Il problema.

Analizziamo, a titolo di esempio, un estratto delle classi messe a disposizione dal framework Bootstrap, ad oggi senz’altro il più noto e utilizzato:

… e la lista potrebbe continuare.

Inutile dire che ciascuna di queste classi presenta al suo interno numerose impostazioni che saranno con tutta probabilità incompatibili con classi aventi lo stesso nome definite in altri fogli di stile, siano essi creati da noi, parte di qualche plugin JQuery o portati in dote da qualsiasi altra libreria o modulo client-side.

La soluzione.

Il metodo più intuitivo per evitare problemi di questo tipo è rinominare le classi in conflitto, iniziando dalle proprie e, se la situazione lo richiede, proseguendo eventualmente con quelle dei plugin/moduli accessori. Tale approccio può essere preso in considerazione nel caso di un piccolo sito, ma è ben lungi dall’essere ideale nel caso di portali di dimensioni medio/grandi.

WHY.Jesse.Pinkman

L’approccio di tipo “search & replace” è in molti casi un’operazione delicata: effettuarla in modo automatico è estremamente rischioso, soprattutto in casi come questo dove si richiede un notevole livello di attenzione. Il sito potrebbe prevedere plugin, moduli o funzioni Javascript che utilizzano selettori di classe per svolgere il loro lavoro e che potrebbero sfuggire a una prima occhiata, come nell’esempio seguente:

In tutti i casi in cui l’approccio del “search & replace” rischia di  rivelarsi troppo oneroso è opportuno orientarsi verso una soluzione più robusta e a prova di errore. Quella che vi presentiamo consente di incapsulare qualsiasi foglio di stile – non importa se creato da voi, incluso nel framework o parte dei plugin installati – all’interno di un vero e proprio Namespace. Per far questo in modo efficiente dovremo utilizzare un pre-processore CSS tra quelli attualmente disponibile: i più noti e diffusi sono SASS, diffuso soprattutto in ambiente Linux, e LESS, particolarmente adatto per chi lavora Windows per via della integrazione con Visual Studio 2012 (e superiori) grazie all’ottima estensione Web Essentials.

Cos’è un pre-processore CSS? In estrema sintesi, si tratta di un compilatore che produce un foglio di stile .css partendo da un file .scss o .less : questo file non è altro che un foglio di stile arricchito da caratteristiche aggiuntive ottenute grazie a una sintassi proprietaria, che il compilatore si occupa di “riscrivere” in modalità compatibile CSS2/CSS3.

Ecco un breve esempio di come si presenta un file .less:

Ed ecco il file .css prodotto a seguito della sua compilazione:

Per una guida completa alla sintassi dei due pre-processori vi rimandiamo alle guide ufficiali presenti sui rispettivi siti:

In questo articolo ci limiteremo a mostrare la sintassi necessaria per creare il nostro namespace. Per nostra fortuna è del tutto identica per entrambi i linguaggi, con la sola eccezione dell’estensione dei file che cambia a seconda del pre-processore scelto.

Nell’esempio che segue abbiamo utilizzato .less:

Una volta compilato, questo file includerà l’intero contenuto dei due file .less menzionati al suo interno avendo cura di aggiungere la classe .namespace-name all’inizio di qualsiasi selettore contenuto. Questo significa che ciascuno di essi verrà preso in considerazione soltanto se utilizzato all’interno di un elemento contenitore (DIV, BODY o qualsiasi altro) recante la classe .namespace-name.

Una volta compreso l’esempio, vediamo come possiamo creare un namespace per le classi CSS fornite con il framework Bootstrap:

Le prime 5 regole di stile (quelle prima dei due @import) sono le stesse che il file bootstrap.css applica all’elemento BODY della pagina, e quindi potenzialmente ereditate da tutti gli altri elementi. Il modo migliore per riprodurre lo stesso identico effetto è quindi aggiungerle direttamente al nostro namespace.

Ecco un esempio di utilizzo del namespace creato secondo le convenzioni di cui sopra:

Come si può facilmente evincere dai commenti, gli stili utilizzati all’interno del div con classe “bootstrap” saranno gli unici ad essere applicati.

IMPORTANTE: Come si può vedere, è necessario che anche i file oggetto dell’importazione abbiano l’estensione corrispondente a quella riconosciuta dal pre-processore utilizzato. Se volete importare dei normali file .css basterà rinominarli in tal senso: del resto, come abbiamo detto, i file .scss e .less non sono altro che fogli di stile “arricchiti”. Se avete optato per .less potete risparmiarvi il rename: basterà utilizzare @import (less) in luogo di @import, come spiegato qui.

Felice sviluppo!

Hearthstone – Mazzo Mage Aggro [Low Budget]

Hearthstone-Goblins_vs_Gnomes

Ho recentemente pubblicato sul sito Hearthpwn.com un mazzo low-budget – ma al tempo stesso piuttosto efficace – che mi sta dando numerose soddisfazioni nella ladder EU. Se state cercando un mazzo poco “dispendioso” e con poche pretese per guadagnare qualche posizione nella vostra ladder potete pensare di dargli un’occhiata.

Il mazzo prevede due carte leggendarie: se non le avete (e/o non potete permettervele) potete rimpiazzarle con un altro Sludge Belcher + Stormwind Champion, oppure con la coppia Feugen + Stalagg, con un Archmage + Loatheb o con qualsiasi altra accoppiata di drop pesanti di cui disponete: in molti casi le sorti della partita verranno decise prima di poterli calare, quindi non faranno comunque troppa differenza.

Se volete effettuare qualche modifica sentitevi liberi di sostituire qualsiasi carta da 2 (tranne i due Knife Juggler, sui quali è imperniato l’intero deck) con un validissimo Nerubian Egg, che in questo mazzo è senz’altro azzeccato.

422.Knife-JugglerIl mazzo è piuttosto versatile e consente di impostare diverse strategie a seconda della pescata iniziale. Una possibile apertura può vedere un Knife Juggler calato nei primi due turni, eventualmente anticipando l’uso del mana crystal, seguito da qualche drop di creatura con deathrattle così da costringere l’avversario a eliminarlo con un removal spell lasciandovi il controllo della board – qualsiasi creatura a 1-2 salute rischierebbe infatti di essere eliminata dal knife e/o dal vostro potere eroe. Le cose non andranno male anche dando inizio alle danze con un Mana Wyrm o con un Undertaker, che potranno essere potenziati velocemente tramite incantesimi e/o drop con deathrattle: anche in questo caso l’avversario sarà costretto a prendere danni, rispondere con creature che lo porteranno a trade svantaggiosi o impiegare un removal spell su una vostra creatura da 1, sacrificando in tal modo tempo ed efficienza.

7737.Undertaker

Se riuscirete a tenere il vostro avversario sulla difensiva finirete probabilmente per mandarlo in vantaggio di carte, cosa che potrete compensare sfruttando la coppia di Arcane Intellect e il Loot Hoarder. Tenete presente però che il vostro vero obiettivo è quello di avere un costante vantaggio di creature e punti vita grazie al sapiente uso dei deathrattle e/o dei segreti mediante i quali potrete prevenire incantesimi di rimozione, copiare un drop dell’avversario e ottenere due copie di una vostra creatura eliminata direttamente in mano – cosa che può rivelarsi devastante se si tratta di un Knife Juggler o qualsiasi altra creatura di costo 4+ tra quelle giocate.

Nella maggior parte dei casi riuscirete a chiudere la partita entro i primi 9-10 turni: in caso contrario, se sarete riusciti a preservare un numero sufficiente di creature e/o carte e/o punti vita, avrete la possibilità di utilizzare almeno uno dei vostri due assi nella manica (Ysera e Kel’Thuzad) che, se non contrastati subito, risolveranno a vostro vantaggio qualsiasi situazione. Il mazzo fornisce anche una serie di removal (singoli e ad area) e un paio di Fireball per infliggere gli ultimi danni o per far fuori eventuali finisher dell’avversario.495.Ysera

Fate attenzione a utilizzare il Counterspell nel modo giusto, magari giocandolo nel turno immediatamente precedente a quello che consentirà all’avversario di giocare il suo AE removal di classe (è buona norma impararli tutti). Infine, fate del vostro meglio per utilizzare nel migliore dei modi le numerose “combo” offerte dalle meccaniche di gioco di Khel’Thuzad, del  Knife Juggler e/o dell’Undertaker, creature che possono fare disastri sia con altre carte che, soprattutto, insieme.

7742.Kel'Thuzad

Il deck è disponibile pubblicamente sul sito hearthpwn.com: qui trovate la lista completa delle carte.

Buon divertimento!

 

Utilizzare JQuery UI e Bootstrap nella stessa pagina web

Gli ultimi mesi hanno visto una diffusione capillare del framework Bootstrap, una libreria CSS/JS che consente di dotare qualsiasi sito web di tutte le funzionalità necessarie per rendere le proprie pagine mobile-friendly e, cosa ancor più importante, pienamente compatibili con tutti i device. Il Framework, oggi giunto alla versione 3.3.1, è dotato di una serie di plugin javascript che richiedono JQuery v1.9.0 o superiore: è quindi facile immaginare come si sia diffuso principalmente sui siti che includono quest’ultimo, i quali non di rado ospitano anche JQuery UI.

Utilizzare questi due framework insieme è possibile, ma occorre fare attenzione ad almeno due conflitti presenti tra le due librerie e che rischiano di produrre errori JS e/o di compromettere alcune funzionalità del sito. Si tratta dei plugin tooltip e button, entrambi presenti (con il medesimo nome) in ciascuna delle librerie.

Il Problema.

Prendiamo come esempio il plugin tooltip. Andiamo sul sito http://jqueryui.com/tooltip/ e diamo un’occhiata al codice di esempio (view source) per la creazione di un tooltip con JQuery UI:

Il testo evidenziato presenta una chiamata alla funzione tooltip che JQuery UI aggiunge a livello runtime per ogni oggetto JQuery. La stessa operazione viene effettuata da Bootstrap come si può vedere analizzando il codice del relativo tutorial:

Questo conflitto di nomi, oltre ad impedire a entrambi i plugin di funzionare, provoca una serie di errori Javascript variabili a seconda di quale libreria viene eseguita prima. Nel caso in cui Boostrap sia inserito dopo JQuery UI, ad esempio, l’errore che vedremo nella nostra Console Javascript sarà con tutta probabilità il seguente:

Uncaught TypeError: Cannot read property ‘documentElement’ of null

Dovuto al fatto che la sintassi del plugin di JQueryUI, solitamente utilizzato a livello di $(document), viene utilizzata per eseguire il plugin di Bootstrap.

 La Soluzione.

Il modo migliore per far convivere le due librerie risolvendo “in positivo” i conflitti di nomi è utilizzare il plugin $.widget.bridge che consente di poter ridefinire a piacimento questi ultimi. Il plugin è fortunatamente incluso all’interno di JQuery UI, quindi non appesantirà ulteriormente il nostro sito. Il suo utilizzo è molto semplice:

Queste istruzioni vanno ovviamente inserite nella pagina in modo sincrono dopo aver incluso il riferimento alla libreria JQueryUI e prima dello script di Bootstrap. Nell’esempio seguente vediamo un esempio completo di implementazione nel blocco <head> di una pagina web:

In conseguenza di questa operazione i metodi tooltip e button diventeranno una prerogativa di Bootstrap, mentre per utilizzare gli omonimi plugin offerti da JQuery UI sarà necessario utilizzare i nuovi alias uitooltip e uibutton.

Riferimenti:
http://stackoverflow.com/a/27745464/1233379 (la mia risposta sul sito StackOverflow che ha ispirato questo post).

WordPress: personalizzare (o rimuovere) l’Infinte Scroll Footer di Jetpack

Con il rilascio della v4.1 di WordPress e il  relativo tema Twenty Fifteen molti blog si sono trovati improvvisamente compatibili con il modulo Infinite Scroll presente in Jetpack, il noto contenitore di plugin sviluppato da WordPress.com. Nel presente articolo darò per scontato che siate a conoscenza delle funzionalità del modulo, in caso contrario vi invito a leggere qui.

Il modulo prevede un Footer standard che si compone di una parte sinistra, nella quale troviamo il nome del sito o blog su cui è installato, e di una parte destra, contenente la frase “Proudly powered by WordPress theme <nome del tema>“.

Per modificare i contenuti della parte destra è sufficiente aggiungere il seguente Filter personalizzato (se non sapete cos’è un Filter o come aggiungerlo, leggete qui):

 

Per cambiare la parte sinistra è necessaria qualche riga di codice aggiuntiva:

Come si può vedere, in questo caso il Filter che andremo ad aggiungere richiama una funzione personalizzata che ha il compito di ricreare l’intero contenuto del Footer.

Nel caso in cui non vogliate alterare il codice sorgente del vostro template potete ottenere un effetto analogo utilizzando la seguente funzione JavaScript (richiede jQuery) da inserire nel blocco <head> della pagina (Appearance -> Edit > header.php):

 

Se invece volete sopprimere del tutto l’Infinite Footer vi basterà aggiungere la seguente linea di codice css (Appearance -> Edit CSS > style.php):

Insomma, ce n’è per tutti i gusti.

WordPress: come aggiungere Actions e Filters personalizzati

Una delle caratteristiche più interessanti della piattaforma WordPress è data dalla possibilità di aggiungere i cosiddetti Hook (letteralmente “uncini”) per modificare le funzionalità del codice sorgente. Gli Hook non sono altro che dei punti specifici in cui è possibile intervenire manualmente per alterare il comportamento delle funzioni che li espongono e si dividono in due tiplogie: Action e Filter.

Per una trattazione completa si rimanda all’apposita documentazione ufficiale presente nel WordPress Codex (con particolare riguardo alle sotto-sezioni dedicate ad Actions e Filters): ai fini di questo articolo ci limiteremo a dire che le Action sono funzioni generiche che vengono eseguite a seguito di determinati eventi, mentre i Filter sono funzioni a cui  viene passato un contenuto (source) e che restituiscono a loro volta un risultato (result), il quale verrà utilizzato in luogo del source.

Questo è un esempio di Action, che determina l’invio di una e-mail a una lista predefinita di destinatari a seguito della pubblicazione di ciascun nuovo articolo sul blog:

 

Questo è un esempio di Filter, in base al quale il contenuto dei nostri articoli viene controllato alla ricerca di termini non appropriati i quali, se trovati, vengono sostituiti da un testo di tipo #?*!:

 

Ora che abbiamo definito cosa si intende per Action e Filter, non resta che vedere come aggiungerli al nostro blog.

Il modo più rapido (e utilizzato) è inserirli all’interno del file functions.php del proprio tema, accessibile tramite il pannello di Amministrazione di WordPress (Appearance -> Theme -> Editor). E’ sufficiente aprire il file e aggiungere la Action o il Filter desiderato in coda alle funzioni già presenti. Questo metodo presenta però il grosso svantaggio che provoca la modifica permanente dei file del tema installato, costringendo ad aggiungere o rivedere gli Hook inseriti in questo modo ad ogni aggiornamento del tema.

Per questo motivo consigliamo di adottare un metodo più efficace come quello fornito da appositi plugin come Add Actions and Filters, così da inserire le nostre modifiche in un contenitore separato.

Add Actions and Filter Plugin - Screenshot

 

Ecco una screenshot che mostra come si presenta. Buona personalizzazione!

Close