Layout a bande by Gianluca Brindisi
Da Html.it vi propongo questo utile e breve tutorial di Gianluca per risolvere una piccola questione tecnica di layout quando ci ritroviamo a dover fare un layout simil-liquido: un layout cioè che solo graficamente sembra esser liquido ma che in realtà non lo è.
Leggete e poi tornate qui che ho un commento da fare.
Come avete visto lui ha usato una classe “banda”, che se condo me è di troppo e fa “ammalare” di “classite” il sito. Trovo infatti inutile istituire una classe “banda” quando già puoi definire il width: 100% nei rispettivi id banda1, banda2, banda3. Idem, anche se forse più debole da sostenere come teoria, per quanto riguarda la classe “wrapper” che si può meglio definire con un id wrapper1, wrapper2 e wrapper3. Diciamo che su questa seconda uno può fare come meglio crede, il codice non si appesantisce. Nel primo caso però credo che sia inutile la classe “banda” appunto.
Concordate?



















Add to Google

7 Commenti
Ragionando a oggetti, da sviluppatore se vuoi, il concetto di classe è perfetto per raggruppare elementi con caratteristiche simili. Non vedo nulla di sbagliato nell’assegnare la classe “banda” a tre elementi, anzi, mi pare un uso molto corretto della classe. Il problema secondo me è invece che l’id dei 3 elementi è “bandaN”; dato che l’ID identifica univocamnete un elemento dovrebbe essere più semantico. Però tutto sommato credo che queste siano questioni di lana caprina, ognuno ha un po’ il suo stile. Cosa ne dici?
@Davide: sì ognuno fa quel che crede, era solo un appunto per spiegare ai tanti che me l’hanno chiesto, cosa fosse la “classite”. Come principio ci sta tutto e lo condivido. Certo è che si possono sfruttare al meglio le gerarchie genitoriali dei css senza far ammalare troppo il codice di classite appunto
Ma… francamente in questo caso non credo che si tratti di classite… anche perchè in realtà quello che appesantisci sul markup lo guadagni sul CSS no? (ad esempio specifichi la larghezza solo una volta e non per ogni ID)
Ritengo che la “classite” di Livio non si ritrovi molto in questo esempio
mmmhhh….bisogna vedere qual’è la destinazione di quel layout. Per esempio…se il layout è destinato a contenere informazioni statiche, i discorsi sulla divite e/o sulla classite si limitano solamente alla pesantezza/semplicità della pagina e alla pulizia del codice, anche se alla fine il risultato è lo stesso. Sotto questo punto di vista darei ragione a Lauryn…in quanto non ha senso inserire class, quando con i css puoi tranquillamente identificare l’aspetto dei div sia i “wrapper” che i div “banda”. Invece se il layout è orientato a contenere informazioni dinamiche magari gestite con framework javascript e con il DOM (quello che Davide probabilmente vede come punto di vista dello sviluppatore) l’uso di class o id…diventa fondamentale per identificare 1 div preciso o un gruppo di div. Dipende di cosa si parla.
Poi…c’è 1 altro discorso …che è la semantica del codice. Per esempio…ho sentito dire (e io ora la uso ….solo perchè è diffusa questa pratica) che per un div che contiene il menu si usa l’id con navbar, mentre il div principale che contiene tutto il sito è prassi chiamarlo container, e il contenuto della pagina con wrapper. Allora a questo punto mi sorge spontaneo un dubbio…usare wrapper1, wrapper2, wrapper3….è semanticamente corretto??? Siamo sicuri che gli spider tengono conto della semantica di un sito?
@giancarlo: non è che gli spider tengono conto del fatto se chiami un id wrapper o “contenitore”. puoi chiamarlo anche “vasetto del miele” se per te rende l’idea del contenitore.
il codice semantico inteso per i tag principali (titoli, paragrafi, menu…) è utile, ma per i div che tu li chiami pippo o pluto serve solo a te e non a google
@Lauryn: Ah…meno male…comunque è buono mantenere queste nomenclature per i div. Avere un buon codice può essere utile per la manutenzione, soprattutto se un progetto passa dalle mani di uno sviluppatore ad 1 altro. Mi piacerebbe invece approfondire qualche argomento relativo agli spider. L’ideale sarebbe quello di confrontare le proprie esperienze con gli altri…ma senza elencare trucchi e tecniche come fanno negli altri forum…ma discutendo di teorie vere, possibilmente mostrando prove certe dei risultati acquisiti. Sarebbe molto interessante…
Ciao Laura!
E’ una questione di compromessi. Sicuramente c’è della marcatura superflua nel codice, e sicuramente c’è ampio spazio per ottimizzare.
Sono dell’idea che allo stato attuale i CSS non ti permettano di scrivere codice “riutilizzabile” che sia anche perfettamente ottimizzato da subito.
Per questioni didattiche ho scritto del codice che fosse subito riutilizzabile così come è. Una volta utilizzato poi sta al webdesigner ottimizzarlo, a seconda della pagina su cui sta lavorando. In generale cerco sempre di scrivere il meno possibile (e quindi utilizzando snippet gia preparate e frameworks) e alla fine, fare poi un lavoro di ottimizzazione.
Anche perché cosa e come ottimizzare varia da progetto a progetto, non ha senso secondo me farlo *prima*.