-
Note implementativeRichieste ForumMe ne sono reso conto solo ora...

In realtà magari no, non me lo ricordo, ma mi sono ricordato ora di lamentarmene...


L'elenco dei thread è una lista. L'HTML dispone di tag apposta per le liste. Non solo usare i tag giusti HTML quando ci sono semplifica il lavoro ma:
1) rende l'accessibilità delle pagine molto migliore (uno screenreader è in grado di navigare le liste sapendo chi è padre e chi è figlio di chi e permettendo una navigazione veloce fra "generazioni" a chi non sta usando un browser "normale" per via di una disabilità temporanea o permaente)
2) permette di avere gratis alcune cose... come ad esempio evitare l'orribile hack che mischia HTML e CSS specificando in pixel i rientri (le liste già sanno che devono rientrare rispetto al genitore)
In genere è buona regola usare i tag HTML corretti nelle situazioni corrette. IMO questa è una di quelle.-
Re: Note implementativeRichieste ForumScritto da: Daisuke Niwa
> 2) permette di avere gratis alcune cose... come ad esempio evitare l'orribile hack che mischia HTML e CSS specificando in pixel i rientri (le liste già sanno che devono rientrare rispetto al genitore)
Questa e' una cosa bella assai
!
> In genere è buona regola usare i tag HTML corretti nelle situazioni corrette. IMO questa è una di quelle.
L'unico che ci capiva qualcosa di HTML, Dolce&Wakkana, si e' dato alla macchia
!
Magari ci puoi aiutare te
?
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Note implementativeRichieste ForumScritto da: Giambo
> Scritto da: Daisuke Niwa
>
> > 2) permette di avere gratis alcune cose... come ad esempio evitare l'orribile hack che mischia HTML e CSS specificando in pixel i rientri (le liste già sanno che devono rientrare rispetto al genitore)
>
> Questa e' una cosa bella assai
!
>
> > In genere è buona regola usare i tag HTML corretti nelle situazioni corrette. IMO questa è una di quelle.
>
> L'unico che ci capiva qualcosa di HTML, Dolce&Wakkana, si e' dato alla macchia
!
> Magari ci puoi aiutare te
?
Fra l'altro c'è anche un display: none che devo attaccare a un pulsante appena ne ho l'occasione.
-
Re: Note implementativeRichieste ForumScritto daNon Autenticatoil 2012-04-07 20:46:36.0 alle 2012-04-07 20:46:36.0> > > 2) permette di avere gratis alcune cose... come ad esempio evitare l'orribile hack che mischia HTML e CSS specificando in pixel i rientri (le liste già sanno che devono rientrare rispetto al genitore)
> >
> > Questa e' una cosa bella assai
!
> >
> > > In genere è buona regola usare i tag HTML corretti nelle situazioni corrette. IMO questa è una di quelle.
> >
> > L'unico che ci capiva qualcosa di HTML, Dolce&Wakkana, si e' dato alla macchia
!
> > Magari ci puoi aiutare te
?
>
> Fra l'altro c'è anche un display: none che devo attaccare a un pulsante appena ne ho l'occasione.
Siamo tutti con te!
-
-
Re: Note implementativeRichieste ForumScritto da: Giambo
> Scritto da: Daisuke Niwa
> L'unico che ci capiva qualcosa di HTML, Dolce&Wakkana, si e' dato alla macchia
!
> Magari ci puoi aiutare te
?
se volete non lo faccio io, e poi non venitemi a dire che non aiuto la comunitàPlease consider the environment before printing this message, 50% of the above is useless!-
Re: Note implementativeRichieste ForumScritto da: dada216
> > L'unico che ci capiva qualcosa di HTML, Dolce&Wakkana, si e' dato alla macchia
!
> > Magari ci puoi aiutare te
?
>
> se volete non lo faccio io, e poi non venitemi a dire che non aiuto la comunità
Capisci HTML&CSS ? A livello di Dolce&Wakkana o a livello di ex ma con il gusto dell'orrido di Avve ?`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Note implementativeRichieste ForumScritto da: Giambo
> Scritto da: dada216
>
> > > L'unico che ci capiva qualcosa di HTML, Dolce&Wakkana, si e' dato alla macchia
!
> > > Magari ci puoi aiutare te
?
> >
> > se volete non lo faccio io, e poi non venitemi a dire che non aiuto la comunità
>
> Capisci HTML&CSS ? A livello di Dolce&Wakkana o a livello di ex ma con il gusto dell'orrido di Avve ?
-
Re: Note implementativeRichieste ForumScritto da: Daisuke Niwa
> > > se volete non lo faccio io, e poi non venitemi a dire che non aiuto la comunità


`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo
-
-
-
-
-
Re: Note implementativeRichieste Forum`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo
-
Re: Note implementativeRichieste ForumScritto da: Giambo
>
>
>
> Mi vuoi bene ora
?
Sembra apposto, sì... ma elimina quel "style" e piazzalo nel file CSS, così se un giorno lo si vuole cambiare non serve andare a cercarlo nel codice.
> Wakko, ho seriamente bisogno di te, delle tue conoscenze in CSS
!!!
Belink?-
Re: Note implementativeRichieste ForumScritto da: Daisuke Niwa
> >
> >
> >
> > Mi vuoi bene ora
?
>
> Sembra apposto, sì...
"si" mi vuoi bene
?
> ma elimina quel "style" e piazzalo nel file CSS, così se un giorno lo si vuole cambiare non serve andare a cercarlo nel codice.
Vedi sotto.
> > Wakko, ho seriamente bisogno di te, delle tue conoscenze in CSS
!!!
>
> Belink?
IMHO il CSS e' un po caotico. Chiaro, e' cresciuto cosi', anarchicamente, pero' quando ho cercato di riutilizzar "questo" frammento di jsp (Scrivi messaggio) in "scrivi PVT" mi sono imbattuto in problemi insormontabili per le mie capacita'.
Una volta avevi suggerito di "spezzare" il CSS, questa e' la mia idea:
- Un css "globale" con le definizioni -appunto- globali: fdt.css
- Ogni servlet (/Messages, /Threads, /Pvt, ...) include automagicamente il suo CSS dal nome fdt${servlet}.css (fdtMessages.css, fdtThreads.css, ...)
- Darci dentro con le classi: Cose come "div.registrationCaptcha div div.registrationCaptchaInput" sono IMHO difficili da gestire.
- Eliminare i doppioni e/o mettere a posto cose oVVibili come la sezione Sondaggi
Conosci altre "best practices" per quel che concerne la gestione dei CSS ?`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Note implementativeRichieste ForumScritto da: Giambo
> > Sembra apposto, sì...
>
> "si" mi vuoi bene
?
Too old
> IMHO il CSS e' un po caotico. Chiaro, e' cresciuto cosi', anarchicamente, pero' quando ho cercato di riutilizzar "questo" frammento di jsp (Scrivi messaggio) in "scrivi PVT" mi sono imbattuto in problemi insormontabili per le mie capacita'.
Io faccio così:
- un css globale che tiene lo stile comune a tutte le pagine (es: i bordi della pagina, lo sfondo, lo stiling dell'header, ecc)
- un css specifico per ogni pagina
- un css a parte per ogni "componente ajax", ovvero quelle parti di gui che compaiono in più pagine richiamate da ajax o comunque condivise
Tutte le pagine includono il CSS globale, il loro CSS specifico e il CSS di tutti i componenti condivisi attinenti a quella pagina.
Ovviamente cerco sempre di usare le classi per essere sicuro che le varie stilate non vadano in conflitto fra loro.
Per esempio...
se ho un componente condiviso, diciamo "maschera messaggio", allora tutti gli stili che riguardano quella maschera incominceranno con qualcosa tipo:
div.mascheraMessaggio div.msg {
}
div.mascheraMessaggio #sendBtn {
}
div.mascheraMessaggio div.msg textarea {
}
Così se ci sono altri div.msg e altri textarea in giro per la pagina che include questo componente questi non vengono toccati.
Ovviamente gli stili invece usati globalmente ha senso metterli nel CSS globale, soprattutto cose tipo i "temi", ovvero quelle combinazioni di colori e look&feel che se cambiano devono cambiare ovunque nel sito per avere una GUI coerente.
In questo modo non solo eviti i problemi di cui parli, ovvero namespace intasato, ecc... ma ottieni gratis un altro vantaggio... ovvero quello di avere file CSS piccolini e molto veloci a caricarsi.
La stessa cosa identica precisa sputata vale per i file javascript: uno globale per le funzioni condivise fra più pagine, e uno specifico per ogni pagina.
Tutte le pagine includono il js globale, il loro js specifico e il js di tutti i componenti condivisi caricati con ajax o meno.
Purtroppo sta cosa l'ho capita "tardi", e ora mi trovo con progetti con CSS da 160k...
**Modificato dall'autore il 13.04.2012 12:48**-
Re: Note implementativeRichieste ForumScritto daNon Autenticatoil 2012-04-13 13:40:13.0 alle 2012-04-13 13:40:13.0Scritto da: Daisuke Niwa
> Scritto da: Giambo
> > > Sembra apposto, sì...
> >
> > "si" mi vuoi bene
?
>
> Too old
>
> > IMHO il CSS e' un po caotico. Chiaro, e' cresciuto cosi', anarchicamente, pero' quando ho cercato di riutilizzar "questo" frammento di jsp (Scrivi messaggio) in "scrivi PVT" mi sono imbattuto in problemi insormontabili per le mie capacita'.
>
> Io faccio così:
> - un css globale che tiene lo stile comune a tutte le pagine (es: i bordi della pagina, lo sfondo, lo stiling dell'header, ecc)
> - un css specifico per ogni pagina
> - un css a parte per ogni "componente ajax", ovvero quelle parti di gui che compaiono in più pagine richiamate da ajax o comunque condivise
>
> Tutte le pagine includono il CSS globale, il loro CSS specifico e il CSS di tutti i componenti condivisi attinenti a quella pagina.
> Ovviamente cerco sempre di usare le classi per essere sicuro che le varie stilate non vadano in conflitto fra loro.
> Per esempio...
> se ho un componente condiviso, diciamo "maschera messaggio", allora tutti gli stili che riguardano quella maschera incominceranno con qualcosa tipo:
>
> div.mascheraMessaggio div.msg {
> }
>
> div.mascheraMessaggio #sendBtn {
> }
>
> div.mascheraMessaggio div.msg textarea {
> }
>
> Così se ci sono altri div.msg e altri textarea in giro per la pagina che include questo componente questi non vengono toccati.
>
> Ovviamente gli stili invece usati globalmente ha senso metterli nel CSS globale, soprattutto cose tipo i "temi", ovvero quelle combinazioni di colori e look&feel che se cambiano devono cambiare ovunque nel sito per avere una GUI coerente.
>
> In questo modo non solo eviti i problemi di cui parli, ovvero namespace intasato, ecc... ma ottieni gratis un altro vantaggio... ovvero quello di avere file CSS piccolini e molto veloci a caricarsi.
>
> La stessa cosa identica precisa sputata vale per i file javascript: uno globale per le funzioni condivise fra più pagine, e uno specifico per ogni pagina.
> Tutte le pagine includono il js globale, il loro js specifico e il js di tutti i componenti condivisi caricati con ajax o meno.
>
> Purtroppo sta cosa l'ho capita "tardi", e ora mi trovo con progetti con CSS da 160k...
>
>
> **Modificato dall'autore il 13.04.2012 12:48**
in questo modo però per avere la pagina finale devi caricare 200 file
-
Re: Note implementativeRichieste ForumScritto da:
> in questo modo però per avere la pagina finale devi caricare 200 file
La mia soluzione carica solo il CSS principale e il CSS specifico di quella pagina
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Note implementativeRichieste ForumScritto daNon Autenticatoil 2012-04-13 13:49:58.0 alle 2012-04-13 13:49:58.0Scritto da: Giambo
> Scritto da:
>
> > in questo modo però per avere la pagina finale devi caricare 200 file
>
> La mia soluzione carica solo il CSS principale e il CSS specifico di quella pagina
il css specifico di una pagina lo puoi mettere dentro la pagina stessa.
comunque l'idea di wakko ha senso però è estremizzata: io raggrupperei i CSS per funzione (form, visualizzazione, stampa)
uno per ogni widget è troppo-
Re: Note implementativeRichieste ForumScritto da:
> Scritto da: Giambo
> > Scritto da:
> >
> > > in questo modo però per avere la pagina finale devi caricare 200 file
> >
> > La mia soluzione carica solo il CSS principale e il CSS specifico di quella pagina
>
> il css specifico di una pagina lo puoi mettere dentro la pagina stessa.
Neanche per sogno. Non devo stare a ricompilare il sito ogni volta che devo cambiare il colore di un bordo... e poi mi sporca il codice, rende le pagine HTML più lunghe e difficili da debuggare... includere i file CSS nelle pagine è come spararsi sui coglioni.
> comunque l'idea di wakko ha senso però è estremizzata: io raggrupperei i CSS per funzione (form, visualizzazione, stampa)
>
> uno per ogni widget è troppo
Il punto è che in questo modo quel widget avrà lo stesso aspetto ovunque tu lo chiami, e sarà anche veloce modificarlo perché sai subito che l'aspetto di quel widget è relegato in quel file. Inoltre come dicevo prima è difficile che una pagina usi più di un paio di widget comuni... che alla fine sono davvero pochi.
Quanti sono su questo sito?
Il widget per inserire il messaggio...
Poi?
-
Re: Note implementativeRichieste ForumScritto da:
> > La mia soluzione carica solo il CSS principale e il CSS specifico di quella pagina
>
> il css specifico di una pagina lo puoi mettere dentro la pagina stessa.
Preferisco tenerlo in un file a parte.
> comunque l'idea di wakko ha senso però è estremizzata: io raggrupperei i CSS per funzione (form, visualizzazione, stampa)
>
> uno per ogni widget è troppo
Non sono abbastanza pratico per dire quale sia la "best practice"
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo
-
-
Re: Note implementativeRichieste ForumScritto da: Giambo
> Scritto da:
>
> > in questo modo però per avere la pagina finale devi caricare 200 file
>
> La mia soluzione carica solo il CSS principale e il CSS specifico di quella pagina
In tal caso dovresti mettere il CSS dei widget condivisi (tipo la div per l'invio dei messaggi) nel CSS globale... ma alla fine vai ad ingrandire un file CSS per niente.-
Re: Note implementativeRichieste ForumScritto da: Daisuke Niwa
> > La mia soluzione carica solo il CSS principale e il CSS specifico di quella pagina
>
> In tal caso dovresti mettere il CSS dei widget condivisi (tipo la div per l'invio dei messaggi) nel CSS globale... ma alla fine vai ad ingrandire un file CSS per niente.
L'alternativa e' o avere dei doppioni o avere un file per ogni componente condivisa.
Quest'ultima soluzione mi fa paura: Si rischia una grande frammentazione (10, 20 CSS in totale) con difficolta' nel trovare quale CSS definisce quale componente e, sopratutto, vedere il browser che deve richiedere 20 micro-CSS invece che uno solo.
Ma, come detto, non sono esperto in materia, magari tu riesci a tirare fuori una soluzione elegante
!
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Note implementativeRichieste ForumScritto da: Giambo
> Scritto da: Daisuke Niwa
>
> > > La mia soluzione carica solo il CSS principale e il CSS specifico di quella pagina
> >
> > In tal caso dovresti mettere il CSS dei widget condivisi (tipo la div per l'invio dei messaggi) nel CSS globale... ma alla fine vai ad ingrandire un file CSS per niente.
>
> L'alternativa e' o avere dei doppioni o avere un file per ogni componente condivisa.
> Quest'ultima soluzione mi fa paura: Si rischia una grande frammentazione (10, 20 CSS in totale) con difficolta' nel trovare quale CSS definisce quale componente e, sopratutto, vedere il browser che deve richiedere 20 micro-CSS invece che uno solo.
La domanda è: quanti widget condivisi ci sono per ogni pagina?
Per "widget condivisi" non intendo oggetti con stili in comune che possono andare nel CSS globale, ma intendo oggetti tipo l'inserimento dei messaggi che viene renderizzato su diverse pagine (o incluso direttamente nell'HTML della pagina o aggiunto via ajax).
Il widget per l'inserimento dei messaggi è uno... quali sono gli altri?
Io in genere creo i widget su file PHP indipendenti, per poi includerli quando serve. Il file CSS associato ha lo stesso nome del file PHP che contiene il widget, quindi non c'è pericolo di sbagliarsi o di non sapere più quale file CSS va assegnato a quale widget.
Se per esempio ho il widget "wdgInserisciMessaggio" allora avrò questi 3 file:
- widget\wdgInserisciMessaggio.php
- script\wdgInserisciMessaggio.js
- css\wdgInserisciMessaggio.css
Se voglio cambiare la width del relativo pulsante "INVIA" del widget mi basta modificare wdgInserisciMessaggio.css e cambierà ovunque quel widget è usato (non mi interesserà scoprire nemmeno in quali pagine è usato se non per testarlo).
Ogni pagina che userà quel widget ovviamente dovrà includere nell'header dell'HTML wdgInserisciMessaggio.js e wdgInserisciMessaggio.css, ma tutte le altre pagine non saranno toccate.
Ora è chiaro che se i widget sono 10 o più per pagina, allora ti conviene inserire tutti i widget in un solo file css/js dei widget e li distingui attraverso le classi. Ma finché sai che ogni pagina al massimo includerà un paio di widget non vedo ragione di fasciarsi la testa.
Se comunque pensi che il forum potrà espandersi fino ad avere più di due widget per pagina allora crea un file unico css e js per tutti i widget e carica quello nelle pagine che li usano... per ogni buon conto, anche all'interno dei singoli CSS dei widget, usa le classi... in questo modo se un domani si metteranno assieme in un unico file non ci saranno problemi di namespace intasato.
Cmq questa cosa dei presunti rallentamenti nel caricare la pagina a causa dei troppi file css/js sono problemi inesistenti IMO, si notano solo la prima volta che apri quella pagina... poi la cache del browser dovrebbe fare il suo lavoro e tenerli memorizzati in locale.-
Re: Note implementativeRichieste ForumScritto da: Daisuke Niwa
> Per "widget condivisi" non intendo oggetti con stili in comune che possono andare nel CSS globale, ma intendo oggetti tipo l'inserimento dei messaggi che viene renderizzato su diverse pagine (o incluso direttamente nell'HTML della pagina o aggiunto via ajax).
In questo caso non tanti: Tutti gli elementi di contorno (Il banner in cima, la navigazione, il footer, la barra laterale, ...), l'inserimento messaggio e la visualizzazione dl messaggio.
> Io in genere creo i widget su file PHP indipendenti, per poi includerli quando serve. Il file CSS associato ha lo stesso nome del file PHP che contiene il widget, quindi non c'è pericolo di sbagliarsi o di non sapere più quale file CSS va assegnato a quale widget.
I "widgets" sono JSP con il nome che inizia con "inc". Non corrispondono direttamente a un widget, ma quasi
Il numero di pagine e' cresciuto, credo che dovrei separarle per "contesto" (Messages / Threads / User / Pvt / Polls)
> Ora è chiaro che se i widget sono 10 o più per pagina, allora ti conviene inserire tutti i widget in un solo file css/js dei widget e li distingui attraverso le classi. Ma finché sai che ogni pagina al massimo includerà un paio di widget non vedo ragione di fasciarsi la testa.
Io propenderei per una versione intermedia: Invece che dover pensare ogni volta quali CSS includere, io definirei un CSS specifico per ogni "contesto" (Vedi sopra), il CSS viene automagicamente caricato (<link href="css/${contesto}.css type="text/css" rel="stylesheet" />
BTW, hai una "naming convention" per le classi CSS ? Qualcosa che possa velocemente farmi capire di che componente si tratta, in che file e in che contesto. E che eviti naming-clash
> Cmq questa cosa dei presunti rallentamenti nel caricare la pagina a causa dei troppi file css/js sono problemi inesistenti IMO, si notano solo la prima volta che apri quella pagina...
La Fondazione Gatto Selvaggio cerca di risparmiare su ogni MIPS e su ogni KB trasmesso: Se il browser deve aprire 10 connessioni TCP per 10 CSS, l'overhead potrebbe prosciugare le casse nel giro di pochi mesi
!
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Note implementativeRichieste ForumScritto da: Giambo
> In questo caso non tanti: Tutti gli elementi di contorno (Il banner in cima, la navigazione, il footer, la barra laterale, ...),
Questi non sono widget, io per widget intendo qualcosa di interattivo con l'utente. Quelli che hai menzionato sono oggetti comuni a tutte le pagine del sito, perciò ha senso metterle nel CSS generale.
> l'inserimento messaggio e la visualizzazione dl messaggio.
Questi sì sono widget... forse la visualizzazione del messaggio non lo è e visto che questo è un forum e visualizzare messaggi è il suo scopo avrebbe forse senso metterlo nel CSS generale.
Inserire il messaggio invece è un widget interattivo che viene caricato solo di tanto in tanto perciò ha senso che abbia il suo css e js separati, IMO.
> I "widgets" sono JSP con il nome che inizia con "inc". Non corrispondono direttamente a un widget, ma quasi
Hmmm no, io vedo i widget come oggetti interattivi che vengono caricati di tanto in tanto, solo quando servono.
> Io propenderei per una versione intermedia: Invece che dover pensare ogni volta quali CSS includere, io definirei un CSS specifico per ogni "contesto" (Vedi sopra), il CSS viene automagicamente caricato (<link href="css/${contesto}.css type="text/css" rel="stylesheet" />
Bé, vedi tu quello che ti va meglio.
> BTW, hai una "naming convention" per le classi CSS ? Qualcosa che possa velocemente farmi capire di che componente si tratta, in che file e in che contesto. E che eviti naming-clash
Non ne ho. I widget potrebbero cominciare con "wdg", le form con "frm", e via avanti, dipende se ha senso farlo o no.
> La Fondazione Gatto Selvaggio cerca di risparmiare su ogni MIPS e su ogni KB trasmesso: Se il browser deve aprire 10 connessioni TCP per 10 CSS, l'overhead potrebbe prosciugare le casse nel giro di pochi mesi
!
Bé, certo, ma fintanto che sono pochi non ci vedo problemi.-
Re: Note implementativeRichieste ForumScritto da: Daisuke Niwa
Ok, credo di essermi fatto piu' o meno un idea.
Ora devo solo trovare la motivazione per mettere a posto il CSS
O trovare un volontario. Qualcuno che abbia voglia di dimostrare il suo talento, qualcuno pronto a sfidare se' stesso, qualcuno di generoso



Ma allora sei di coccio
!
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Note implementativeRichieste ForumScritto da: Giambo
> Scritto da: Daisuke Niwa
>
> Ok, credo di essermi fatto piu' o meno un idea.
> Ora devo solo trovare la motivazione per mettere a posto il CSS
>
> O trovare un volontario. Qualcuno che abbia voglia di dimostrare il suo talento, qualcuno pronto a sfidare se' stesso, qualcuno di generoso

Si anche io pensavo a suoranciata.
-
-
-
-
-
-
-
-
Re: Note implementativeRichieste ForumScritto da:
> Scritto da: Daisuke Niwa
> > Scritto da: Giambo
> > > > Sembra apposto, sì...
> > >
> > > "si" mi vuoi bene
?
> >
> > Too old
> >
> > > IMHO il CSS e' un po caotico. Chiaro, e' cresciuto cosi', anarchicamente, pero' quando ho cercato di riutilizzar "questo" frammento di jsp (Scrivi messaggio) in "scrivi PVT" mi sono imbattuto in problemi insormontabili per le mie capacita'.
> >
> > Io faccio così:
> > - un css globale che tiene lo stile comune a tutte le pagine (es: i bordi della pagina, lo sfondo, lo stiling dell'header, ecc)
> > - un css specifico per ogni pagina
> > - un css a parte per ogni "componente ajax", ovvero quelle parti di gui che compaiono in più pagine richiamate da ajax o comunque condivise
> >
> > Tutte le pagine includono il CSS globale, il loro CSS specifico e il CSS di tutti i componenti condivisi attinenti a quella pagina.
> > Ovviamente cerco sempre di usare le classi per essere sicuro che le varie stilate non vadano in conflitto fra loro.
> > Per esempio...
> > se ho un componente condiviso, diciamo "maschera messaggio", allora tutti gli stili che riguardano quella maschera incominceranno con qualcosa tipo:
> >
> > div.mascheraMessaggio div.msg {
> > }
> >
> > div.mascheraMessaggio #sendBtn {
> > }
> >
> > div.mascheraMessaggio div.msg textarea {
> > }
> >
> > Così se ci sono altri div.msg e altri textarea in giro per la pagina che include questo componente questi non vengono toccati.
> >
> > Ovviamente gli stili invece usati globalmente ha senso metterli nel CSS globale, soprattutto cose tipo i "temi", ovvero quelle combinazioni di colori e look&feel che se cambiano devono cambiare ovunque nel sito per avere una GUI coerente.
> >
> > In questo modo non solo eviti i problemi di cui parli, ovvero namespace intasato, ecc... ma ottieni gratis un altro vantaggio... ovvero quello di avere file CSS piccolini e molto veloci a caricarsi.
> >
> > La stessa cosa identica precisa sputata vale per i file javascript: uno globale per le funzioni condivise fra più pagine, e uno specifico per ogni pagina.
> > Tutte le pagine includono il js globale, il loro js specifico e il js di tutti i componenti condivisi caricati con ajax o meno.
> >
> > Purtroppo sta cosa l'ho capita "tardi", e ora mi trovo con progetti con CSS da 160k...
> >
> >
> > **Modificato dall'autore il 13.04.2012 12:48**
>
> in questo modo però per avere la pagina finale devi caricare 200 file
No invece. I file alla fine saranno 3 o 4 per pagina.
Un file CSS globale
Un file specifico per la pagina
Un file per ogni componente condiviso.
Quanti sono i componenti comuni a più pagine? Saranno due o tre in tutto il sito e difficilmente una pagina ne usa più di due contemporaneamente.
-
-
-
-
-
-