Tags: internet explorer, ie8, acid2

Prendiamo un caso specifico di modulo: se si deve effettuare l’upload di tre foto, ad esempio, può risultare estremamente noioso dover ripetere l’operazione di invio del modulo per ben tre volte; se il modulo prevede l’upload di più files alla volta, rimane la limitazione del numero fisso di file che è possibile caricare.

Per ovviare a questi problemi, e rendere così leggermente meno doloroso l’invio di moduli con più file, bisogna necessariamente intervenire mediante Javascript

La soluzione che mi pare essere la più diffusa prevede la possibilità, mediante la pressione di un bottone, di inserire quanti campi di file si voglia, uno di seguito all’altro.

Personalmente trovo che, sebbene molto efficace, questa soluzione non sia il massimo quanto a chiarezza, per l’utente finale. L’elenco dei campi di file fa aumentare considerevolmente la lunghezza dell’intero modulo, cosa che in generale sarebbe meglio evitare. Inoltre non è possibile avere una chiara percezione di quali file si stia per caricare, dal momento che il percorso del file molto spesso è più lungo della larghezza del campo dov’è stato immesso.

Per finire, l’unico modo certo per evitare l’upload di un file è un reset dell’intero form; un’eventualità, quella della cancellazione dell’upload, che esiste e che non è neanche così remota, sebbene lato server possano essere messe in atto contromisure adeguate.

Una possibile soluzione

Partendo da questo presupposto, ho pensato non fosse una brutta idea scrivere uno script per snellire l’aspetto di quei moduli che consentono il caricamento di più file alla volta.

Spiegare lo script che ho realizzato riga per riga diventerebbe decisamente pesante e oltremodo noioso, anche per dei nerd“persone genuinamente interessate all’informatica” come me, quindi riassumo velocemente:

• Aggiungo prima tutti i file che mi servono, uno per uno, apparentemente usando sempre lo stesso campo di input.
• Ad ogni inserimento di un nuovo file, aggiorno un’apposita lista creata per avere sottomano l’elenco dei file che si sta per caricare in maniera semplice e leggibile.
• Eseguendo un doppio click su un elemento di quella lista è possibile annullare l’upload di quel particolare file.

I vantaggi, sebbene lo script non abbia nessuna pretesa di completezza, sono due:

1. Il contenuto è molto più semplice da aggiungere e da visualizzare.
2. Non si deve necessariamente compiere un reset in caso di errore.

Infine, ho cercato di rendere lo script il più possibile accessibile, in modo che il suo utilizzo non sia precluso anche a coloro i quali navigano in condizioni non convenzionali, per così dire.

Nello specifico, in caso di Javascript disattivato o totalmente assente (come ad esempio nei browser testuali), la funzionalità non è preclusa in assoluto (lo script è dunque degradabile), ma limitata a un solo file; in altre parole, si perde il concetto di multi-upload, ma non si perde la possibilità di ottenere lo scopo che anche il multi-upload si proponeva, ovvero il caricamento di un file sul server.

In caso di CSS disabilitati e Javascript abilitato, lo script è comunque fruibile nella sua interezza.

Un piccolo problema si riscontra nel caso in cui sia i CSS, sia Javascript siano disabilitati, dal momento che il bottone aggiungi, pur avendo perso la sua funzionalità, rimane visibile, rischiando quindi di risultare fuorviante per l’utente finale.

Come sempre, vi rimando all’apposito esempio, avvertendovi che, per ovvie ragioni, l’upload (ma non l’invio del form) è disabilitato.

Tags: upload

Innanzitutto, penso sia doveroso cominciare a dire cosa sia un drag&drop e quali siano le sue peculiarità.

Come spesso accade, Wikipedia ci viene in aiuto definendo il drag&drop come segue:

Nell’interfaccia grafica di un computer, il drag and drop indica il cliccare su un oggetto virtuale (quale una finestra o un’icona) e trascinarlo (in inglese:drag) in un’altra posizione, dove viene rilasciato (in inglese:drop).

Tecnicamente, e nel caso specifico delle pagine Web, questa definizione si traduce in quanto segue:

1. Clicco su un oggetto (elemento) della pagina.
2. Tenendo premuto il tasto del mouse, muovo lo stesso mouse.
3. Giunto alla posizione di destinazione, rilascio il tasto.

Andiamo dunque per punti, ad analizzare come si implementa un sistema del genere mediante Javascript.

Primo click sull’oggetto

Dopo essersi posizionati col cursore del mouse sull’oggett che si intende trascinare, eseguiamo un click. Al momento del click, viene attivato il rispettivo evento Javascript, denominato onmousedown, letteralmente tradotto come quando viene premuto il mouse.

A questo evento, associato soltanto all’oggetto che abbiamo cliccato, possiamo associare una funzione, il che equivale a dire che ogni volta che cliccheremo detto oggetto, una porzione di codice da noi stabilita sarà eseguita.

el.onmousedown = seleziona;

Notare come la funzione seleziona sia qui indicata soltanto come reference, e pertanto non ammetta l’indicazione di parametri.

Bene, quello che accade all’interno della funzione seleziona ci interessa relativamente, dal momento che questo articolo non parla di trascinare effettivamente oggetti, nel senso di spostarli da un punto all’altro dello schermo, ma solo di come impostare correttamente quello che sta dietro al drag&drop.

Quello che possiamo dire riguardo alla funzione seleziona, ci porta però al secondo aspetto della faccenda.

Spostamento del mouse

Dopo aver cliccato, si sposta il mouse tenendo premuto il tasto opportuno. Il fatto di muovere il mouse, attiva anche in questo caso un evento particolare chiamato onmousemove.

C’è da dire una cosa riguardo a onmousemove. L’elemento che chiama questo handler può essere alternativamente o un elemento della pagina, o la pagina stessa.

Nel primo caso, l’evento sarà attivo solo nel caso in cui il mouse si sposti all’interno dell’area dell’elemento (per esempio, nel caso di un elemento rettangolare come può essere un div, all’interno dell’area di quel div), mentre nel secondo caso, più generico, l’evento sarà attivo nel caso il mouse si muova all’interno della porzione di schermo che il browser dedica al rendering della pagina.

Nel nostro caso, volendo catturare ogni movimento del mouse, a prescindere da dove esso si trovi, scriviamo:

document.onmousemove = muovi;

che può essere letto come ogni volta che muovi il mouse all’interno della finestra di rendering del browser, fai quello che ti dice la funzione muovi.

Anche in questo caso non ci sofferiamo su cosa effettivamente svolga la funzione muovi.

All’interno della funzione seleziona dobbiamo però anche definire cosa accade al rilascio del mouse, o meglio, definire quale sarà la funzione adibita alle operazioni in concomitanza di quello che è l’evento onmouseup.

Rilascio del mouse

All’interno della funzione seleziona, scriviamo la seguente riga, dal significato che ormai dovrebbe essere chiaro:

document.onmouseup = fine;

Spostandoci nella funzione fine, due sono le cose da fare:

1. “Scollegare” l’evento onmouseup, ovvero dissociarlo dalla funzione fine.
2. Fare la stessa cosa per l’evento onmousemove, per la funzione muovi.

Ovvero:

document.onmouseup = null;
document.onmousemove = null;

Cenni conclusivi

Le funzioni seleziona e muovi, ovvero quelle funzioni che gestiscono le vere operazioni di drag&drop, sono indicate, come abbiamo visto, mediante un semplice riferimento.

Queste funzioni, però, sono lanciate quando un particolare evento viene attivato, sia esso un click, uno spostamento, o un altro tipo di evento. Esse sono così in grado di sapere quale sia stato l’evento che le ha lanciate e di reperire informazioni utili rispetto sia all’evento, sia alla periferica che lo ha attivato (mouse, tastiera).

Tutte queste belle cose, che meriterebbero senz’altro una trattazione più esaustiva, avvengono mediante la variabile e, un oggetto in cui vengono memorizzate tutte le informazioni. Questo oggetto, incidentalmente, viene indicato come parametro al momento di definire la funzione.

Per esempio, se volessimo conoscere le coordinate del mouse al momento del click, basterebbe fare riferimento ai valori e.clientX ed e.clientY, e così via.

Per la solita storiella che noi non viviamo in un mondo ideale, e non è universalmente riconosciuta (qualcuno ha nominato per caso IE?).

Internet Explorer infatti utilizza un’altra variabile per memorizzare le informazioni dell’evento, vale a dire window.event.

Possiamo ovviare a questo problema, scrivendo all’interno delle funzioni sopra citate, quanto segue:

if (!e) var e = window.event;

Per una maggiore completezza, e visto che abbiamo parlato di coordinate, ho preparato un esempio di quanto illustrato in questo articolo, ovvero uno script che traccia le coordinate del mouse solo in presenza di un drag&drop.

Tags: drag&drop

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!

Tags: css, framework, fogli di stile

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.

Tags: javascript, css

La seconda premessa è che le mie conoscenze a proposito degli argomenti trattati qui sotto sono più che mai in evoluzione, dunque correzioni, obiezioni, critiche e quant’altro sono più che mai accettate e incoraggiate.

In questi giorni, dicevo, ho letto parecchio materiale riguardo alla questione, in sé piuttosto datata, riguardante la scelta tra XHTML e HTML.

Mi rendo conto che, in passato, sono caduto anch’io in uno degli errori più comuni che si possono fare, ovvero usare XHTML soltanto perché è percepito come la novità, o come la cosa di moda. In realtà, dopo aver indagato più a fondo, sono giunto alla conclusione, diametralmente opposta alle mie idee di non più di un paio di mesi fa, che usare HTML4 è una scelta tanto rispettabile quanto quella di usare XHTML, e che non vi sono vere e proprie ragioni per cui il secondo debba essere preferito al primo, o comunque possa dirsi oggettivamente migliore.

L’inghippo è sostanzialmente uno: l’XHTML che usiamo ogni giorno non è trattato come XML. Per fare in modo che l’XHTML sia effettivamente gestito dai browser come tale, dovremmo infatti assicurarci che il nostro documento sia inviato come un tipo MIME che faccia effettivamente parte della “famiglia” di XML, ovvero application/xhtml+xml.

Normalmente, però, quando scriviamo un documento in XHTML, esso è gestito dal server come normalissimo text/html, di fatto eliminando gran parte (se non la totalità) dei vantaggi dell’usare XHTML: se non serviamo XHTML come application/xhtml+xml l’unico effetto che otteniamo è che il nostro documento è trattato come se fosse HTML e nulla più.

Potremmo dunque chiederci cosa ci trattenga dall’usare application/xhtml+xml su base quotidiana. La risposta è che non tutti gli User Agent sono in grado di leggere correttamente tale tipo MIME, uno su tutti l’amato (da pochi)/odiato (da molti) Internet Explorer 6 (Si veda questa tabella per una comparazione tra i vari browser oggi disponibili).

Quindi diciamo che gli scogli da superare se volessimo utilizzare detto tipo MIME sono due:

1. Le impostazioni dei server, dal momento che trattano automaticamente i file .html come text/html, sostanzialmente fregandosene del DOCTYPE da noi impostato.

2. Lo scarso supporto di application/xhtml+xml da parte degli user agent. Qui ci possiamo fare relativamente poco, anche se esistono dei modi, un po’ tortuosi forse, per far digerire application/xhtml+xml anche a IE.

Per quel che concerne il primo punto, possiamo pensare di gestire la cosa in due modi. Dal momento che gli header HTTP hanno priorità più elevata rispetto alle indicazioni fornite dal documento nell’apposito elemento meta, possiamo intervenire modificando tali header con i metodi già conosciuti e forniti da linguaggi di programmazione quale ad esempio PHP, oppure divertendoci con il file .htaccess.

Con i linguaggi di programmazione come PHP, inoltre, è possibile tentare anche un abbozzo di browser sniffing, andando a controllare l’esistenza di $_SERVER["HTTP_ACCEPT"], un header inviato dai browser che può contenere la stringa application/xhtml+xml, cosa che permette dunque il riconoscimento automatico degli user agent che supportano XHTML mediante un semplicissimo controllo if.

Utilizzare XHTML secondo le modalità con cui è stato realmente concepito ci porta in un mondo tutto nuovo, in cui l’essere well-formed è una caratteristica essenziale, non più solo un valore aggiunto, o comunque qualcosa che, qualora mancasse, non comprometterebbe la visualizzazione della nostra pagina.

Il discorso che faccio è iper-semplificato, anche e soprattutto per le lacune del sottoscritto a riguardo, ma in pratica, se si utilizza un parser XML al posto del solito parser HTML, ci si avvicina molto di più alla situazione che si ha in programmazione, nella quale un singolo errore causa il blocco dell’intero programma. Similmente, un errore nella well-formedness del documento, causerebbe una schermata di errore, impedendo drasticamente la visualizzazione della pagina intera.

Ad oggi tutti i browser implementano vari sistemi di correzione degli errori, in modo che, anche in presenza di imperfezioni nel markup, la pagina venga sempre caricata e mostrata all’utente.

Naturalmente il dibattito è tra chi è un sostenitore della rigidità anche nei linguaggi di marcatura adoperati sul Web, e chi invece reputa giusto l’inserimento di meccanismi per la correzione degli errori. Se è vero che la prima ipotesi sensibilizzerebbe gli autori/sviluppatori a scrivere codice valido e ben formato (che sono due cose diverse, non necessariamente sovrapponibili), è anche vero che non è pensabile stampare solo un messaggio di errore in presenza di una pagina che non sia conforme a XML, dal momento che la stragrande maggioranza delle pagine Internet non lo sono.

Comunque, questo è un altro argomento. La scelta del tipo MIME con cui i nostri documenti XHTML sono inviati appartiene solo a noi. Nella maggior parte dei casi non vi sono veri e propri vantaggi nell’inviare XHTML come application/xhtml+xml, per le ragioni illustrate precedentemente.

Inoltre, le differenze tra HTML e XHTML non finiscono qui, e toccano anche altri aspetti della programmazione per il web, come ad esempio le funzioni Javascript del DOM: non è possibile usare la funzione, molto diffusa, document.write (sostituita da document.createElementNS), funzioni di uso comune come getElementsByTagName potrebbero non dare i risultati che si aspetta, dal momento che XHTML è case-sensitive, al contrario di HTML, giusto per citare quelle più immediate.

Riassunto di tutta la sbrodolata di informazioni di cui sopra: si può usare XHTML, ma bisogna però tener presente che, quando scriviamo un documento con quel DOCTYPE, in realtà esso sarà letto come un comune documento HTML.

Ma allora, se nella maggior parte dei casi usare XHTML ha lo stesso valore che usare HTML, com’è possibile scegliere tra i due? E ancora, come mai si dovrebbe preferire il primo, quand’è chiaro che lo si utilizzerebbe in un modo per il quale non è stato progettato?

Personalmente ritengo che XHTML sia più chiaro e meno confusionario rispetto ad HTML, e aiuti lo sviluppatore a scrivere codice migliore, anche sotto un punto di vista di organizzazione dei contenuti, non solo dal punto di vista “estetico”.

Inoltre lo sviluppo che è in atto con XHTML2 mi sembra molto più sensato, rispetto al lavoro portato sinora avanti dal WHATWG.

Tuttavia, ed è qui che arrivano i veri dolori, il W3C dice che XHTML2 non dovrà essere inviato come text/html, ma solo come application/xhtml+xml. Se è vero che per arrivare a XHTML2, posto che effettivamente ci si arrivi, passeranno parecchi anni, è anche vero che se i browser non saranno pronti a gestire il tipo MIME application/xhtml+xml saremo di nuovo al punto di partenza: una tecnologia buona, ma scarsamente supportata favorirà l’utilizzo di un’altra, a mio modo di vedere inferiore, ma universalmente accettata.

Tags: html, xhtml, xml

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.

Tags: tutorial, photoshop

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?

Tags: programmazione, web design, sistemi operativi

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?

Tags: cms, cakephp, doctype

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.

Tags: css, selettori, genitori