e se css potesse impostare più di un background?

[IroN@xiD]

Ciao a tutti!!

Sono circa due anni che realizzo siti con CSS e XHTML e mi sono imbattuto più volte in situazioni di difficile soluzione per quanto riguarda la resa grafica.

Per esempio posto la più classica delle situazioni.

Volendo creare un particolare contorno ad un div come si può procedere?

Beh ci sono diverse soluzioni ma (a meno che qualcuno non abbia soluzioni differenti valide) solo una può funzionare a dovere, soprattutto quando il layout è fluido o le dimensioni del div devono necessariamente variare.

<div style="background:transparent url('angolotopsx.jpg') top left no-repeat;">
 <div style="background:transparent url('angolotopdx.jpg') top right no-repeat;">
  <div style="background:transparent url('angolobottomsx.jpg'); bottom left no-repeat;">
   <div style="background:transparent url('angolobottomdx.jpg'); bottom right no-repeat;">
    

Contenuto</p>
   </div>
  </div>
 </div>
</div>

N.B. La soluzione non è del tutto completa.. potrebbero servire in certe situazioni altri 4 box per i 4 lati.

E che diamine... questo è tuttaltro che accessibilità e diminuzione del markup.. quasi quasi si risolveva meglio con le tabelle!!! Con 9 celle si arrivava allo stesso risultato..

Allora io mi chiedo.. perchè CSS non potrebbe supportare
più di un singolo background per box? Voi cosa ne pensate?

Per farvi un esempio.. risolvendo la situazione di prima con background multipli uscirebbe:

<style>
#mybox {
background-color:transparent;
background-1:url(lefttop.jpg) top left no-repeat 1;
....
background-4:url(leftbottom.jpg) bottom left no-repeat 1;
}
</style>

<div id="mybox">

Contenuto</p></div>

In questo esempio ho usato la sintassi background-x che si dovebbe riferire al background n°x e definirne le caratteristiche così come si fa con background adesso. L'unica differenza è il valore numerico finale che indica il livello del background (una sorta di z-index dedicato al background).

Cmq era solo un esempio.. ci sarebbero una marea di situazioni in cui il background multiplo sarebbe utile.

Grazie per la vostra opinione!!!

[Mich_]

Quella proposta in alto non mi sembra la soluzione migliore.
Mi pare di aver visto nel forum soluzioni piu` razionali per gli angoli, e che risolvono anche i bordi.

Comunque dovresti dare un'occhiata alla bozza dei CSS3 (che sono in elaborazione): dovrebbe esserci una soluzione corretta anche per gli angoli.

[IroN@xiD]

Ho cercato nel forum ma non ho trovato soluzioni che riescano a produrre lo stesso risultato dell'esempio che ho postato. Per capirci con l'esempio che ho fatto si possono personalizzare completamente sia gli arrotondamenti che i bordi. Nel forum ho trovato esempi per angoli arrotondati ed altro ma non sono riuscito a trovare niente che possa darmi bordi ed angoli personalizzati adattabili ad un design fluido..

Cmq il box grafico era un esempio. Ci sono molte altre situazioni in cui i background multipli si renderebbero utili.

Cmq ho dato un occhiata a CSS3 come mi hai consigliato e a quanto pare ci avevano già pensato eheh

http://www.w3.org/TR/2005/WD-css3-ba...0216/#layering

Speriamo che i browser si adeguino presto al supporto CSS3 allora...

5 o 6 anni potrebbero bastare?!?

[andrea.paiola]

i Nifty Corners ?

[IroN@xiD]

Questi Nifty non li avevo mai visti ma cmq mi sembrano un semplice ripiego.. d'accordo, apparentemente c'è meno markup dell'esempio che ho postato io ma:

1- non sono completamente personalizzabili (con immagini per es).
2- richiedono il linkaggio a 2 css (mettiamo 1 se si accorpano) ed 1 javascript di 174 righe.....
3- il javascript non fa altro che aggiungere markup alla pagina originale.. il risultato? alla fine arriverà pure a superare il markup in eccesso dell'esempio che ho fatto (e di molto se consideriamo quello che è servito per produrlo)

Insomma. Tutto il contrario di ciò che css dovrebbe rappresentare.

Mi sembra uno scriptino simpatico.. per il resto non userei mai una cosa simile..

E' l'esempio di ciò che si dovrebbe evitare.



modifica: non ho capito la tua firma.. sembra la filosofia della microsoft... oppure ho capito male il senso?

[andrea.paiola]

Originariamente inviato da IroN@xiD
Questi Nifty non li avevo mai visti ma cmq mi sembrano un semplice ripiego.. d'accordo, apparentemente c'è meno markup dell'esempio che ho postato io ma:

1- non sono completamente personalizzabili (con immagini per es).
2- richiedono il linkaggio a 2 css (mettiamo 1 se si accorpano) ed 1 javascript di 174 righe.....
3- il javascript non fa altro che aggiungere markup alla pagina originale.. il risultato? alla fine arriverà pure a superare il markup in eccesso dell'esempio che ho fatto (e di molto se consideriamo quello che è servito per produrlo)

Insomma. Tutto il contrario di ciò che css dovrebbe rappresentare.

Mi sembra uno scriptino simpatico.. per il resto non userei mai una cosa simile..

E' l'esempio di ciò che si dovrebbe evitare.



modifica: non ho capito la tua firma.. sembra la filosofia della microsoft... oppure ho capito male il senso?

I nifty corners sono nati per evitare che si usasse il markup per la presentazione nei casi di bordi arrotondati...
il fatto positivo è che degradano bene percui chi ha javascript disabilitato (o non ce l'ha proprio) vedrà dei bordi non arrotondati e pazienza...
1) non si dovrebbero usare immagini quando è possibile evitare risparmi così sul peso
2) anche se fosse vero non vedo il problema
3) dici che modifica il DOM della pagina? bò non ne ho idea

il CSS non centra niente... qui si tratta di javascript (anche se usato impropriamente per la presentazione)

purtroppo attualmente è l'uica alternativa che abbiamo ad usare impropriamente un sacco di div annidati

cosa non hai capito della mia firma?
1) scrivi codice standard e semanticamente corretto

mi sembra chiaro: il codice sul web dovrebbe tendere agli standard W3C e quindi scriverlo tenendo conto della semantica quando si tratta di markup

2) separa il contenuto dalla presentazione

anche questo è chiaro: è una buona regola di progettazione e migliora l'accessibilità dell'informazione

3) perchè sprecare tempo per qualcosa che poi l'utente non vede?

qui mi riferisco soprattutto a flash o altri oggetti/applet/linguaggi proprietari che se l'utente non ha l'apposito player semplicemente non vede (e quindi fanno perdere solo tempo allo sviluppatore)

ps: la M$ mi sta sul

[IroN@xiD]

Originariamente inviato da andrea.paiola
I nifty corners sono nati per evitare che si usasse il markup per la presentazione nei casi di bordi arrotondati...

Ma lo usano cmq anche se lo fanno creare da javascript però.. quindi non si vede ma c'è!

1) non si dovrebbero usare immagini quando è possibile evitare risparmi così sul peso

si ma non sempre mi possono bastare i classici bordi ed angoli stondati. Se si vuole qualcosa di particolare bisogna fare qualcosa di diverso e quindi usare le immagini. Per angoli ed altro non ci sono grossi problemi con pochissimi byte se si ottimizza a dovere si ottengono risultati eccellenti. La noia è la richiesta http multipla ma questo non si può sempre evitare.

2) anche se fosse vero non vedo il problema

Come non vedi il problema? Se uno vuole con js e position:absolute a questo punto può fare qualsiasi cosa ma non era questo lo spirito del post. Mi da farstidio il markup in eccesso dell'esempio che ho fatto.. figurati due o tre richieste http in più con centinaia di righe da scaricare..

3) dici che modifica il DOM della pagina? bò non ne ho idea

modifica il codice. Non vedi perchè le modifiche sono apportate con javascript ma se potessi vederlo troveresti molte righe in +.

il CSS non centra niente... qui si tratta di javascript (anche se usato impropriamente per la presentazione)
purtroppo attualmente è l'uica alternativa che abbiamo ad usare impropriamente un sacco di div annidati

Parlo della filosofia css w3c. Usare quel sistema non è certo una bella soluzione. Come dici anche tu è solo un ripiego, piuttosto incasinato anche.

cosa non hai capito della mia firma?

I primi due punti li ho capiti benissimo ma con il terzo sembra che tu sia sarcastico.

Del tipo "che mi frega di essere corretto nella sintassi, rispettare l'accessibilita e separare presentazione da contenuto quando poi l'utente non vede?".

[andrea.paiola]

Originariamente inviato da IroN@xiD
Ma lo usano cmq anche se lo fanno creare da javascript però.. quindi non si vede ma c'è!



si ma non sempre mi possono bastare i classici bordi ed angoli stondati. Se si vuole qualcosa di particolare bisogna fare qualcosa di diverso e quindi usare le immagini. Per angoli ed altro non ci sono grossi problemi con pochissimi byte se si ottimizza a dovere si ottengono risultati eccellenti. La noia è la richiesta http multipla ma questo non si può sempre evitare.



Come non vedi il problema? Se uno vuole con js e position:absolute a questo punto può fare qualsiasi cosa ma non era questo lo spirito del post. Mi da farstidio il markup in eccesso dell'esempio che ho fatto.. figurati due o tre richieste http in più con centinaia di righe da scaricare..



modifica il codice. Non vedi perchè le modifiche sono apportate con javascript ma se potessi vederlo troveresti molte righe in +.



Parlo della filosofia css w3c. Usare quel sistema non è certo una bella soluzione. Come dici anche tu è solo un ripiego, piuttosto incasinato anche.

è ovvio che è un ripiego... la situazione attuale è quella che è... aspettiamo 5-6 anni (se bastano) e il problema sarà risolto (insieme a molti altri) dai CSS3...
non vedo comunque tutto questo dramma nel non usare bordi arrotondati... se proprio li si vuole usare per me il metodo migliore rimangono i Nifty Corners...

per la questione "markup addizionale" in realtà Nifty Corners lo aggiunge solo nel DOM (penso) e quindi all'atto del parsing della pagina penso... non esiste in realtà quel codice... e questo è confermato dal fatto che basta avere js disabilitato...

I primi due punti li ho capiti benissimo ma con il terzo sembra che tu sia sarcastico.

Del tipo "che mi frega di essere corretto nella sintassi, rispettare l'accessibilita e separare presentazione da contenuto quando poi l'utente non vede?".

è esattamente il contrario
l'estrema sintesi porta a questi qui pro quo...
ti assicuro che l'utente si accorge sia dei problemi del codice (che si trasmettono come errori in quello che poi vede l'utente) che in fatto di accessibilità.
L'usabilità poi (di cui l'utente si accorge ancora di più) è una questione più che altro progettuale e che col codice non centra niente, ma è IMPORTANTISSIMA.

[IroN@xiD]

Va beh, avevo frainteso io.
Cmq non è detto che se ne accorge. Perchè c'è un layout a tabelle per esempio non è detto che il sito funzioni male e un utente per accorgersene dovrebbe usare uno browser testuale..

Non è una questione di angoli arrotondati... è una questione di design. Se voglio una grafica particolare DEVO usare le immagini.