Andrea Gandino

Definizione di felicità per un web developer. Ottima notizia!

Una possibile soluzione al problema della gestione dei form che prevedono il caricamento sul server di più file alla volta.

Continua …

Un rapido sguardo a cosa sia un drag&drop, e come si implementi un semplice drag&drop in Javascript.

Continua …

Visto che sembra essere l’argomento del momento, nel mondo del web design, spendo anch’io un paio di parole sull’argomento e lo premetto subito: non sono un grande fan dei framework CSS.

Li trovo abbastanza inutili per varie ragioni:

• La prima ragione è che ognuno disegna e programma a modo suo, quindi quello che va bene per uno, può risultare scomodo per un altro.

• Secondo poi, i framework sono generalmente piuttosto estesi, e sebbene a volte siano suddivisi in più file separati e importabili a piacere, quasi sempre l’80% delle regole che vi sono scritte non vengono utilizzate.

• Infine, una considerazione un po’ più filosofica, che nasce dal fatto che usando i framework si è costretti ad usare nomi di classi scelti da altri, che in molti casi, inoltre, non sono esattamente semantici.

  Mi riferisco, ad esempio, alle classi specifiche per “floattare” (sì, lo so, sto termine fa rabbrividire anche me, ma non mi veniva di meglio) degli elementi a destra e a sinistra, comunemente indicate con left e right: ora, “left” e “right” sono due parole che racchiudono in loro un concetto visivo, e dunque non sono, a parer mio, adatte per essere messe all’interno di un markup che dev’essere il più possibile generico.

Quindi, come consiglia tanta altra gente, è meglio piuttosto farsi il proprio framework/foglio di reset da soli, cosicchè non si debba essere costretti a scrivere le solite regole n volte per n progetti, e con il vantaggio non indifferente di avere qualcosa che è fatto su misura per le nostre esigenze.

Quindi, qui sotto, pubblico quanto ho realizzato finora, col duplice scopo di non perdermelo in qualche cartella sperduta nell’hard disk e di condividerlo con chi avesse avuto dubbi simili ai miei sulla questione.

Scarica!

Riprendo un secondo un articolo che avevo scritto tempo fa per la versione inglese di questo spazio, e cerco di portare il discorso un po’ più avanti.

Dunque, potendo scegliere di inventare così su due piedi una nuova proprietà dei fogli di stile, avevo pensato che sarebbe stato utile poter impostare automaticamente due colonne ad avere la stessa altezza. Tradotto in fanta-CSS verrebbe più o meno così:

#div2 {
    height: #div1;
}

Ovvero, in parole povere:

Rendi l’elemento caratterizzato da id uguale a div2 alto tanto quanto l’elemento con id uguale a div1.

Ok, questa è fantascienza, ma con Javascript forse qualcosa può essere fatto in tal senso. Javascript è infatti in grado di modificare gli elementi di un documento XML leggendo e alterandone le rispettive proprietà. Per questo motivo, possiamo immaginare di leggere l’altezza di div1, e applicarla a div2.

Portando avanti il ragionamento, potremmo pensare di estendere la cosa a più elementi. Potremmo ad esempio scegliere di dare una particolare classe a tutti gli elementi che vorremmo avessero la stessa altezza, in modo da gestire la presentazione della nostra pagina solo ed esclusivamente tramite fogli di stile, come dovrebbe essere.

Quindi, con la funzione getElementsByClassName definita dall’utente che ritorna un array contenente tutti gli elementi che hanno una data classe, ecco la funzione che normalizza le altezze degli elementi posti in quell’array.

function stessa_altezza(className) {
    cols = getElementsByClassName(className);
    var max = 0;
    for(var i=0; i<cols.length; i++) {
        if(cols[i].clientHeight > max) max = cols[i].clientHeight;
    }
    for(i=0; i<cols.length; i++) {
        cols[i].style.height = max + "px";
    }
    for(i=0; i<cols.length; i++) {
        if(cols[i].clientHeight > max) {
            offset = cols[i].clientHeight - max;
            cols[i].style.height = (parseInt(cols[i].style.height)) - offset + "px";
        }
    }
}

Descrivendo a parole cosa fa la funzione in oggetto:

1. Scelgo tutti gli elementi nel mio documento che presentano la classe className
2. Individuo l’elemento con altezza massima
3. Imposto tutti gli elementi ad avere quell’altezza
4. Correggo eventuali imperfezioni derivanti da una non corretta interpretazione del Box Model nei diversi browsers.

Per maggiore chiarezza, ecco un esempio pratico della funzione.

Pensieri sparsi riguardanti il vero utilizzo di XHTML, e le ragioni per cui la scelta tra HTML e XHTML non è poi così scontata quanto uno potrebbe pensare.

Continua …

Ripropongo tradotto in italiano un mio tutorial per Photoshop, volto a creare quell’effetto tipo foglio rialzato che è oggi piuttosto comune in tanti layout (esempio). La sua realizzazione è piuttosto semplice, nulla per cui valga la pena preoccuparsi.

Ecco quindi la procedura passo-passo per creare il suddetto effetto:

1. Creare un nuovo documento, di dimensioni a piacere, ad esempio 600x400, con uno sfondo grigio.
2. Creare un nuovo livello (Layer 1) e selezionare un’area di dimensioni 400x400, con lo strumento di selezione rettangolare.
3. Riempire la selezione di bianco. (Immagine #1)
4. Creare un nuovo livello (Layer 2), e posizionarlo in primo piano.
5. Con lo strumento di selezione circolare, selezionare una porzione molto stretta del libello. Potrebbe essere più facile usando una selezione di dimensione prefissata, ad esempio 25x300.
6. Allineare il lato sinistro della selezione con il lato sinistro del rettangolo bianco che si è disegnato in precedenza.
7. Riempire la selezione ovale con qualsiasi colore. In questo esempio ho scelto il nero, poiché è facilmente distinguibile se rapportato sia al bianco, sia al nero. (Immagine #2)
8. Ripetere i passi 5, 6 e 7 ma questa volta allineare la selezione al lato destro del rettangolo bianco (Immagine #3).
9. Portare il Layer 2 al di sotto del Layer 1.
10. Colorare di bianco lo sfondo del documento.
11. Applicare un effetto “bagliore esterno” al Layer 2, e modificare a piacimento i valori dell’effetto. Questi sono i parametri che ho utilizzato in questo tutorial.

Questo è il risultato finale

Per concludere, suggerisco di tenere a mente che l’ultimo punto è, ovviamente, il più importante, dal momento che cambiando la curva del bagliore esterno, cambia sensibilmente il risultato finale.

La curva dritta produrrà un’ombra più scura e larga, mentre la curva ondulata creerà un effetto opposto, ovvero un’ombra stretta e chiara.

Quello che segue è un pensiero che gira nella mia testa da parecchio tempo, e che solo ora ho la voglia, o il tempo di fare uscire. Non è niente di che, e durerà solo il tempo che impiegherà il backup che sto facendo a terminare.

Il punto è che quando vedo cose come questa, mi viene inevitabilmente da chiedermi come mai i migliori programmi nel nostro campo (e probabilmente non solo in quello) vengano progettati per piattaforme diverse da Windows.

Nota: lungi da me scatenare flames tra utenti Windows e utenti Mac, dal momento che sono discussioni fini a se stesse, e devo dire anche piuttosto stupide; inoltre attualmente lavoro su base quotidiana su entrambi i sistemi, quindi non mi sento di esprimere preferenze per l’uno o per l’altro in senso assoluto.

Coda è solo l’ultimo degli esempi, ma potrei farne molti altri: Textmate su tutti, ma anche BBedit, Transmit, perfino un semplicissimo Cyberduck, client FTP noto ai più e assolutamente gratuito, secondo me è in grato tranquillamente di reggere il confronto (e mi fermo qua) con qualunque client FTP, anche a pagamento, presente per Windows.

Ora, per i gestori di connessioni FTP, per ora ci mettiamo una pietra sopra. Per gli editor di testo qualcosa si sta muovendo, con due ottimi progetti quali Intype ed e, purtroppo entrambi a pagamento, ma sono sempre stato dell’idea che un buon editor di testo valga la pena spenderci qualche Euro sopra.

Un discorso analogo può essere fatto per i gestori di feed, peraltro, ma per ora limiterei la discussione solo all’ambito lavorativo degli editor di testo e client FTP.

La domanda è: è davvero così difficile programmare roba buona per Windows, o è piuttosto il dato di fatto che la maggior parte dei web designers / web developers lavorano su Mac a determinare l’aridità di soluzioni per chi utilizza i sistemi operativi di Redmond?

E quand’anche fosse la seconda delle due, chi mi spiega come mai esistono moltissime IDE per detti sistemi, ma nessuno veramente leggero, versatile, e usabile per il nostro lavoro?

Il blog procede. Lo sviluppo in CakePHP, almeno per quanto riguarda l’interfaccia di amministrazione è giunto ad un discreto 70% di realizzazione.

Ho riflettutto molto, negli ultimi giorni, riguardo al CMS da usare. Come mio solito ho cambiato idea una decina di volte. Ho provato sia Expression Engine, sia Textpattern. Due CMS simili, in un certo senso, perchè entrambi hanno un sistema di templates basato su propri tags; tuttavia sono distanti anni luce.

Devo dire con piacere di aver riscoperto Expression Engine. Ad una prima occhiata non può risultare che ostico. L’interfaccia rimane molto dispersiva, e per trovare un’opzione, possono passare anche 2-3 minuti (sono dell’idea che in questo genere di cose l’immediatezza sia un pregio cui non bisognerebbe mai rinunciare), ma tuttavia il CMS risulta estremamente flessibile e utilizzabile per scopi che vanno ben oltre il semplice blog personale.

Alla fine, però, non ho potuto far meno di ritornare all’ovile e continuare ad usare il mio sistema, conscio del fatto che le chances di vedere, un giorno, un CMS sviluppato da altri che si adatti completamente ai miei gusti, probabilmente sono tanto basse che possono essere approssimate a zero.

Uno dei nodi principali, ora, diventa un’organizzazione sensata dei contenuti. Ed è qui che entrano in gioco dubbi, se va bene, ancora più profondi.

Layout fisso, fluido o liquido? Chiaro su scuro o viceversa? Struttura a singolo articolo in home page, e link ai successivi nella forma di una lista puntata, o solita pagina “a cascata”?

Mi fa piacere, comunque, notare che queste scelte saranno supportate da un sistema che davvero si adatta a quello che ho in mente. Penso ad esempio alla possibilità di postare articoli in un cosiddetto tumblelog, una cosa che ho sempre desiderato di implementare come si deve su WordPress, e che per un motivo o per l’altro non sono mai riuscito a fare.

Il tutto iscritto in quella che è l’ennesima mia personale rivoluzione copernicana, nata dall’aver letto questo articolo.

Al che mi spunta una domanda: se è vero che usare HTML 4.01 Strict pare essere la soluzione migliore per avere la migliore compatbilità possibile, e siccome detto HTML 4.01 Strict non ammette il carattere / a fine tag, come faremo noi povere anime che per pubblicare il contenuto usiamo strumenti come Textile o Markdown, che mandano in output codice XHTML (e quindi con / a fine tag), compromettendo dunque la validazione?

Pensierino della sera da catalogare nella serie “cosa vorrei da un selettore di un foglio di stile, e cosa probabilmente non avrò mai prima di 10 anni”: non sarebbe veramente una gran cosa se i CSS prevedessero un particolare selettore che ritornasse, dato un elemento, il suo genitore?

Mi è venuta in mente questa idea, di per sé piuttosto banale, tentando di realizzare un form con dei popup per meglio specificare il contenuto dei vari campi, cercando di non utilizzare in nessun modo Javascript.

L’implementazione sarebbe anche piuttosto semplice, dal momento che in Javascript una cosa del genere è possibile renderla attraverso una singola riga di codice:

var elem = document.getElementById('mioelemento');
var parent = elem.parentNode;

Niente di fantascientifico dunque; rimanendo nel mondo della fantasia, ecco un ipotetico selettore che restituisce il padre di un elemento dato:

div#mioElemento input:focus << p.informazioni

Il difficile sarebbe interpretare questa scrittura, dal momento che sovvertirebbe un po’ tutte le regole base dei selettori di CSS che vedono l’elemento a sinistra come padre di quello a destra. In questo caso invece potremmo interpretare la riga qui sopra come:

1. Prendi l’elemento caratterizzato da un id uguale a mioElemento
2. Quando l’input figlio di quell’elemento ottiene lo stato di focus, ovvero quando è attivo, modifica le proprietà stilistiche del paragrafo con attributo class uguale a informazioni, che è figlio del genitore di input (<<).

Per prendere il genitore di input, si potrebbe invece ipotizzare di avere un selettore del tipo <.

Ok, ora torno nel mondo reale.