Very short trick: versatilità delle classi CSS

Lunedì 10 Novembre, 2008

I più esperti lo sapranno già, tuttavia mi viene spesso chiesto che differenza c'è tra class e id nei fogli di stile CSS. Una panoramica su alcune differenze e avvertenze è possibile trovarla in Classi e ID nei CSS, tuttavia una caratteristica utile, che distingue class da id, è la possibilità di usare classi multiple. Ad esempio è possibile definire:

CSS:
  1. .bordoNero {border:2px solid #000}
  2. .coloreRosso {color:#f00}
  3. .bordoRosso {border:2px solid #f00}

e scrivire nell'HTML:

HTML:
  1. <div class="bordoNero coloreRosso">Bordo nero con caratteri rossi</div>
  2. <div class="bordoRosso coloreRosso">Bordo rosso con caratteri rossi</div>

class, a differenza di id, può contenere al suo interno più definizioni in qualsiasi sequenza!

Post correlati

CSS3: qualcuno ha visto Internet Explorer?

Giovedì 16 Ottobre, 2008

Io proprio no...

CSS:
  1. p {
  2. /* Rounded Corners */
  3. border-radius: 9px; /* CSS 3 */
  4. -o-border-radius: 9px; /* Opera */
  5. -icab-border-radius: 9px; /* iCab */
  6. -khtml-border-radius: 9px; /* Konqueror */
  7. -moz-border-radius: 9px; /* Firefox */
  8. -webkit-border-radius: 9px; /* Safari */
  9. }

Post correlati

Safari, eliminare il blue border sui campi input

Lunedì 14 Luglio, 2008

Safari, il browser Apple disponibile anche per Windows, produce un bordo blu (blue border) quando si clicca all'interno di un campo input. Se in alcuni casi può risultare piacevole, in altri diventa davvero fastidioso! Per eliminarlo basta inserire nel nostro foglio di stile:

CSS:
  1. /* ____________________________ remove blue border */
  2. input { outline: 0 none }

O, in alternativa, direttamente come attributo nel tag input:

HTML:
  1. <input style="outline: 0 none" ... />

Post correlati

Accessibilità e Usabilità: unobtrusive Javascript

Martedì 27 Marzo, 2007

Permettere agli utenti di interagire con una pagina Web ha prodotto negli ultimi anni un notevole aumento nell'uso di script lato client: codice Javascript in grado di rispondere e manipolare in tempo reale tutta una serie di informazioni. Il Web2.0 è la massima espressione di questa capacità di interazione, dove l'utente finale - il navigatore -partecipa attivamente alla costruzione e all'evoluzione del sito Web, interagendo con esso e contribuendo personalmente. Si parla quindi di User-Generated Content (o UGC - contenuto generato dagli utenti) che vede il "navigatore" sicuramente meno passivo!

Per realizzare questa interazione, per permettere quindi all'utente finale di aggiungere il suo contributo, sono state sviluppate una serie di tecniche che hanno modificato l'aspetto e il comportamento delle pagine Web (statiche sino ad oggi, mentre adesso simili alle tradizionali applicazioni dei Desktop) negli ultimi anni. Modificare il contenuto di una pagina, inviare dei file, dare il proprio voto ad un video o a un documento, registrarsi o modificare i propri dati, sono solo alcune delle operazioni richeste in tanti servizi (2.0 beta) presenti sul Web.

Continua a leggere... »

Post correlati

Net Software

Venerdì 2 Marzo, 2007

È successo alla TV di trasformarsi in Net TV, come già era successo alla Radio di diventare Net Radio, per non parlare della musica! Ora, come anticipato in altri Post, è ufficiale anche per il Software di trasformarsi a breve in Net Software!

Adobe, che come sappiamo ha da poco acquisito Macromedia, ufficializza le Web Application - del Web 2.0 - in vere e proprie RIA (Rich Internet Applications) con l'annuncio di voler portare sul Web il noto software di fotoritocco Photoshop. È recente l'accordo tra Adobe e Photobucket per rendere disponibile online una tecnologia per l'editing e il remix video. Grazie alla nuova tecnologia sviluppata per Flash 9, con ActionScript 3.0, Adobe punta in alto, anticipando che entro sei mesi sarà disponibile online una versione di Photoshop basata, appunto, su tecnologia Flash.

Effettivamente le nuove potenzialità di ActionScript 3.0 (che coinvolgono progetti come Flex e Apollo - vedi anche Web2.0: Adobe ci prova con Apollo e Ajax: Rich Internet Application) lo rendono il candidato perfetto per l'implementazione di vere RIA sul Web. Ajax, dal canto suo, si vede spodestato dal suo trono in questo nuovo scenario. Nonostante gli innumerevole Framework Ajax, alcuni di ottimo livello, prodotti nel corso di questi ultimi anni, Flash garantisce un'ambiente più evoluto e semplice da manipolare. Inoltre parliamo di uno dei Plugin più diffuso al mondo: Flash ha infatti alle spalle qualche anno in più rispetto ad Ajax e derivati.

Inoltre risulta ovvio che Adobe scelga Flash, essendo oramai lui il produttore. Tuttavia ci sono da considerate questioni tecniche che possono - ad oggi - essere risolte in modo armonico unicamente ricorrendo a tecnologie come quella Flash. Dando uno sguardo al nuovo ActionScript 3.0 ci si rendo subito conto delle enormi possibilità di sviluppo che offre questa nuova piattaforma. Lo standard ECMA del linguaggio e i nuovi oggetti messi a disposizione dal Framework, permettono di arrivare ad un livello di dettaglio impensabile con le precedenti versioni di Flash: una su tutte, ad esempio, la possibilità di accedere ai dati Bitmap di un'immagine caricata da disco!

L'attacco da parte di Adobe sembra svolgerersi quindi su due fronti distinti che hanno in comune la tecnologia Flash (che ricordiamo ha da sempre la capacità di interagire attivamente con il browser e quindi con Javascript lato Client e Scripting lato Server).

Il primo attacco avviene dall'esterno, sul versante browser, dove la tecnologia Apollo si propone di fatto come alternativa ai Kernel usuali delle diverse piattoforme oggi disponibili (Windows, Mac OS, Linux, ecc...); usare Adobe Apollo, quindi, al posto del browser per ottenere prestazioni e applicazioni (vere e proprie RIA) impensabili, aggirando così le incompatibilità tra Internet Explorer, FireFox e compagnia. Inoltre Apollo garantisce una piattaforma unica di sviluppo, al pari di Javascript-Ajax, ma senza i problemi di compatibilità. Quest'ultimo punto è uno scacco notevole a tecnologie come Ajax che ancora oggi soffrono enormemente delle questioni legate alla compatibilità tra browser; non dimentichiamo, inoltre, tutta la questione legata alla resa (rendering) grafica dei CSS!

L'altro attacco avviene direttamente dall'interno, colpendo i Framework Ajax con la carta Flash. L'elemento vincente in questa strategia risiede nell'uso di Flash, della tecnologia Flash, che trova applicazione sia in Flex, sia in Apollo, sia in versione standalone come già siamo abituati a vedere (semplici file SWF per intenderci)! Non c'è dubbio che tale scenario è estremamente invitante per gli sviluppatori, Web e non. Ciò che realizzo in Flash diventa immediatamente riusabile in vari modi, senza costringermi a modificare una sola riga di codice e, inoltre, senza preoccuparmi della compatibilità!

Tutto questo, a mio avviso, è un'importante passo avanti, una svolta di proporzioni notevoli che coinvolge anche il mondo dei giochi e del Marketing. Ne parleremo ancora prossimamente, statene certi!

Post correlati

Nascondimi

Lunedì 12 Febbraio, 2007

Una caratteristica dei fogli di stili (i file .css) è quella di poter essere specificati a seconda del media di output. Gli Style Sheet permettono infatti di specificare la stessa classe, lo stesso ID lo stesso TAG, ecc... per media diversi. Ad esempio posso scrivere un file .css con la seguente sintassi:

CSS:
  1. @media screen {
  2. div#myBox {display:none}
  3. }
  4.  
  5. @media print {
  6. div#myBox {display:block}
  7. }

Quello che ne deriva, alla fine, è che il contenuto del DIV con id myBox non sarà visibile sul browser, sullo schermo, ma quando provo a stampare la pagina troverò un contenuto diverso da quello che mi aspettavo.
I motori di ricerca, spider, crawler o aggregatori, normalmente (per ora) non risolvono i file css. A loro interessa il contenuto non la formattazione visiva. Tuttavia questa tecnica potrebbe avere risvolti interessanti se non inquietanti. Proprio per le caratteristiche dei sistemi di indicizzazione una situazione come quella mostrata qui sotto sarebbe quantomeno curiosa:

HTML:
  1. <div id="visibile_a_video">
  2.    <p>Contenuto visibile a video</p>
  3. </div>
  4.  
  5. <div id="visibile_in_stampa">
  6.    <p>Contenuto visibile in stampa</p>
  7. </div>

Correlato con un file .css di questo tipo:

CSS:
  1. @media screen {
  2. div#visibile_a_video {display:block}
  3. div#visibile_in_stampa {display:none}
  4. }
  5.  
  6. @media print {
  7. div#visibile_a_video {display:none}
  8. div#visibile_in_stampa {display:block}
  9. }

Google, ad esempio, indicizzerebbe entrambi i contenuti del nostro HTML, anche se a video saremmo in grado di vederne solo uno. Se stampiamo la pagina troveremmo con sorpresa un nuovo contenuto. Il trucco, tuttavia, sarebbe svelato eliminando l'applicazione degli stili nei browser che lo supportano. Normalmente nessuno esegue un'operazione di questo tipo quando naviga su Internet. Tale indagine scaturirebbe solo dopo aver trovato un'incongruenza tra ciò che è visibile a video e ciò che si è stampato!

Ad oggi non mi risultano casi eclatanti di questo tipo di manipolazioni tramite CSS. Un tempo si cercava di aumentare la visibilità su Internet inserendo una serie di testi, parole, dello stesso colore dello sfondo della pagina Web, così da rendere tale artifizio oscuro agli occhi dei navigatori. Con il tempo i motori di indicizzazione si sono cautelati contro queste "frodi". Sarà forse il momento di anticipare qualche burlone prima di creare un precedente?

Attualmente gli Style Sheet consentono di specificare tutta una serie di media type di output. Per una lista completa vedi il W3C.

Post correlati

Classi e ID nei CSS

Giovedì 7 Settembre, 2006

Ecco alcuni brevi consigli su come usare class e id nei fogli di stile. Tenete subito in considerazione che l'uso di tecniche Javascript avanzate, come lo stesso uso di motori Ajax, può entrare in conflitto con i consigli esposti qui! E vedremo alla fine il perchè.

Avendo a disposizione sia l'attributo class="" che l'attributo id="" per legare un TAG ad uno stile, spesso si rimane confusi e non si capisce quale sia la differenza o, comunque, la scelta migliore tra i due. In verità segnare un TAG tramite la classe o tramite l'id ai fini del CSS non cambia nulla, o quasi. Quello che cambia è il nostro modo di pensare alla pagina e di utilizzare in modo corretto id e classi senza ritrovarci poi a pentirci delle scelte fatte.

Una precisazione sull'ereditarietà

Prima di iniziare vorrei cogliere l'occasione per sottolineare un comportamento importante degli stili, ovvero il coscading o ereditarietà. In pratica un sottoelemento eredita le caratteristiche dell'elemento padre, a meno di non specificare esplicitamente che è !important. Vediamo un esempio che può chiarire meglio questa situzione. Immaginiamo di aver creato il seguente foglio di stile:

CSS:
  1. #a_box p {font-size:14px}
  2. #b_box p {font-size:22px}

e il seguente codice HTML:

HTML:
  1. <div id="a_box">
  2.    <p>Primo testo direttamente sotto a_box</p>
  3.    <div id="b_box">
  4.        <p>Secondo testo sotto b_box e a sua volto sotto a_box</p>
  5.    </div>
  6. </div>

Il risultato sul browser sarà effettivamente quello desiderato, il primo paragrafo sarà reso con il font 14 pixel e il secondo paragrafo con il font a 22 pixel! Proviamo ora ad usare class al posto di id:

CSS:
  1. #c_box p {font-size:14px}
  2. .d_box p {font-size:22px}

codice HTML:

HTML:
  1. <div id="c_box">
  2.    <p>Primo testo direttamente sotto c_box</p>
  3.    <div class="d_box">
  4.        <p>Secondo testo sotto d_box e a sua volto sotto c_box</p>
  5.    </div>
  6. </div>

Il risultato sul browser (provato su FireFox 1.5+ e su IE6), questa volta, sarà diverso! Cosa è accaduto? Il div con classe d_box ha ereditato il font-size del primo div con id c_box. Un id, quindi, obbliga le classi "figlie" ad ereditare i propri attributi (anche se questo non è valido per tutti gli stili). Per eliminare il problema bisogna indicare esplicitamente, con la keywork !important, il font-size nella classe d_box, come mostrato qui sotto:

CSS:
  1. #c_box p {font-size:14px}
  2. .d_box p {font-size:22px !important}

In questo modo imponiamo di prendere in considerazione il nuovo stile definito con la classe d_box.

Usando esclusivamente le classi:

CSS:
  1. .c_box p {font-size:14px}
  2. .d_box p {font-size:22px}

codice HTML:

HTML:
  1. <div class="c_box">
  2.    <p>Primo testo direttamente sotto c_box</p>
  3.    <div class="d_box">
  4.        <p>Secondo testo sotto d_box e a sua volto sotto c_box</p>
  5.    </div>
  6. </div>

Il risultato sul browser sarà quello iniziale, entrambi i paragrafi saranno resi correttamente. Morale: massima attenzione quindi quando si usano gli stile in cascading... se è vero che non c'è una immediata differenza tra classi e id è anche vero che il loro uso non è del tutto identico. Altrimenti perchè esisterebbero due modi di indirizzamento?

Regola

Tuttavia esiste un modo per sapere chi "vince" quando si imposta uno stile. Questa tecnica viene normalmente chiamata Cascade Rule 3.
Si fornisce un valore ad ogni selettori, o riga dichiarativa CSS. Questo valore ha la forma A-B-C.

1) Addizionare 1 ad A per ogni id nel selettore
2) Addizionare 1 ad B per ogni class nel selettore
3) Addizionare 1 ad C per ogni TAG nel selettore

Vediamo un esempio:

CSS:
  1. 0-0-1 = 1       -[ p {color:red}
  2. 0-1-1 = 11      -[ p.largetext
  3. 1-0-1 = 101    -[ p#largetext
  4. 1-0-2 = 102    -[ body p#largetext
  5. 1-1-3 = 113    -[ body p#largetext ul.mylist
  6. 1-1-4 = 114    -[ body p#largetext ul.mylist li

Il valore più alto vince. Nel caso due regole hanno lo stesso peso, vince l'ultima definita.

Consigli

Una strada potrebbe essere questa: usare la classe quando il comportamento visivo di un TAG può variare a seconda del suo contenitore madre. Usare id quando il comportamente visivo è univoco, cioè prescinde dal suo contenitore madre.

Un esempio chiarificatore di questo approccio potrebbe essere il seguente: il comportamento di un ipotetico titolo. In questo caso useremo la class="title" e in base al contenitore superiore regolare i vari comportamenti. Il file CSS potrebbe essere:

HTML:
  1. <div id="codice"><code>.title { ...... }
  2. </code><code>#listProducts .title { ........ }
  3. #listUsers .title { ....... }</code></div>

Nella realtà, addirittura, le cose sono anche meglio visto che abbiamo i TAG Hn che ci aiutano. In un caso reale la classe title sarebbe inutile. In pratica la tecnica è quella di usare gli id come selettori di comportamento (infatti vengono spesso indicati come id-selector). Una situazione reale potrebbe essere quindi:

HTML:
  1. <div id="codice"><code>h1 { ...... }
  2. </code><code>#listProducts h1 { ........ }
  3. #listUsers h1 { ....... }</code></div>

Abbiamo dunque tre comportamenti diversi in base al selettore. La regola principale potrebbe essere la seguente: se questo TAG si comporterà visivamente in modo diverso a seconda del contenitore usare class!

In questa casistica, tra l'altro, rientrano molti elementi del layout visivo come ad esempio le liste ul. Queste si possono comportare in modo diverso a seconda del contenitore madre: possono avere un aspetto nella barra di navigazione, un altro nella pagina principale, un altro ancora nella barra laterale, ecc... Tuttavia quello che ci serve, nella maggioranza dei casi, è il solo selettore id, utilizzando al meglio i TAG standard messi a disposizione dell'HTML.

Per esempio è buona regola usare le liste ul o ol quando si può, i TAG titolo Hn, i TAG strong, acronym, code, insomma limitare div e span altrimenti rendiamo inutile l'uso degli stili, inondando inoltre la rete con bit supeflui. Spesso, infatti, non si conoscono nemmeno tutti i TAG HTML. Alcuni Web Designer sembrano ignorare alcuni dei più utili TAG presenti nell'attuale standard HTML. Certo alcuni TAG (come anche alcuni attributi, eventi, stili e, ahimè, altre varie cosine...) sono confinati nello standard di qualche specifico browser, ma ci sono molti TAG pienamente supportati da praticamente tutti i browser esistenti (Safari compreso - apropos ma Apple ha forse dimenticato di aver sviluppato un suo browser?!).

I fogli di stile, ancora ahimè, sono anch'essi soggetti a qualche incomprensione sparsa quà e là. Ai Web Designer non resta che pazientare sperando in un futuro più standard e meno variabile. Utilizzare gli id come selettori, quindi, non può esimersi dall'essere anch'esso coinvolto in un effetto collaterale legato all'uso di Javascript. Tramite il linguaggio lato client più diffuso, se attivato nel browser, è possibile ottenere un puntatore ad uno specifico TAG o elemento della pagina. Questo oggi viene risolto con estrema facilità (un pò di tempo fa era leggermente più complesso, a causa delle sempre presenti incompatibilità tra browser!) tramite il metodo getElementByID() messo a disposizione dall'oggetto document.

Come si evince dallo stesso nome del metodo, getElementByID() recupera il puntatore in base all'id dell'elemento. Il problema che ha a che fare con i fogli di stile risiede nel fatto che l'id in questione è proprio lo stesso utilizzato da getElementByID() per rintracciare l'elemento. Quindi immaginiamo di dover scrivere una Web Application che gestisce una serie di post-it a video, caso mai con il position:absolute attivato. Questo significa che di post-it sulla pagina ne potrei avere un numero imprecisato di n. Il Web Designer che vuole scrivere il foglio di stile per quest'oggetto, seguendo la nostra regola precedente sceglierebbe di usare un div contenitore e assegnargli un id="postIt". In questo modo seguirebbe la nostra regola in quando un post-it non si comporta per se stesso in modo visivamente differente a seconda del contenitore madre. Nella nostra specifica esso è un'oggetto unico e quindi è corretto associargli un'id. I guai arrivano quando il programmatore Javascript (i personaggi di questa ministoria sono 2 diversi ma la questione sarebbe ugualmente imbarazzante anche per un'unico sviluppatore...) tenta di ottenere un puntatore ad uno specifico post-it! Esso si accorge presto che non può usare l'ID come discriminatore in quanto se sulla pagina esistono più elementi con lo stesso ID allora getElementByID() non può restituire un'unico puntatore, al limite può restituire un elenco (array), una lista di elementi che si chiamano tutti allo stesso modo.

Questa lunga e noiosa discussione porta con se una nota conseguenza. Nello sviluppo HTML/Javascript/CSS e in particolare nei fogli di stili, molto dipende dalla visione generale. Non esiste davvero una regola valida per qualsiasi soluzione. Saper vedere il progetto nella sua completezza può aiutare di più delle regole prefissate.

Post correlati

Le meraviglie del CSS2.0+

Giovedì 27 Luglio, 2006

A causa forse delle incompatibilità stilistiche e di output - ancora presenti - tra i vari browser, non tutti conoscono le innumerevoli potenzialità dei fogli di stile. Vogliamo mostrare, quindi, alcune caratteristiche della sintassi CSS sconosciute ai più e per ricordarci quanto poco - spesso - sfruttiamo a pieno gli strumenti che abbiamo a disposizione.

Nota: tutti gli esempio sono stati provati su Firefox 1.5.0.5

Selezione per attributi

HTML:
  1. <div id="myInput">
  2. <input type="submit" value="invia" />
  3. <input type="button" value="Pulisci" />
  4. <input type="button" value="Annulla" />
  5. </div>

CSS:
  1. div#myInput input[type=submit] {color:#f00}
  2. div#myInput input[type=button] {color:#0f0}
  3. div#myInput input[value=Annulla] {color:#00f}

Questa caratteristica, spesso indicata cone CSS2 avanzata, permette cose strabiglianti, se ci riflettiamo un attimo. Il maggior vantaggio lo si ottinene lato HTML, dove non sono necessarie classi o id per distinguere i TAG nel CSS. Sono proprio gli attributi - comunque presenti - nel TAG ad indicare quale stile associare. Inoltre qualsiasi attributo del TAG può essere preso come selettore: alt, title, accesskey, ecc...

Selezione per profondità

Questo tipo di selezione è a dir poco spettacolare, se considerate che può essere sommata a quella precedente. Essa permette di definire la gerarchia degli elementi. Guardando l'esempio qui sotto ci si rendo subito conto della straordinaria portata di questo tipo di selezione, che mantiene il codice HTML pulito e senza indicatori superflui.

HTML:
  1. <div id="myBox">
  2. <p>Paragrafo 1</p>
  3. <p>Paragrafo 2</p>
  4. <p>Paragrafo 3</p>
  5. <p>Paragrafo 4</p>
  6. <p>Paragrafo 5</p>
  7. </div>

CSS:
  1. div#myBox> p       {color:#f00}
  2. div#myBox> p + p {color:#0f0}
  3. div#myBox> p:last-child {color:#00f}

Addirittura, giusto per concludere questo sorvolo, oltre a last-child esiste first-child e - fantastico - first-letter! Provate voi.
Abbiamo ovviamente appena sfiorato l'argomento, alquanto vasto a dire il vero, che vede i CSS come strumento evoluto per la definizione del layput di pagine. Esistono altri selettori e comportamenti e grandi novità per le specifiche dei file CSS di futura generazione.

Post correlati