☺
Proc di Catania
Scritto da:
> > Un gatto maschio in genere non si ingroppa una cucciola.
>
> C'è un video su YouTube che smentisce questa affermazione.
E io che pensavo che Gatto fosse etero...
> > Un gatto maschio in genere non si ingroppa una cucciola.
>
> C'è un video su YouTube che smentisce questa affermazione.
E io che pensavo che Gatto fosse etero...
Immacolata concezione
Ad
http://archive.vn/qN1x1
Meglio della Madonna! Se vuoi scoprire come ha fatto clicca qui!!
☺
Scritto da: Giambo
> Scritto da: Daisuke Niwa
>
> > > Cosa devo fare per convincerti a mettere in sesto il CSS di questo sito
?
> >
> > Ok...
>
> ... fatto ?
>
> Stavo pensando: Se si chiude la barra a sinistra, c'e' molto spazio non usato a destra.
Non chiuderla.
Mi piacciono i problemi di facile soluzione.
> Se mettessimo div.msgInfo fuori da div.messageBox, alla sua destra ? Verrebbe una porcheria o sarebbe di una bellezza sconvolgente
?
Credo verrebbe una porcheria, inoltre poi forse ci sarebbero problemi quando vai a ridimensionare la finestra, dovresti trovare un modo per hakkare dentro il componente jquery e fargli chiamare una funzione ogni volta che c'è un resize... a meno che il resize non sposti anche tutto quello che sta a destra, ma ne dubito.
> Scritto da: Daisuke Niwa
>
> > > Cosa devo fare per convincerti a mettere in sesto il CSS di questo sito
?> >
> > Ok...
>
> ... fatto
?>
> Stavo pensando: Se si chiude la barra a sinistra, c'e' molto spazio non usato a destra.
Non chiuderla.
Mi piacciono i problemi di facile soluzione.
> Se mettessimo div.msgInfo fuori da div.messageBox, alla sua destra ? Verrebbe una porcheria o sarebbe di una bellezza sconvolgente
?Credo verrebbe una porcheria, inoltre poi forse ci sarebbero problemi quando vai a ridimensionare la finestra, dovresti trovare un modo per hakkare dentro il componente jquery e fargli chiamare una funzione ogni volta che c'è un resize... a meno che il resize non sposti anche tutto quello che sta a destra, ma ne dubito.
☺
Scritto da: Giambo
> Scritto da: Daisuke Niwa
>
> > Non vi conviene comportarvi male con me. Avete presente Jurassic Park? Eh?
>
> Cosa devo fare per convincerti a mettere in sesto il CSS di questo sito ?
Ok...
> Scritto da: Daisuke Niwa
>
> > Non vi conviene comportarvi male con me. Avete presente Jurassic Park? Eh?
>
> Cosa devo fare per convincerti a mettere in sesto il CSS di questo sito
?Ok...
☺
Scritto da: avvelentani
> Scritto da: Giambo
> > Scritto da: avvelentani
> >
> > > > Abbiamo inquinato fiumi, laghi, mari, oceani, terre aria e spazio. Gli aborigeni australiani sono la da 60'000 anni e non hanno rovinato nulla. Siamo veramente sicuri di essere noi i più evoluti?
> > >
> > > Noi almeno non ci inventiamo storie di legnetti magici che tornano indietro quando li tiri.
> >
> > Noi abbiamo l'E-Cat !
>
> A quello ci crede solo wakkaboia.
Sempre meglio che credere a pezzi di legno che creano distorsioni gravitazionali tali da farli precipitare verso chi li ha lanciati!
> Scritto da: Giambo
> > Scritto da: avvelentani
> >
> > > > Abbiamo inquinato fiumi, laghi, mari, oceani, terre aria e spazio. Gli aborigeni australiani sono la da 60'000 anni e non hanno rovinato nulla. Siamo veramente sicuri di essere noi i più evoluti?
> > >
> > > Noi almeno non ci inventiamo storie di legnetti magici che tornano indietro quando li tiri.
> >
> > Noi abbiamo l'E-Cat
!>
> A quello ci crede solo wakkaboia.
Sempre meglio che credere a pezzi di legno che creano distorsioni gravitazionali tali da farli precipitare verso chi li ha lanciati!
Il coraggio degli asiatici
Ad
https://imgur.com/iYd5ZkJ
Cinesi salvano Gatto Selvaggio da sicuro annegamento, altro che musulmani!
☺
capo: chissà che succederà ora che $bigboss se ne è andato in pensione
io: perché?
capo: qui sono tutti preoccupati, non si sa ancora chi lo sostituirà
io: ah... bé... chiunque sia non gli conviene fare il furbo con il programmatore
capo: a no?
io: no... ricordi che fine ha fatto Jurassic Park quando non hanno dato al programmatore quello che voleva?
capo: hmmm... vero, però mi sembra che neanche il programmatore abbia fatto una bella fine
io:
in effetti...
Se uno di questi giorni smetto di postare probabilmente mi ha mangiato un dilofosauro!
io: perché?
capo: qui sono tutti preoccupati, non si sa ancora chi lo sostituirà
io: ah... bé... chiunque sia non gli conviene fare il furbo con il programmatore
capo: a no?
io: no... ricordi che fine ha fatto Jurassic Park quando non hanno dato al programmatore quello che voleva?
capo: hmmm... vero, però mi sembra che neanche il programmatore abbia fatto una bella fine
io:
in effetti...Se uno di questi giorni smetto di postare probabilmente mi ha mangiato un dilofosauro!
☺
Richieste Forum
Scritto 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.
> 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.
☺
Richieste Forum
Scritto 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.
> 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.
☺
Richieste Forum
Scritto 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.
> 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.
Vieni anche tu a fare autostop in merio oriente!!!
Ad
https://imgoat.com/uploads/cdd60ea004/183004.png
Non lasciarti scappare questa occasione più unica che rara di conoscere nuove culture e la gentilezza dei taxisti che provano a stuprarti ma a metà opera se ne pentono e ti lasciano in mezzo ad un bosco!
☺
A quando questi geni penseranno ad una tassa sulle email o sul numero di volte che premi INVIO?
☺
Scritto da: Ceiling dog
>
http://www.agi.it/in-primo-piano/notizie/201204130...
>
>
IMO con il tradimento del trota e del "gran capo" ora anche il più tardone dei leghisti dovrebbe aver capito che i ladroni non stavano tutti a Roma.
>
>
>
IMO con il tradimento del trota e del "gran capo" ora anche il più tardone dei leghisti dovrebbe aver capito che i ladroni non stavano tutti a Roma.
☺
Richieste Forum
Scritto 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?
> 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?
☺
Richieste Forum
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
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.
> 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.
AH SI ma NO Non lo so
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Richieste Forum
Scritto 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.
> 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.
☺
Richieste Forum
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**
> > 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**
☺
Richieste Forum
Scritto 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?
>
>
>
> 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?
☺
Scritto da: altg
> I frammenti di codice non venivano bene con una ordered list numerica?
> Cioe`, le table non erano esecrabili?
Code è renderizzato attraverso un tag <pre>
http://www.w3.org/TR/html5/the-pre-element.html#th...
Poi, via un componente esterno javascript, questo tag viene convertito in un <div> che a sua volta contiene tutti i suoi cazzi&mazzi per allineare le righe ai numeri di linea (ma permettendo di selezionare solo il codice e non i numeri di linea nel caso tu voglia copiarlo), ecc.
Le tabelle sono esecrabili perché creano problemi di accessibilità, lo screen-reader (quello dei ciechi per esempio) non sa in che ordine leggere le celle della tabella, perciò rende estremamente difficoltosa la lettura della pagina qualora usi tabelle per formattare il layout. Tuttavia in questo caso non sono un grosso problema, visto che basta spegnere javascript per avere un tag <pre> semplice semplice e di facile lettura.
D'altro canto si poteva anche usare una lista numerata, ma in quel caso selezionando il testo si sarebbero selezionati anche i numeri di linea, inoltre sarebbe stato IMO un uso sbagliato delle liste (non stai facendo un elenco, stai solo usando le liste per numerarti le righe di un testo che NON è un elenco quindi stai usando le liste per motivi "estetici" e non in accordo con il loro significato)... comunque, visti i problemi che le liste presentavano, e visto che esisteva già questo componente che ha pure il syntax highlight per svariati linguaggi aggratis oltre che la numerazione delle linee indipendente dal testo (e che quindi permette di copiaincollare il testo altrove senza copiare anche i numeri di linea), visti i pro e i contro, ho preferito usare questo metodo anziché reinventare l'acqua calda e perderci su tempo inutilmente.
> I frammenti di codice non venivano bene con una ordered list numerica?
> Cioe`, le table non erano esecrabili?
Code è renderizzato attraverso un tag <pre>
Poi, via un componente esterno javascript, questo tag viene convertito in un <div> che a sua volta contiene tutti i suoi cazzi&mazzi per allineare le righe ai numeri di linea (ma permettendo di selezionare solo il codice e non i numeri di linea nel caso tu voglia copiarlo), ecc.
Le tabelle sono esecrabili perché creano problemi di accessibilità, lo screen-reader (quello dei ciechi per esempio) non sa in che ordine leggere le celle della tabella, perciò rende estremamente difficoltosa la lettura della pagina qualora usi tabelle per formattare il layout. Tuttavia in questo caso non sono un grosso problema, visto che basta spegnere javascript per avere un tag <pre> semplice semplice e di facile lettura.
D'altro canto si poteva anche usare una lista numerata, ma in quel caso selezionando il testo si sarebbero selezionati anche i numeri di linea, inoltre sarebbe stato IMO un uso sbagliato delle liste (non stai facendo un elenco, stai solo usando le liste per numerarti le righe di un testo che NON è un elenco quindi stai usando le liste per motivi "estetici" e non in accordo con il loro significato)... comunque, visti i problemi che le liste presentavano, e visto che esisteva già questo componente che ha pure il syntax highlight per svariati linguaggi aggratis oltre che la numerazione delle linee indipendente dal testo (e che quindi permette di copiaincollare il testo altrove senza copiare anche i numeri di linea), visti i pro e i contro, ho preferito usare questo metodo anziché reinventare l'acqua calda e perderci su tempo inutilmente.
E TU Lo Sai o no?
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Scritto da:
> Salve a tutti, ho 33 anni, sono sposata da 5 anni senza figli, da un anno ho scoperto che mio marito frequenta siti porno.. prima non me ne ero mai accorta di questa sua passione se così si può chiamare.. sapevo che ai tempi della scuola con gli amici si scambiavano film porno ma credevo fosse una cosa legata a quell’età. Io sono stata la sua prima ragazza e lui il primo x me, non c’è una grande passione tra noi, ci limitiamo ad avere rapporti coniugali e niente di extra… mi imbarazzano quelle cose anche se lui me le ha proposte spesso… io glie l’ho rinfacciato quando l’ho scoperto e lui si è dimostrato dispiaciuto di ciò…
> Ora vorrei sapere.. è normale x voi uomini vedere questi siti? Vi prego non so cosa fare… ora mio marito cerca di cancellare le tracce dal pc ma io so usarlo bene e ogni qualvolta vado a controllare trovo tracce di questi siti schifosi… una curiosità ma perché guarda anche siti dove ci sono donne e donne insieme… avete capito no? O un altro sito di donne mature… vorrei capire se devo preoccuparmi… se è una cosa seria…. grazie x favore rispondete sinceramente
Il fatto che tuo marito preferisca il porno a te è un evidente segnale del tuo fallimento come moglie, come femmina e come essere umano.
Mi spiace.
> Salve a tutti, ho 33 anni, sono sposata da 5 anni senza figli, da un anno ho scoperto che mio marito frequenta siti porno.. prima non me ne ero mai accorta di questa sua passione se così si può chiamare.. sapevo che ai tempi della scuola con gli amici si scambiavano film porno ma credevo fosse una cosa legata a quell’età. Io sono stata la sua prima ragazza e lui il primo x me, non c’è una grande passione tra noi, ci limitiamo ad avere rapporti coniugali e niente di extra… mi imbarazzano quelle cose anche se lui me le ha proposte spesso… io glie l’ho rinfacciato quando l’ho scoperto e lui si è dimostrato dispiaciuto di ciò…
> Ora vorrei sapere.. è normale x voi uomini vedere questi siti? Vi prego non so cosa fare… ora mio marito cerca di cancellare le tracce dal pc ma io so usarlo bene e ogni qualvolta vado a controllare trovo tracce di questi siti schifosi… una curiosità ma perché guarda anche siti dove ci sono donne e donne insieme… avete capito no? O un altro sito di donne mature… vorrei capire se devo preoccuparmi… se è una cosa seria…. grazie x favore rispondete sinceramente
Il fatto che tuo marito preferisca il porno a te è un evidente segnale del tuo fallimento come moglie, come femmina e come essere umano.
Mi spiace.
☺
Scritto da: gengiva
> metti la punta della lingua tra gli incisivi inferiori e le labbra e mentre apri e chiudi la bocca come un pesce fai un verso tipo... ble ble ble
Chamate un ambulansa plesto!
> metti la punta della lingua tra gli incisivi inferiori e le labbra e mentre apri e chiudi la bocca come un pesce fai un verso tipo... ble ble ble
Chamate un ambulansa plesto!
☺
Scritto da:
> > > > >
http://bologna.repubblica.it/cronaca/2012/04/11/ne...
> > > > >
> > > > > Quoto. E per la stessa ragione non dovrebbe essere battezzato.
> > > >
> > > > Quoto.
> > > > Ma quoto anche un'altra cosa sottointesa... se gli altri bambini, in quarta elementare, sono invece "capaci di intendere e di volere", allora lo sono anche per quanto riguarda altre questioni. Non è che uno è in grado di intendere e di volere solo quando fa comodo alla società.
> > > >
> > > >
> > >
> > > Ecchediamine se uno è in grado di voler ricevere il corpo di Cristo sotto forma di ostia potrebbe anche voler ricevere qualcos'altro...
> >
> > Non fare il furmiga.
>
> Quarta elementare? Ai miei tempi la comunione si faceva a sei anni.
Secondo me si dovrebbe fare a 56.
> > > > >
> > > > >
> > > > > Quoto. E per la stessa ragione non dovrebbe essere battezzato.
> > > >
> > > > Quoto.
> > > > Ma quoto anche un'altra cosa sottointesa... se gli altri bambini, in quarta elementare, sono invece "capaci di intendere e di volere", allora lo sono anche per quanto riguarda altre questioni. Non è che uno è in grado di intendere e di volere solo quando fa comodo alla società.
> > > >
> > > >
> > >
> > > Ecchediamine se uno è in grado di voler ricevere il corpo di Cristo sotto forma di ostia potrebbe anche voler ricevere qualcos'altro...
> >
> > Non fare il furmiga.
>
> Quarta elementare? Ai miei tempi la comunione si faceva a sei anni.
Secondo me si dovrebbe fare a 56.