« Due parole sul box model di questo blog »

16 febbraio 2011 @ 17:26

EDIT: Bug, ho dovuto revertare perché dopo aver aggiustato tutto ho rotto un’altra cosa. Bello HTML, quasi quasi lo odio… Viva le tabelle!
alla fine ho sistemato tutto, ma si è reso necessario un add-on a questo post.

Il box model è la modalità di formattazione definita dalla combinazione di HTML e fogli di stile (CSS). Per i non addetti, potrei riassumerlo in italiano corrente come la regola base da conoscere per lavorare con HTML e CSS. I non addetti ai lavori possono uscire da questo articolo, è lungo, palloso e non fa per voi.

Non voglio entrare in tecnicame che non sono nemmeno sicuro di conoscere così bene, voglio solo fare un esempio di box model vero (questo blog) e dei problemi che questo si porta dietro. Tenete conto che la lunghezza del post è direttamente proporzionale al casino che mi ci è voluto per sistemarlo, il che da l’idea di quanto possa essere problematico un layout web.

Potete pensare a una pagina web come un’insieme di scatolotti quadrati (correttamente blocchi, ma li chiamerò anche box o quadratoni ^_^ ) con cui si devono fare i conti: in genere si mettono scatolotti dentro altri scatolotti e si impilano scatolotti uno sopra l’altro.
In questo post troverete alcuni spunti su come il browser organizza il flusso dei blocchi nella pagina, soprattutto sulla croce e delizia del webmaster che si rispetti: tentare di affiancare due scatolotti senza usare tabelle.

Questo è il favoloso sviluppo table-less, un mito spesso inseguito e poi abbandonato soprattutto perché Internet Explorer si fa i cavoli suoi fino a scatenare tendenze omicide negli sviluppatori. Alla fine tutti usano il modello di sviluppo basato sulle tabelle. Quick & dirty, molto dirty.

Ma siccome io sono un vero figo vi faccio vedere due modi diversi di usare il box model table-less che producono lo stesso risultato con mezzi (e problemi) differenti.

Versione uno

Questa è la vecchia versione del  blog:

Box model del blog prima della revisione

Innanzitutto la scatolona nera è la pagina stessa, che contiene tutto. All’interno ci sono quattro DIV, ognuno di questi rappresenta un elemento, l’HEADER è l’intestazione con la foto e il titolo, il CONTENT è lo scatolone che conterrà tutti i post, la SIDEBAR contiene il menù e il FOOTER alcune informazioni accessorie.

Senza definizioni di stile  si vedrebbero i quadrati impilati tutti i fila, uno dopo l’altro. Prima l’header, subito sotto i post, sotto i post il menù e sotto il menù il piè di pagina. In pratica si vedrebbe così.

Sidebar

Il modo di piazzare il menù è  un barbatrucco, si prende il blocco SIDEBAR e lo si sottrae al normale flusso della pagina col css position:absolute. Questo comando dice al browser che lo scatolotto non sarà più al suo posto naturale ma gli verrà dato un punto assoluto partendo dall’angolo in alto a sinistra della pagina. Naturalmente coprirebbe l’header, quindi bisogna spostarlo dall’alto (css top: 260px) e impostare manualmente la larghezza (css width:270px) perché non finisca a tutta pagina.
Chiaramente questo layout ha due problemi: uno, è facile da gestire se l’header ha un’altezza fissa, se l’header è variabile credo sia impossibile. Due: ti costringe ad avere un menù a larghezza fissa, credo anche qui gestire larghezze variabili sia impossibile. Insomma, bello ma poco liquido, anche se a me va benissimo così.

Content

Ora bisogna risolvere un problema: spostare il margine destro del blocco CONTENT perché non finisca sotto il menù. Come già dettola SIDEBAR è fuori dal normale flusso, il browser non la conta e lascia che lo scatolotto contenitore si allarghi a tutta pagina.
Il metodo che preferisco è mettere un bel margine a sinistra (css margin-left:240px), il blocco lascia lo spazio che serve al menù. E’ il metodo che preferisco perché rende facilmente liquida la parte dei contenuti e di solito funziona bene al primo colpo con tutti i browser.

Un altro piccolo tocco è lo spostamento del blocco CONTENT in alto di qualche pixel, il cui scopo è sovrapporre lo scatolotto con l’HEADER. Combinato con l’immagine di sfondo da quel bell’effettino sfalsato al blog.
Si mette il blocco in posizione relativa (css position:relative), in questo modo il browser prima calcola la posizione dello scatolotto come se fosse un normalissimo blocco,  poi accetta modifiche relative.
Nel nostro caso si sposta il blocco CONTENT di 140 pixel (css top:-140px) sopra la sua linea naturale, andando a sovrapporsi all’header.
NB: Se non mettete il position relative qualsiasi modifica in tal senso verrà ignorata.

Footer

Ora veniamo alla grossa sòla di questo layout che mi ha portato a cambiarlo, cioè il footer che finisce direttamente sotto il menù quando il CONTENT è poco alto (perché poco pieno). Guardate qui una diapositiva.
Perché accade questo?  Sempre il solito motivo, la SIDEBAR è assoluta il FOOTER non calcola la sua presenza è collide nello stesso spazio, finendo sotto.
La soluzione più semplice sarebbe quella di trattare il FOOTER come il CONTENT, mettendo un margine anche a lui… ma lascerebbe un buco a sinistra e non mi piace l’idea.

Versione due

La versione due è così:

Box model del blog dopo la revisione

Il cambiamento,  in soldoni, è che la SIDEBAR non è più assoluta ma flottante (css float: left). Il float è un comando che permette al box di restare nel flusso dei blocchi ma di galleggiare (to float) su un lato. La differenza è sottile, per esempio non mi serve più spostarlo dall’alto per non farlo cozzare con l’header (css top: 260px) ma devo comunque spostare il CONTENT con il margine per non farlo finire sotto e devo comunque specificare la larghezza.

Il float, a differenza della posizione assoluta, reagisce a un comando chiamato clear. Clear applicato a un blocco obbliga il browser a non accettare alcun quadratone a lato del blocco stesso.
Per vederlo nell’esempio, il blocco FOOTER finisce sotto il blocco SIDEBAR perchè ha il clear (css clear:both) impostato, il browser non accetta che stia da parte a un blocco flottante e lo sposta subito sotto. Risolto il problema del footer :) .

La menata della posizione relativa

Notare bene: ho messo sia CONTENT che FOOTER a posizione relativa -140px. Perché?
La posizione relativa ha una piccola particolarità, sposta il blocco ma non lo spazio occupato. Dura da capire? Ecco un’immagine esplicativa:

Particolarità del box model con posiziamento relativo

Quando si sposta un blocco con il css relative il browser  occupa lo spazio come se il blocco fosse al suo posto naturale, non si basa sull’effettiva posizione.
Questo vuol dire che se per esempio prendo un blocco e relativamente lo sposto dall’altra parte della pagina, lascerò un bel buco vuoto al suo posto. Proprio come se lui fosse davvero lì.
Quindi se non spostassi il FOOTER mi troverei un bel buco vuoto tra CONTENT e FOOTER, dovuto al naturale posizionamento della scatola contenuto.  Allora sposto anche il FOOTER di -140px, così tappo il buco. Giusto? Manco per il ca##o!

Come accade spesso aggiusti una cosa  e se ne rompe un’altra.
Il FOOTER ha il clear, per cui dovrebbe finire sotto la SIDEBAR o al CONTENT, dipende quale è il più alto. Solo che se il più alto è il CONTENT (CASO 1) è tutto ok, mentre se è la SIDEBAR ad essere più alta (CASO 2) il FOOTER va sotto il menù ma poi si sposta di -140px e collide col menù stesso. In pratica sono tornato al punto di partenza.

Qual’è la soluzione definitiva? Mi ci è voluto un po’ per pensarla, ed è un po’ sporca… si mette un margine di 140px (css margin-bottom:140px) sotto la SIDEBAR che compensa lo spostamento del FOOTER (soluzione) quando è il menù ad essere più alto.  Se è CONTENT ad essere più alto, spingerà giù il FOOTER e il margine diventerà semplicemente inutile.

Problema e soluzione a causa del footer spostato in alto
Tutto questo percorso è il frutto di vari tentativi che hanno esplorato anche molte altre strade diverse, alcune delle quali si sono rivelate vicoli ciechi. Potete capire che lavorare sul layout di una pagina può diventare complesso, specie se non è un semplice due colonne come questo blog.
Per questo molti preferiscono tagliar corto lavorando con le tabelle, che sono più facili da implementare anche se qualitativamente meno pregiate.

Un commento a “Due parole sul box model di questo blog”

  1. Picchiarsi col box model di questo blog - Gerry's blog - Tech, Trips, Anime & clouds ha detto:
    24 febbraio 2011 alle 17:46

    […] La seconda parte è stata aggiunta in seguito ad un lievissimo problema con l’ultima versione del box model che avevo pensato. Per la storia completa vedete il vecchio post. […]

Lascia un commento