Chi si sarà già avvicinato al fantastico mondo dei CSS, spero anche grazie a questo sito, avrà sicuramente sperimentato queste due proprietà: display e visibility. Avrete sicuramente notato che sono simili come proprietà, ma hanno delle differenze sostanziali: andiamo ad analizzare queste proprietà più da vicino.

Per quanto riguarda la proprietà display, questa specifica il modo di visualizzazione di un elemento: il valore può essere none, block, inline e list-item. Ce ne sarebbero anche altri, ma vista la scarsa implementazione non se ne consiglia troppo l’uso. Il valore none indica che l’elemento non è visibile, il valore block indica che l’elemento sarà visibile come blocco distaccato, quale può essere ad esempio un elemento DIV; il valore inline indica che l’elemento deve assumere un comportamento da blocco in linea quale può essere quello dell’elemento SPAN; list-item indica che l’elemento si comporta come un punto di un elenco.

Per quanto riguarda invece la proprità visibility, essa, come display, imposta la visibilità di un elemento e supporta i valori: hidden(nascosto) e visible(visibile), tuttavia il comportamento è assai diverso da quello di DISPLAY. Un elemento impostato come non visibile attraverso display:none infatti non solo non è visibile, ma lo spazio che avrebbe occupato nella pagina viene rimpiazzato dagli altri elementi, se invece impostiamo visibility:hidden lo spazio cheoccuperebbe l’elemento risulta vuoto, ma viene preservato. Notiamo quindi che entrambe le proprietà possono impostare la visibilità di un elemento, ma la differenza è molto evidente.

Prossimamente analizzeremo la proprietà POSITION e alcune sue caratteristiche. Buona lettura e venite a trovarmi spesso!

Spesso vi sarà capitato di avere due o più regole che, anche con selettori diversi, si riferiscono allo stesso oggetto. In questo caso le due o più regole si applicano contemporaneamente, a cosa accade se alcune dichiarazioni sono in conflitto tra loro? In questo caso entrano in gioco alcune norme definite dal w3c che ci permettono di calcolare la priorità di tali regole. Qui entra in gioco la specificità: maggiore è la specificità, maggiore sarà la priorità assunta da tale regola. La specificità di un selettore si basa su un numero di tre cifre ABC determinate in questo modo:

• A = numero di selettori di tipo ID
• B = numero di classi, pseudoclassi (e di selettori di attributi diversi da ID)
• C = nuemro di selettori di tipo presenti

Qui alcuni esempi:

• selettore [a {}] = specificità 001 in quanto è presente un solo selettore di tipo

• selettore [p a {}] = spcificità 002 in quanto sono presenti due selettori di tipo

• selettore [p a:link {}] = spcificità 012 in quanto sono presenti due selettori di tipo e uno di speusoclassi

• selettore [p#identificatore {}] = specificità 101 in quanto è presente un selettore di tipo ed uno di ID

Quindi, quando due dichiarazioni sono in conflitto si applica la dichiarazione il cui selettore ha maggiore specificità. A parità di specificità si applica la dichairazione scritta per ultima. Spero che questo possa fugare molti dei vostri dubbi e limitare molti errori comuni che spesso mi ritrovo a leggere in newsgroups del settore. Nel prossimo articolo aplieremo la questione della specificità parlando della direttiva !important, non mancate!

Spesso ci troviamo, creando i nostri siti, con la necessità di avere delle colonne affiancate che abbiano la stessa altezza. Il problema sopraggiunge quando una delle due colonne ha un’altezza maggiore dell’altra. In questo caso, se applichiamo un colore di sfondo per ogni colonna, avremo due colone di altezza diversa, vanificando il nostro intento di avere un template con colonne di pari altezza. Come ovviare a questo? la soluzione è davvero molto semplice. Basta applicare un’immagine di sfondo all’elemento precedente le nostre due colonne, body o un altro div contenitore, che simuli due colonne. Questa tecnica viene indicata col nome di FAUX COLUMNS, false colonne, in quanto le colonne sono appunto falese, simulate. Diamo un’occhiata a questa pagina. Come potete vedere, è perfettamente simulato un template con header, footer e due colonne della medesima altezza. Il codice della pagina è questo:

<div id=”center”>
<div id=”header”>
<h1>TITOLO</h1>
</div>
<div id=”nav”>
[contenuto]
</div>

<div id=”content”>
[contenuto]
</div>
<div id=”footer”>
</div>
</div>

abbiamo i vari div ai quali abbiamo poi associato un foglio stile. Eccolo di seguito:

body {
color: #FFFFFF;
margin: 0;
padding: 0;
text-align: center;
}

#header {
height: 125px;
background: url(’img/bg_01.jpg’);
}

#header h1 {
position: absolute;
left: -2000px;
}

#center {
margin: 0 auto;
width: 600px;
background-image: url(’img/bg_03.jpg’);
background-repeat: repeat-y;
text-align: justify;
}

#nav {
float: left;
width: 170px;
padding: 20px 30px 20px 20px;
}

#content {
width: 320px;
padding: 20px 30px 20px 20px;
margin-left: 220px;
}

#footer {
height: 98px;
background: url(’img/bg_05.jpg’);
}

analizziamolo in dettaglio. Per prima cosa abbiamo centrato il div contenitore dando al tag body la proprietà text-align: center per consentire ad IE di centrare l’elemento e abbiamo dato un margin: auto al div content per centrarlo. Fatto questo abbiamo associato all’header questa immagine e agli abbiamo attribuito un’altezza. Poi ci siamo occupati del div contenitore che è quello alla base del nostro trucchetto per ottenere le false colonne, abbiamo infatti, oltre alle solite cose quali altezza e allineamento del testo (che deve essere ridefinito onde evitare l’ereditarietà della proprietà text-align: center definita nel tag body), definito un’immagine di sfondo, questa, per appunto simulare le colonne. Poi abbiamo posizionato i div interni associando al div NAV un float left e al div CONTENT un margin-left per averle affiancate. Infine abbiamo associato questa immagine al footer ed ecco che il nostro template a due colonne è bello e pronto! Come vedete, niente di trascendentale. La tecnica appena descritta è stata provata da me su i browsers gecko e internet explorer fino alla versione 6. Se volete, potete provare e postare qui i vari problemi che incontrate, se ce ne dovessero essere, con browser più datati. Più in avanti ci occuperemo di altre situazioni, compresi layout liquidi, in cui possiamo utilizzare questa tecnica ed infine anche un’ulteriore tecnica che non prevede, almeno per simulare le due colonne, l’utilizzo di un’immagine di sfondo. Quindi, mi raccomando, non mancate e partecipate attivamente commentando e provando voi stessi le varie tecniche proposte nel sito. Solo così potremo crescere in esperienza e favorire chi non ne ha e vuole imparare. A presto

Spesso noi web designer ci troviamo di fronte all’annoso problema di rendere il nostro sito compatibile all’indietro, coi vecchi browser, non perdendo però le funzionalità e il design accattivante visibile coi browsers moderni. Ogni volta quindi che dobbiamo sviluppare un sito dobbiamo sì pensare a come renderlo migliore con le ultime tecnologie verso i browsers attuali, ma anche funzionali e accessibili verso chi ha un browser un po’ datato. Ora, visti i prezzi dell’hardware, vista anche la necessità di aggiornare il proprio sistema, soprattutto in ambito di navigazione web, per non incorrere in sgradevoli virus in grado di aggirare qualche nota falla, trovo, personalmente, un po’ inutile cercare di rendere i siti compatibili con versioni, ad esempio di internet Explorer, inferiori alla 5.5.

Detto questo, in ogni mio sito o applicazione, cerco sempre di rendere il tutto compatibile con gli ultimi standard. Questo perché? Perché penso bisogna cercare una compatibilità verso il futuro e non tanto verso il passato. Certo, non possiamo limitare l’accesso ai nostri siti da parte di chi non ha un browser all’ultimo grido, ma non possiamo nemmeno creare un handicap per chi può usufruire appieno delle nuove tecnologie. Guardare all’indietro può essere utile, ma se questo significa creare hack che in un futuro potrebbero dare problemi, o aggirare il problema con codice non valido e che quindi prossimamente dovrà essere rivisto, allora non sono più d’accordo ad avere un sito compatibile anche all’indietro. Penso piuttosto, ed è quello che faccio io, che bisogna limitare al minimo le incompatibilità attraverso fogli stile molto snelli, e, dove non è possibile e dove vogliamo un sito più elaborato in termini di grafica, semplicemente limitare l’accesso al foglio stile predefinito da parte dei browsers più datati offrendo pertanto una buona visualizzazione o quantomeno accettabile del sito senza però pregiudicare i browsers attuali.

Concludo quindi dicendo un mio personalissimo parere: meglio avere un sito compatibile con gli standard attuali, senza hack e senza artifizi giusto per renderlo compatibile col passato, così da avere un sito il più possibile proiettato verso il futuro. Se tutti i progettisti iniziassero a pensarla così, a mio avviso, anche i produttori dei browsers inizierebbero a pensare a come fare per produrre programmi il più possibile compatibili con gli standard e col passare del tempo, non è infatti una cosa da poco, pian pianino, avremo una quasi totalità di browsers che supportano appieno gli standard.

Precedentemente abbiamo parlato del box model e di come più browsers interpretino in maniera sbagliata o semplicemente del tutto propria, questo box model. Per ovviare a ciò abbiamo introdotto il termine hack che utilizza vari metodi per fare in modo di avere più dichiarazioni per ogni browser. Ce ne sono tanti di hack e molti sono difficili da ricordare e spesso anche inspiegabili in quanto a funzionamento. Qui oggi voglio presentarvi uno degli hack più semplici da implementare e da ricordare. Partiamo dall’inizio. Quando in una dichiarazione di css abbiamo più versioni della stessia proprietà, a prevalere sarà l’ultima partendo dall’alto verso il basso. Se invece aggiungiamo, dopo la dichiarazione, la parola chiava !important, quest’ultima sarà a prevalere. per esempio se abbiamo una dichiarazione di questo tipo:

div {
color: blue !important;
color: green;
}

sarà la prima e non l’ultima proprietà a prevalere e noi avremo un div il cui testo sarà di colore blu in tutti i browsers aderenti alle specifiche css2. Purtroppo IE, versione 6 inclusa, non dà la priorità alla parola chiave !important facendo sì che il testo sia verde. Passando al box model e quindi alle dimensioni vogliamo, per esempio, ottenere un box di larghezza uguale a 200px con una larghezza effettiva di 180px e padding di 10 su entrambi i lati. Utilizziamo quindi questo codice:

div#box {
width: 180px !important;
width: 200px;
padding: 0 10px;
}

Abbiamo ottenuto il risultato voluto almeno nei browsers recenti che interpretano correttamente la parola chiave !important il box model, cioè Opera, Mozilla, Firefox e Safari, e anche in IE 5.x in quanto gli viene fornita una larghezza ad hoc di 200px. Ma sfortunatamente IE 6, non in quirks mode, interpreta correttamente il box model ma non la parola chiave !important per cui abbiamo un box di 220px con tale browser. Per ovviare a tale problema ci basta inserire un commento vuoto (prima dei due punti, e anticipato da uno spazio) per nascondere la seconda dichiarazione a IE6, che verrà comunque interpretata da IE5.x. La versione definitiva è dunque questa:

div#box {
width: 180px !important;
width /**/: 200px;
padding: 0 10px;
}

Come potete vedere, è una tecnica molto semplice e facile da ricordare e può essere usata anche per ovviare ad altri bug. Ne parleremo diffusamente nei prossimi articoli, ma se volete condividere le vostre esperienze commentando, sentitevi liberi di farlo. A presto e buon hack!

Ogni elemento block level crea attorno a se un box. Tale box ha come dimensioni le dimensioni intrinseche dell’elemento nonché i bordi, il padding e i margini. Questa immagine chiarirà meglio il concetto che sto spiegando:

Come possiamo vedere quindi, un box largo 30px con bordi di 1px, padding 10px e margini di 10px, sarà largo complessivamente 52px. Questo è quindi il comportamento che ci si aspetterebbe da un browser in grado di gestire al meglio questa situazione. Ma non è sempre così. Se, attraverso il codice CSS assegnamo una larghezza, quindi un valore a width, pari a 100px per esempio, qualsiasi altro valore che aggiungiamo al padding o al margin o ai bordi, dovrà essere sommato a tale valore. I recenti browsers si comportano così mentre, IE 5.0, 5.5 e 6 in quirks mode, non sommano il valore dei bordi, dei margini e del padding al valore di width, ma bensì, lo sottraggono avendo quindi un box di larghezza complessiva di 100px al cui interno sono compresi i bordi e tutto il resto. Di seguito possiamo vedere un’immagine esplicativa:

Per ovviare a tale inconveniente esistono vari metodi per far passare in un unico foglio stile, più versioni così da avere un box giusto per tutti i browsers. Questi metodi vengono definiti HACK e ne parleremo più diffusamente nei prossimi articoli, non mancate!

Come ben sapete ed avete avuto modo di leggere anche qui su queste pagine, l’xhtml non è altro che una trasposizione dell’html secondo le regole, ben più rigide, dell’xml. Non stupisce quindi che bisogna avere una buona padronanza dell’html prima di poter essere un buon designer e progettista in xhtml. Per questo e quasi per gioco, mi sono imbattuto in un sito in cui veniva proposto, con un timer a tempo, di ricordare quanti più tag html possibile. Ci ho provato e questo è stato il risultato:

52

Non sono andato tanto male a quanto pare e devo dire che quelli che ho dimenticato non sono poi tanto frequenti, mi si può considerare ancora un buon conoscitore dell’html ^_^

Se anche voi volete cimentarvi potete cliccare sull’immagine e andare a fare il piccolo test per poi postare i risultati qui, non siate timidi. Inoltre, dopo aver fatto il test, mi raccomando, solo dopo, potete andare a controllare e a ripassarvi tutti gli elementi HTML sul sito dedicato del w3c, qui.

Vi aspetto quindi e non mancate per i prossimi entusiasmanti articoli sul mondo del web design!!

Come avrete capito, in questo blog mi propongo di esporre sostanzialmente le mie esperienze con XHTML tralasciando l’ormai obsoleto HTML 4.01 nonostante il w3c stia preparando un nuovo working draft su HTML 5.0. Rimaniamo per ora su XHTML quindi e come avrete già visto, XHTML ha vari doctype. Ora ci soffermeremo su quello Strict e su quello Transitional. Per prima cosa, la prima implementazione di XHTML, la 1.0, ha più doctype, Strict, Transitional e Frameset mentre la revisione 1.1 ha una sola DTD, strict per definizione.

Se vogliamo un sito sgombro da tag non semanticamente corretti, allora useremo un Doctype Strict, quindi 1.0 Strict o 1.1. Tale doctype non permette alcuni tag o attributi ritenuti obsoleti dal w3c e che incorporano ancora elementi presentazionali. Il nostro sito pertanto, con questo doctype, sarà pienamente conforme agli standard e privo di codice di presentazione e semanticamente scorretto.

Se invece passiamo da HTML e vogliamo conservare alcuni tag non semanticamente corretti e/o ancora legati all’aspetto presentazionale, useremo un doctype Transitional che, come suggerisce il nome, ci aiuta nella transazione dal vecchio HTML al nuovo XHTML.

Infine, se ancora non siamo convinti nel non utilizzare assolutamente i Frame e vogliamo continuare ad usarli pur essendo conformi all’XHTML, possiamo utilizzare il doctype Frameset.

Queste, in breve, le differenze sostanziali tra i vari doctype. Usate pertanto queste informazioni per decidere quale doctype sia più adatto alle vostre esigenze. Spero vi sia stato utile!

Il tutto nasce agli albori della guerra tra i browser che fortunatamente ora sta andando sempre di più verso un favorevole epilogo, favorevole per gli utenti, cioè una implementazione sempre migliore degli standard w3c. Ma non è stato sempre così…Andiamo con la memoria ai tempi della versione 4 di Explorer e di Netscape. A quei tempi, l’implementazione dei CSS era a dir poco sconcertante e sebbene Explorer li rispettasse maggiormente di quanto non facesse Netscape, i siti venivano comunque visti in maniera non corretta. Explorer 5 ovviò a parecchi bug, ma l’implementazione era lontana dall’essere rispettata in maniera perfetta. Gli sviluppatori pertanto dovevano progettare i propri siti cercando in tutti i modi di adattarsi ai diversi browser e per questo il codice non era molto rispettoso degli standard. Quando poi il rispetto degli standard divenne importante, i produttori dei browsers si trovarono di fronte ad un grosso problema, infatti i siti che avrebbero rispettato gli standard sarebbero stati visualizzati correttamente mentre quelli progettati precedentemente e con un supporto agli standard misero, sarebbero stati visualizzati in maniera non corretta. Pertanto, i browsers dovevano favorire chi conosceva gli standard e progettava secondo questi, ma nondimeno dovevano permettere alle pagine non correttamente sviluppate, di essere viste in maniera decente. La soluzione a questo fu appunto la creazione di browser in grado di riconoscere le pagine sviluppate correttamente e quindi visualizzare secondo gli standard, e quelle non correttamente sviluppate e quindi visualizzarle con una modalità non conforme, detta appunto “quirks mode”. Per fare ciò il browser si affida al DOCTYPE e in base a questo decide come visualizzare la pagina. Fare questo viene definito “doctype switching” e viene implementato come segue:

1. Un doctype completo XHTML 1.0 o 1.1 attiva la modalità Standards (secondo gli standard) in versioni conformi di IE e nelle prime versioni di Gecko (Netscape 6 e Mozilla 1.0)

2. Un doctype completo XHTML Strict ha lo stesso effetto in tutti i browser sopra elencati con l’aggiunta di mozilla 1.01+, netscape 7, firefox 1+, camino

3. Un doctype completo XHTML 1.0 Transitional o Frameset attiva la modalità “Quasi Standards” negli ultimi browsers Gecko

4. Inoltre, a proposito del prologo XML, nonostante abbiamo inserito un doctype completo e che quindi dovrebbe attivare la modalità standard, con il prologo xml, IE6 per Win e Opera 7, vi porteranno in modalità Quirks

5. Doctype incompleti attivano la modalità Quirks in tutti i browsers che implementano il doctype switching

Già, avete sentito bene, c’è anche una modalità “Quasi Standards”. Si chiama così perché differisce dalla modalità Standards di IE per qualche dettaglio. Per questi dettagli, per il modo in cui si comportano i browser con le varie modalità, vi rimando prossimamente per un post a riguardo, dove inizierò a parlare del “BOX MODEL” dei vari browsers, non mancate!

Spesso vi sarà capitato, navigando, di imbattervi in siti in cui alcune sezioni avessero gli angoli arrotondati. Se l’avessimo visto almeno una decina di anni fa non avremmo avuto dubbi sulla loro implementazione. Si sarebbe infatti trattato di tabelle annidate con immagini al proprio interno: un approccio assolutamente da non perseguire in un web che sempre di più si batte per un codice semanticamente corretto e che non appesantisca le pagine. Vediamo quindi come fare ad ottenere, utilizzando immagini, box con angoli smussati utilizzando semplicemente i CSS. Il primo approccio che andremo a verificare è quello di un box a larghezza fissa. Per prima cosa quindi, col nostro programma di grafica, dobbiamo creare due immagini che andremo a posizionare in alto e in basso. Poi dovremo creare due DIV annidati ai quali poi attribuiremo delle semplicissime regole per ottenere un effetto di sicuro impatto, leggero e semplice da implementare. Come detto in precedenza, questo è un ottimo approccio per box di larghezza fissa. Qui potrete trovare una pagina esplicativa dalla quale copiare e analizzare il codice di questo esempio appena descritto.

Se invece abbiamo l’esigenza di creare un box, cosiddetto “liquido” e cioè non a larghezza fissa, ma che si può ridimensionare, abbiamo la necessità, non più di creare immagini a larghezza fissa, ma bensì dovremo creare i quattro angoli col nostro programma di grafica preferito così poi da implementarli nel nostro codice, come immagini di sfondo per quattro DIV che andremo ad annidare. Qui potrete trovare una pagina esplicativa dalla quale copiare e analizzare il codice di questo esempio. Noterete che la larghezza del box non è espressa con un numero preciso di pixel, ma è in percentuale, proprio per far notare come questo approccio sia indipendente dalle dimensioni del box. Non per ultimo, c’è un ulteriore metodo per implementare angoli arrotondati con i CSS, detto “modular corners”. Si tratta in questo caso di ottenere un box a larghezza fissa, ma che si adatta in altezza al contenuto al suo interno. Questo effetto lo otteniamo con una semplice immagine che andremo ad associare agli unici due DIV annidati che avremo. L’immagine che andremo a editare col nostro programma di grafica preferito, avrà pertanto, una larghezza fissa e una altezza massima decisa da noi, che però non sarà quella visibile in un primo momento, ma sarà quella massima fin alla quale avremo la possibilità che il nostro box si potrà adattare. Vediamo qui un esempio esplicativo con tanto di codice.

Penso che sia tutto…qualcuno ha cercato di creare anche angolo non utilizzando immagini, ma il risultato, pur essendo pulito e senza appunto immagini, non è dei migliori soprattutto se il box viene allargato. Così invece otteniamo ciò che vogliamo, con codice standard, accessbile, non tanto semanticamente corretto, questo è da dirlo, ma pur di non utilizzare javascript, quindi un approccio poco accessibile, meglio scendere a compromessi con la semantica e quindi ottenere un bel risultato visivo e usabile al tempo stesso. Buon markup a tutti con gli angoli arrotondati coi CSS!