|
| Precedente :: Successivo |
| Autore |
Messaggio |
dAb
Dio minore
Registrato: 22/06/05 00:15
Messaggi: 858
Residenza: montana e piovosa
|
 Inviato: 19 Ott 2005 15:44 Oggetto: |
 |
|
Scalabile: detto di un programma, servizio o componente hardware che permette l'espansione delle proprie funzionalita` in due direzioni. Verso il basso per permetterne l'uso su sistemi a prestazioni inferiori a quelle dove originariamente e` stato sviluppato il servizio, verso l'alto per soddisfare le richieste di maggiori prestazioni.
Ad essere pignoli, il layout scalabile non esiste. La definizione corretta e` layout adattabile. Esiste il layout a codice scalabile, forse Nicola si riferiva a quello? |
|
| Top |
|
 |
{marcello}
Ospite
|
| Inviato: 19 Ott 2005 19:47 Oggetto: discreto ma... |
|
|
| discreto articolo.... per un prncipiante va bene ma andrebbe completato così come è è dispersivo...e guardate che ha ragione dab...layout scalabile è un concetto inesistente... |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 20 Ott 2005 02:09 Oggetto: Re: quante sciocchezze |
|
|
salve nicola, eccomi a risponderti 
| {Nicola - web designer} ha scritto: | | nn ho mai letto un rticolo più semplicistico e banalmente impreciso come questo... |
beh, in un certo senso e' vero che e' semplicistico, ma l'idea era proprio quella di chiarire un'affermazione che ho sentito tante volte da chi si avvicina ai linguaggi di marcatura, non era rivolto agli specialisti che quei linguaggi gia' li conoscono a dovere; per quanto riguarda la banalita', il fatto stesso che qualcuno ancora faccia certe affermazioni dimostra come evidentemente le idee non siano chiarissime al riguardo
| Citazione: |
ma veniamo con ordine: non è sufficiente leggersi il libro di zeldman per dire cose scontate. Il libro merita una riflessione (anticipi il concetto del libro perchè si evince che l'autrice lo abbia letto [male]) |
pecca mia, ma il libro che citi non l'ho letto, almeno non ancora; le mie affermazioni sono semplicemente il frutto della mia esperienza
| Citazione: |
la prima frase "ma tabelle e CSS non lo sono affatto e possono anzi convivere tranquillamente in un layout, perché si occupano di parti differenti di una pagina: le prime della struttura, i secondi della formattazione."
è una cosa ssolutamente falsa. I CSS si occupano di tutti gli aspetti relativi all'impaginazione dei contenuti, ed è per questo che nelle nuove specifiche troviamo maggiori controlli per il layout. Oltretutto le pagine basate su tabelle non hanno layout scalabili. |
"i secondi della formattazione"= i css (secondi citati nella frase) si occupano di formattazione, che e' quel che ribadisci tu piu' sotto, usando pero' il termine impaginazione (formattazione=impaginazione=presentazione: sinonimi)
come qualsiasi altro elemento, le tabelle hanno delle misure che possono essere espresse sia in valori relativi (75%) che in valori assoluti (600px): nel primo caso abbiamo un layout fluido (sempre il 75% della larghezza della finestra del browser, qualunque sia la risoluzione), nel secondo caso abbiamo un layout fisso (sempre 600px, qualunque sia la risoluzione); tale valore puo' essere dato direttamente nel tag (<table width="600px">) oppure via css (table {width: 600px;} ) il che significa che la formattazione (=dato relativo alla larghezza) lo gestisco con i css e che anche con le tabelle si possono creare indifferentemente layout fluidi o fissi
| Citazione: |
"le tabelle hanno indubbiamente dei vantaggi, non ultimo la robustezza."
Intanto i web-designer hanno usato le tabelle ssempre e solo per impaginare i dati. quindi ieri come oggi. I dati cosa sono? immagini, testi etc... è solo diventato più complesso il modo di annidare le tabelle (merito anche degli editor visuali...). |
le tabelle sono nate per esporre dati tabellari (i risultati delle partite di calcio della stagione piuttosto che i prezzi di un elenco di oggetti di un negozio o le caratteristiche di determinati minerali o qualsiasi altro tipo di esposizione di dati di questo tipo ti venga in mente), ma ad un certo punto sono state usate dai webdesigner per creare dei layout e - anziche' dei valori - nelle varie celle hanno iniziato ad inserire dei pezzetti di immagine che come un puzzle creavano il layout desiderato: siamo passati da tabelle per esposizione di dati a tabelle per la creazione di layout
niente vieta di usare tabelle per la creazione di layout, solo si raccomanda di impostarle diversamente e di non usare - ad esempio, ma non solo - i tag thead e tbody, specifici delle tabelle per esposizione di dati
| Citazione: |
Dire che le tabelle sono più solide dei css è una scemenza. |
le tabelle sono un elemento del linguaggio html, i css sono un linguaggio a se; le prime sono rese allo stesso modo nei principali browsers, i secondi sono interpretati in modo diverso dagli stessi (essendo del mestiere, credo avrai sicuramente sentito parlare piu' volte della diversa gestione del box model da internet explorer piuttosto che da mozilla, firefox ed opera, tanto per citare i piu' noti)
essendo webdesigner, credo avrai avuto modo di verificare tu stesso come un layout creato con l'uso di tabelle sia visualizzato nello stesso identico modo nei principali browsers, siano essi microsoft o non microsoft; allo stesso modo e per il problema di cui parlavo sopra, avrai avuto modo di verificare come un layout creato usando div al posto di tabelle non abbia la stessa stabilita', se non c'e' un uso ben calibrato dei css che gestiscono tale layout
| Citazione: |
Le tabelle sono in realtà tag che attivano la funzionalità del browser di generare un campo delimitato in una pagina. |
i tag table - tr - td ed i relativi specifici tbody - tfoot - th - thead servono per marcare ed esporre correttamente dati di tipo tabellare
| Citazione: | | I css sono altri tag che attivano altre funzioni e quiparabili a quelle delle tabelle. |
i css NON sono dei tag, ma sono un linguaggio: esiste un tag style che serve pero' per introdurre il linguaggio css all'interno del codice nel caso si decida di optare per i css interni alla pagina esattamente come esiste un tag script se si inserisce del codice ja*ascript all'interno della pagina, ma ne' css ne' ja*ascript sono tag, bensi' dei linguaggi (rispettivamente di formattazione e di scripting che si usano per interagire e manipolare i tag del linguaggio di marcatura html di cui fa parte anche table ed i suoi derivati)
| Citazione: |
Non si può far credere che la tabella viene "inserita" nella pagina mentre il CSS è un "codice" (come uno script). Sono esattamente la stessa cosa a livello di DOM, |
ehm... credo tu stia facendo confusione tra css e div: i primi sono un linguaggio DIVERSO da html, i secondi (i div) sono un elemento di marcatura e per l'esattezza un contenitore di tipo blocco usati per contenere parti di layout
| Citazione: | | solo che attivano cose diverse e siono scritti con TECNICHE diverse. |
SERVONO per scopi diversi: i tag html e quindi anche le tabelle per DETERMINARE di che tipo di elemento si tratti - un titolo, un paragrafo, un'immagine, una tabella per esporre dati... mentre i css servono per PRESENTARE gli elementi che i tag contengono e definiscono
| Citazione: | | Per assurdo si potrebbe inserire una specifica in un CSS che crei una tabella (ma il browser non ha questa funzionalità attivabile dal CSS... quindi non funzionerebbe) |
i css non sono in grado di modificare alcunche', ne' di inserire dinamicamente alcun tag come invece fanno i linguaggi di programmazione (asp, php, ja*ascript... ); sono semplicemente in grado di determinarne l'aspetto ed eventualmente la visibilita' e mi sto riferendo ad esempio a display: none per non rendere visibile un elemento che potrei poi rendere visibile con display: inline o display: block attraverso l'uso del gia' citato ja*ascript e dei suoi gestori d'eventi: tre linguaggi che interagiscono fra loro, ma che rimangono comunque ben distinti nelle loro funzioni:
- html per determinare di che elemento stiamo parlando
- css per determinare come quell'elemento dev'essere reso a video o su carta
- ja*ascript per modificare in base a taluni eventi l'aspetto di tale elemento
| Citazione: | | "per molto tempo non furono adeguatamente considerati dai webdesigner". Non è che i web-design (quelli veri) non hanno ADEGUATAMENTE considerato i css. |
io sono del parere che se i professionisti del web avessero iniziato gia' agli esordi ad usare correttamente i css (pur con tutte le limitazioni che avevano sicuramente nei primi anni), i produttori di browsers e di editor visuali avrebbero spinto per una miglior resa delle pagine e cioe' per una piu' corretta interpretazione delle specifiche del w3c
cosi' non e' stato e tutt'ora i browsers si sforzano di rendere leggibile anche le pagine web scritte male (tag non annidati correttamente o non chiusi ad esempio), sprecando un sacco delle loro energie in questo compito
sto comunque esprimendo un'opinione personale e percio' opinabile (nella prima frase intendo: la seconda e' un dato di fatto)
| Citazione: | | Il fatto è che i CSS devono avere delle proprietà minime per essere usati, proprietà che all'epoca non esistevano. |
errato: il fatto e' che il linguaggio dei css dev'essere correttamente interpretato dai browsers, cosa che finora non e' stata fatta per molti dei browsers a piu' larga diffusione e questo ha fatto si che i webdesigner non li usassero, ma che ricorressero alle gia' collaudate tabelle e all'appesantente formattazione nei tag
| Citazione: | | Ora con le nuove specifiche i CSS possono fare molte più cose |
ora i webdesigner devono comunque tener presente di quale versione dei css e' supportata dai piu' diffusi browsers, il che vuol dire che spesso devono prendere atto che le nuove specifiche non saranno rese come dovrebbero e optare eventualmente per l'utilizzo delle vecchie per evitare che molti utenti non possano visualizzare correttamente le pagine e per correttamente non intendo elementi di pochi pixel piu' in basso o piu' in alto, ma intere sezioni non fruibili (vedi menu a tendina non navigabili e di conseguenza intere sezioni non raggiungibili, tanto per fare un esempio classico)
| Citazione: | | e quindi i WEB-DESIGNER li preferiscono molto spesso alle tabelle. |
ancora una volta compari le tabelle ed i css, mentre quel che si deve comparare sono le tabelle (elemento di blocco) con i div (elemento di blocco alternativo) ed i css (linguaggio di presentazione) con la formattazione classica dei tag (sistema di formattazione in linea di tag per tag)
| Citazione: | | QUindi la scelta non è condizionata dal gusto del designer ma dalla tecnologia diponibile al momento di fare una scelta |
le tecnologie ci sono da tempo, basta solo usarle correttamente
| Citazione: | "Diverso il discorso dei div: perché scegliere di usare i div come contenitori anziché le tabelle? Semplice: perché i div sono molto più malleabili delle tabelle" questa frase si commenta da sola
"si adattano molto più facilmente ai supporti più diversi che continuamente sono proposti al pubblico, come ad esempio i palmari o i cellulari"
quale palmare non legge le tabelle? |
ok, diciamo che non ho scelto l'esempio piu' corretto per spiegarmi bene: i browser vocali usati dai non vedenti hanno grosse difficolta' a leggere contenuti web inseriti in tabelle annidate, mentre riescono agevolmente a leggere contenuti web inseriti in div
fai una prova: prendi una classica pagina web a tre colonne costruita con le tabelle e formattata con i css esterni, poi prendi la stessa pagina a tre colonne costruita con i div e formattata ugualmente con i css esterni
ora chiedi ad un utente che fa uso di browser vocali quale pagina riesce a leggere e quale gli crea parecchie difficolta': ti rispondera' che la pagina costruita usando div riesce ad usufruirla correttamente in toto, mentre non riesce a fare la stessa cosa con la pagina costruita con le tabelle annidate: spero di essermi spiegata meglio
| Citazione: | | il fatto di usare i css per i palmari non riguarda le tabelle. riguarda il fatto che con i div puoi creare versioni alternative (che potrebbe avere anche tabelle) per dimensioni dello schermo ridotte (come quelle di un palmare. |
certo che puoi creare versioni alternative con i div e molto piu' agevolmente che con le tabelle: se hai un layout a tre colonne su div, puoi trasformarlo in un layout a due colonne semplicemente modificando il css, mentre se hai un layout a tre colonne con le tabelle, puoi modificare il css fin che vuoi, ma sempre a tre colonne rimane!
i piccoli monitor ora in uso preferiscono un layout verticale per una maggiore usabilita': con i div e' possibile ottenerlo usando come giustamente dici un css dedicato, con le tabelle non e' possibile fare la stessa cosa
| Citazione: | | "Purtroppo c'è ancora qualche controindicazione all'uso dei div" ci sono migliaia di hack in giro... basta conoscerli |
gli hack sono fortemente sconsigliati dagli stessi stilatori delle specifiche del w3c, la settimana scorsa se ne e' parlato proprio ad un seminario al quale partecipava Charles McCathieNevile, membro attivo del w3c e sviluppatore di opera
sono sconsigliati, perche' basando la formattazione di un layout su un hack che fa riferimento ad un baco di un browser, si rischia che quando il browser sara' aggiornato ed il baco corretto, l'hack visualizzi male la pagina e ne renda magari inutilizzabile il contenuto, come si diceva sopra
invece con l'uso corretto dei linguaggi di marcatura e di formattazione, eventualmente rinunciando agli effetti speciali che richiedono hack, si ha la certezza che il sito rimarra' correttamente leggibile e fruibile anche in futuro: si e' passati insomma da una progettazione retrocompatibile ad una programmazione che guarda al futuro, senza dimenticare i vecchi browser rinunciando - ad esempio in caso di siti a larghissima diffusione - ad usare alcuni elementi dei css mal supportati, che potremo usare in lavori futuri, quando la quantita' di browsers che li supporta sara' piu' ampia
spero di essermi spiegata piu' chiaramente, evidentemente non ero riuscita nell'intento scrivendo l'articolo
@marcello: grazie
lo scopo dell'articolo era appunto di parlare ai principianti ed indurli a frequentare il forum, dove si trattano i vari argomenti in modo piu' specifico e dettagliato e si, concordo: ha ragione dab! il termine giusto infatti e' layout fluido (o adattabile), da contrapporre al layout fisso, come dicevo all'inizio della mia risposta
L'ultima modifica di rebelia il 20 Ott 2005 09:30, modificato 2 volte |
|
| Top |
|
|
Memole
Eroe
Registrato: 17/10/05 01:22
Messaggi: 65
|
| Inviato: 20 Ott 2005 08:47 Oggetto: |
|
|
| Citazione: | | io sono del parere che se i professionisti del web avessero iniziato gia' agli esordi ad usare correttamente i css (pur con tutte le limitazioni che avevano sicuramente nei primi anni), i produttori di browsers e di editor visuali avrebbero spinto per una miglior resa delle pagine e cioe' per una piu' corretta interpretazione delle specifiche del w3c |
Mi inserisco solo per dire la mia su questa frase.
Purtoppo, e lo dico a malincuore, non credo le cose vadano come dici tu, rebelia.
Un web designer deve pensare soprattutto alla visibilità del suo sito, non può, nel 99% dei casi, scegliere di utilizzare una tecnologia che è poco o nulla diffusa.
La vera differenza invece la fanno gli utenti. Se un browser che supporta gli standard si diffonde molto come sta succedendo per firefox allora questo porta anche i concorrenti (per riguadagnare fette di mercato) a implementare quello per cui lui stesso ha fatto successo.
I browser purtroppo non vengono sviluppati in base alle esigenze dei webdesigner ma rispetto a dove si sposta la grande massa.
Del resto se così non fosse sarebbero già pienamente supportati da anni formati com e il png (che può essere usato solo tramite escamotages su IE) o l'SVG di cui ho cominciato a sentire parlare seriamente circa 6 anni fa in un convegno adobe e a tutt'oggi non si sa ancora se e quando potrà davvero essere utilizzato...
E ti giuro, io come web designer non vedo l'ora di usarlo... ma se oggi faccio un sito avvalendomi dell'svg non lo vede nessuno e capisci bene che un sito che non vede nessuno non è un prodotto vendibile che mi piaccia o no.
Magari e ripeto MAGARI potessimo davvero fare il bello e il cattivo tempo.
Cosa invece molto vera è che ORA che la tecnologia CSS è bene o male quasi del tutto supportata VA UTILIZZATA ed è assurdo e inutile progettare siti ex-novo utilizzando metodologie ormai sorpassate. |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 20 Ott 2005 09:07 Oggetto: |
|
|
| Memole ha scritto: |
Purtoppo, e lo dico a malincuore, non credo le cose vadano come dici tu, rebelia. |
si, probabilmente hai ragione: era solo una mia supposizione il fatto che se i professionisti avessero richiesto a gran voce piu' supporto per gli strumenti *forse* i produttori di sw si sarebbero dati una mossa prima, tutto qua
| Citazione: |
Cosa invece molto vera è che ORA che la tecnologia CSS è bene o male quasi del tutto supportata VA UTILIZZATA ed è assurdo e inutile progettare siti ex-novo utilizzando metodologie ormai sorpassate. |
ed infatti! solo che mi e' capitato piu' volte di cogliere una certa ritrosia ad adottare il sistema div+css parlando con alcuni webdesigner nel campo da tempo e che continuano ad usare il "vecchio metodo"
te l'ho detto: sono considerazioni personali e percio' opinabilissime |
|
| Top |
|
|
Samaritan
Mortale devoto
Registrato: 21/10/05 09:11
Messaggi: 12
|
| Inviato: 21 Ott 2005 16:53 Oggetto: |
|
|
brrr....quasi un flame..eh eh eh
Se posso dire la mia certe parti del discorso tra div/CSS e tabelle mi sembrano simili alle guerre di religione tra Windows e Linux.
Se è vero che, con l'aumento della complessità dei layout si è arrivati a degli eccessivi livelli di nesting delle tabelle, è altrettanto vero che un layout tableless non è obbligatoriamente ben fatto.
Div e posizionamenti via CSS sono, a mio avviso, più soggetti a modifiche non volute di impaginazione se non preparati con accortezza.
Cose di questo genere vanno quindi valutate a tutto tondo:
- adattabilità a differenti riusoluzioni (se necessario)
- adattabilità a diversi visitatoti (accessibilità)
- produttività del team creativo e di sviluppo
- appeal del risultato finale
- manutenibilità / aggiornabilità
Sono d'accordo invece sul'utilizzare i frame sui siti con molta parsimonia per i problemi si SEO che comportano.
Vanno poi fatte le dovute distinzioni tra i siti/portali e le web application (intese come applicazioni web based)
Mi sembrano discorsi un pò campati per aria (non me ne abbia chi li ha espressi) quelli sull'utilizzo su più device.
Non di sola grafica vive un prodotto informativo o un servizio.
Al di là del layout un prodotto web realizzato per dare il massimo confort sul web mal si adattera al palmare.
Device/media con modalità di fruizione e catteristiche differenti non possono permetter fruire bene lo stesso prodotto (chi si ricorda la web tv??).
Una cosa è avere il minibrowser un altra e cercare di fare la spesa on line su un sito web......o no ?
Chiudo con una domanda: quanti di voi hanno provato ad usare gli script che aggiungono a IE i behavior per avere l'evento hover gestibile nei css su tutti i tag ? (FF l'ha di default)
Si possono aggiungere giochi interessanti "zero code" ;-P |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 21 Ott 2005 17:36 Oggetto: |
|
|
| Samaritan ha scritto: | | brrr....quasi un flame..eh eh eh |
hai detto bene: "quasi" 
| Citazione: |
Se posso dire la mia certe parti del discorso tra div/CSS e tabelle mi sembrano simili alle guerre di religione tra Windows e Linux. |
vero, ma se giri su altri forum ti accorgerai che qua e' praticamente inesistente: nell'articolo ho cercato di essere il piu' obiettiva possibile sui pro ed i contro dei vari sistemi
| Citazione: |
Se è vero che, con l'aumento della complessità dei layout si è arrivati a degli eccessivi livelli di nesting delle tabelle, è altrettanto vero che un layout tableless non è obbligatoriamente ben fatto. |
assolutamente d'accordo!
| Citazione: |
Div e posizionamenti via CSS sono, a mio avviso, più soggetti a modifiche non volute di impaginazione se non preparati con accortezza. |
sono d'accordo: div+css e' un'abbinata fantastica a mio avviso, ma richiede molta piu' attenzione e manualita' nell'usarli di quanto richiedano le tabelle e la formattazione classica e lo verifico giorno dopo giorno, quando bastano una slash o un puntoevirgola dimenticati per distruggere un layout!
| Citazione: |
Cose di questo genere vanno quindi valutate a tutto tondo:
- adattabilità a differenti riusoluzioni (se necessario)
- adattabilità a diversi visitatoti (accessibilità)
- produttività del team creativo e di sviluppo
- appeal del risultato finale
- manutenibilità / aggiornabilità
|
giusto; vediamo in dettaglio:
- adattabilita' a differenti risoluzioni: sia tabelle che div permettono il layout fluido, percio' qua nessuna differenza
- adattabilita' a diversi visitatori: vedi il punto in cui parlo di browser vocali: i div sono piu' accessibili delle tabelle che vanno oltre 1 cella per riga (non lo dico io, ma gli esperti *quelli veri*, vedi diodati.org)
- produttivita' del team creativo e di sviluppo: ??? scusa, non capisco 
- appeal del risultato finale: nessuna differenza, non dipende dalla scelta tra div e table
- manutenibilita'/aggiornabilita': e qua direi che i div la fanno da padrone: come dicevo sopra, un layout a tre colonne creato con i div lo puoi verticalizzare completamente, un layout fatto con le tabelle no a meno di metter mano alla struttura
| Citazione: |
Mi sembrano discorsi un pò campati per aria (non me ne abbia chi li ha espressi) quelli sull'utilizzo su più device. |
dici? io non ho un palmare, ne' navigo con il cellulare, ma amici lo fanno, cercano un albergo al volo mentre sono in giro oppure un'info su un qualche servizio... siccome div+css permettono di gestire con poco sforzo *anche* questo, perche' non offrire al navigatore il servizio?
| Citazione: |
Non di sola grafica vive un prodotto informativo o un servizio. |
certo che no! non mi risulta di aver scritto nulla di simile
non intenzionalmente, almeno 
| Citazione: |
Al di là del layout un prodotto web realizzato per dare il massimo confort sul web mal si adattera al palmare. |
non sono d'accordo: ho seguito diversi corsi e seminari dove si facevano anche prove di questo tipo e in molti casi (occhio: probabilmente non *in tutti*, ma in molti si) e' possibile avere questo e quello, ad esempio tramite i css dedicati
| Citazione: | Chiudo con una domanda: quanti di voi hanno provato ad usare gli script che aggiungono a IE i behavior per avere l'evento hover gestibile nei css su tutti i tag ? (FF l'ha di default)
Si possono aggiungere giochi interessanti "zero code" ;-P |
vero, ma personalmente (per la filosofia che seguo nei lavori, intendo) cerco di evitare features attualmente non ben supportate, riservandomi (e l'evento hover e' sicuramente uno di quelli interessanti!) di usarle quando saranno supportate meglio da tutti i browsers; questa cmq e' una filosofia personale, non discuto assolutamente su scelte diverse |
|
| Top |
|
|
{Federico Maggi}
Ospite
|
| Inviato: 12 Nov 2005 03:07 Oggetto: Non solo div |
|
|
Purtroppo non si tratta solo di utilizzare come contenitori al posto delle tabelle (che contenitori non sono affatto!). Il problema e` molto piu` grave e va ben oltre l'abuso che i webdesigner hanno fatto finora (e che continuano a fare) delle tabelle.
Non solo le tabelle sono state (e continuano per la maggior parte dei siti ad essere) usate come strumento di posizionamento, ma sono davvero pochissime (ancora) le pagine realizzate rispettando l'effettiva semantica dei marcatori HTML stabilita dalle specifiche. Quante pagine effettivamente utilizzano le liste dove effettivamente sono necessarie? E in questo, quanto gli editor WYSIWYG aiutano? Ma aiutano veramente? Quanto i contenuti sono semanticamente strutturati (con i costrutti *corretti* che HTML offre) e totalmente separati dalla presentazione (CSS)?
La troppa liberta` che i browser (e forse l'idea stessa di HTML) hanno lasciato ai progettisti ha provocato quello che il Web e` adesso. Infondo i costrutti resi disponibili da HTML sono piu` che sufficienti per strutturare con la giusta semantica la maggior parte dell'informazione inseribile in una pagina Web. Perche` non vengono utilizzati a dovere? Perche` non sono supportati? O perche` chiunque con pochi scrupoli puo` diventare "webdesigner" grazie agli amici WYSIWYG?
Perche` il markup semantico dev'essere una particolarita`? Il markup semantico dovrebbe essere la normalita`! E` il *minimo* indispensabile perche` una pagina sia degna di essere pubblicata!
Che utilita` hanno tutti gli standard i draft e le raccomandazioni del W3C riguardo all'usabilita` se poi e` a stento possibile capire se una serie di siano in realta` una lista di elementi o chissa` cos'altro?
Purtroppo non e` possibile esaurire questa discussione ed il mio intento era solo quello di fornire degli spunti di riflessione ed aprire un dialogo al quale partecipo piu` che volentieri.
--
Federico |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 12 Nov 2005 13:19 Oggetto: Re: Non solo div |
|
|
| {Federico Maggi} ha scritto: | | La troppa liberta` che i browser (e forse l'idea stessa di HTML) hanno lasciato ai progettisti ha provocato quello che il Web e` adesso. Infondo i costrutti resi disponibili da HTML sono piu` che sufficienti per strutturare con la giusta semantica la maggior parte dell'informazione inseribile in una pagina Web. Perche` non vengono utilizzati a dovere? Perche` non sono supportati? O perche` chiunque con pochi scrupoli puo` diventare "webdesigner" grazie agli amici WYSIWYG? |
ciao federico, ben arrivato
in linea di massima sono d'accordo con il tuo punto di vista: anch'io mi batto per il corretto uso dei tag etc, pero' a differenza di te non demonizzo i programmi wysiwyg, perche' hanno permesso ad una marea di persone assolutamente digiune di html di riversare in rete una quantita' di materiale ora a disposizione di tutti
per me "colpevoli" sono ad esempio i costruttori di browsers, stati davvero poco lungimiranti (giusto per essere gentili): se avessero fornito un supporto diverso ai linguaggi per il web, i programmi wysiwyg sarebbero stati sviluppati diversamente, piu' conformi alle regole e di conseguenza anche le persone non professioniste avrebbero lavorato in maniera piu' conforme
altro discorso quello dei professionisti: c'e' stata una specie di ubriacatura di web ed anche parecchie persone molto preparate per la grafica cartacea passati poi a progettare per il web, cercando di riprodurre lo stesso effetto con il ben noto risultato delle millemila tabelle annidate, i layout iperrigidi e tutto il resto
ora pero' secondo me le cose si stanno evolvendo e c'e' sempre piu' attenzione alla corretta struttura ed anche allo studio di un sistema di lavoro diverso da quello in uso per la grafica su carta; con il passar del tempo ci sara' una scrematura: non sara' una cosa immediata, questo e' certo, ma sono ottimista al riguardo e penso che ogni giorno aumenta il numero di pagine scritte correttamente che vengono pubblicate |
|
| Top |
|
|
{filobus}
Ospite
|
| Inviato: 15 Nov 2005 15:44 Oggetto: |
|
|
| riguardo le dimensioni di visualizzazione, bisogna anche considerare che non sempre la navigazione del sito avviene a "pieno schermo"... |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 15 Nov 2005 16:29 Oggetto: |
|
|
| {filobus} ha scritto: | | riguardo le dimensioni di visualizzazione, bisogna anche considerare che non sempre la navigazione del sito avviene a "pieno schermo"... |
vero
secondo me bisogna di volta in volta considerare i pro ed i contro dei vari layout: un layout completamente fluido - ad esempio - e' piu' adatto ad un sito con molti testi che ad un sito vetrina |
|
| Top |
|
|
kkk2003
Dio minore
Registrato: 11/08/05 07:15
Messaggi: 863
Residenza: Mosca - Russia
|
| Inviato: 25 Gen 2006 13:09 Oggetto: |
|
|
| Quando ho iniziato a impostare il mio sito con i css (grazie Reb!), l'ho considerato principalmente una opportunita' di imparare a "lavorare" correttamente. Poi... ho avuto voglia di cambiare i colori a tutto il sito e... VIVA i CSS!!! |
|
| Top |
|
|
Marcolino
Semidio
Registrato: 27/04/05 15:26
Messaggi: 257
Residenza: Udine e dintorni
|
| Inviato: 28 Gen 2006 00:30 Oggetto: |
|
|
C'è una grossa controindicazione sui layout fluidi, ovvero la risoluzione e la dimensione del monitor su cui si sta guardando la pagina.
Con un layout fluido i contenuti si spalmano sulla finestra, se la risoluzione è troppo alta, si rischia che questi spariscano, sopratutto il testo, che diventa illegibile.
Ci sono soluzioni, ma nessuna definitiva, una è il cosidetto layout definito in em invece che in percentuali.
In pratica si legano i font in grandezza espressa in em, con la larghezza degli lementi che compongono il layout espressi pure loro in em.
Un em è la dimensione della lettera m, che è sempre la stessa rapportata alla risoluzione video.
Il rischio ovviamente è che su monitor molto grandi a sinistra della pagina rimanga sempre troppo spazio o su siti centrati, sia a destra che a sinistra lo spazio diventa davvero troppo, riducendo il sito ad una banda colorata verticale all'interno di tanto spazio, magari bianco.
Una soluzione ibrida c'è, l'ha proposta Luca Mascaro tepo fa.
| Codice: |
// gelatina transformers
// versione 1.0
// idea per il forum di diodati.org
// implementazione e tecnica di Luca Mascaro
// rilasciata sotto licenza http://creativecommons.org/licenses/by-nd-nc/1.0/
function gelatina() {
var index;
if (self.innerHeight) { index = self.innerWidth; }
else if (document.documentElement && document.documentElement.clientHeight) { index = document.documentElement.clientWidth; }
else if (document.body) { index = document.body.clientWidth; }
index = index/60;
value = "0 "+index+"% 0 "+index+"%";
document.getElementsByTagName("Body").item(0).style.padding = value;
}
onload = function(){ gelatina(); }
onresize = function(){ gelatina(); }
|
Si richiama il javascript dall'interno di una dischiarazione <script></script> e poi fa da solo.
In pratica rende le parti laterali nei siti centrali, sempre con una dimensione percentuale accettabile, l'importante è che la parte centrale abbia una dimensione non espressa in percentuali.
Ah, chi pensa che ciò si ovvia usando le percentuali, dico subito che non è così, perché ad esempio 10% ad una risoluzione può risultare gradevole, mentre ad altre ... con "gelatina", la percentuale è sempre differente e dipende dal dispositivo, quindi l'effetto è comunque gradevole.
m. |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 28 Gen 2006 00:40 Oggetto: |
|
|
non la conoscevo
i layout fluidi secondo me hanno anche un'altra controindicazione: la quantita' di contenuto: funzionano bene con pagine ricche, ma con siti con pochi contenuti il risultato finale non sempre e' gradevole  |
|
| Top |
|
|
Marcolino
Semidio
Registrato: 27/04/05 15:26
Messaggi: 257
Residenza: Udine e dintorni
|
| Inviato: 28 Gen 2006 00:55 Oggetto: |
|
|
Be, Nielesen, ma io non lo amo affatto, diceva che le pagine dovevano essere piene di conenuti comunque perché se no era spazio sprecato.
Io non amo le pagine zeppe di contenuti, capisco un portale e comunque avrei qualche ideuzza anche al riguardo, ma il sito del rivenditore di lavatrici realizzato con il classico layout a C [header, menù a sinistra, footer che completano la C e contenuto al centro] per non parlare di quello ad anello, ovvero come C ma anche una striscia a destra di link e/o altro, per quanto siano un classico hanno fatto il suo tempo.
Personalmente trovo che un logo che riempia una porzione di pagina sia più che sufficiente, amo incondizionatamente gli spazi vuoti, secondo me riempiono e armonizzano; un sito Web non è un tabloid. |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 28 Gen 2006 01:00 Oggetto: |
|
|
| Marcolino ha scritto: | | amo incondizionatamente gli spazi vuoti |
anch'io da matti e mi ritrovo regolarmente a litigare con clienti che *non* hanno contenuti, ma vogliono per forza riempire gli spazi 
per pagine ricche intendevo con una buona quantita' di testo: se non c'e', gia' 1024x768 la pagina diventa triste |
|
| Top |
|
|
juzo kun
Dio maturo
Registrato: 19/04/04 09:32
Messaggi: 1853
Residenza: tra la tastiera e la sedia
|
| Inviato: 28 Gen 2006 01:03 Oggetto: |
|
|
L'horror vacui è una cosa che riscontro spesso anche io.
Il vuoto è essenziale alla composizione della pagina, una delle caratteristiche della grafica a stampa che vale anche sul web...
Cià
JK |
|
| Top |
|
|
rebelia
Dio maturo
Registrato: 17/07/03 09:22
Messaggi: 7987
|
| Inviato: 28 Gen 2006 01:09 Oggetto: |
|
|
| juzo kun ha scritto: | | L'horror vacui |
 hai delle definizioni a volte che sono spettacolari |
|
| Top |
|
|
Marcolino
Semidio
Registrato: 27/04/05 15:26
Messaggi: 257
Residenza: Udine e dintorni
|
| Inviato: 28 Gen 2006 01:09 Oggetto: |
|
|
Bè attenzione a paragonare la stampa su carta al Web, è un errore comune il Web segue regole che la carta non ha e viceversa.
Per esempio tutta la discussione in atto qui, segue una regola che sulla carta non è presente, ovvero la non dimensione delle pagine Web.
questesi allungano e si restringono a seconda di come le vedi, la carta invece ha sempre le stesse dimensioni.
Il colore sul Web è più brillante che sulla carta.
Insomma non si possono applicare le stesse regole. |
|
| Top |
|
|
juzo kun
Dio maturo
Registrato: 19/04/04 09:32
Messaggi: 1853
Residenza: tra la tastiera e la sedia
|
| Inviato: 28 Gen 2006 01:13 Oggetto: |
 |
|
| Marcolino ha scritto: | | Bè attenzione a paragonare la stampa su carta al Web |
Non stavo paragonando
(infatti un quarto dei miei capelli bianchi è dato dai clienti che invece... paragonano)
Volevo solo dire che è una delle (poche) cose che hanno in comune.
Cià
JK |
|
| Top |
|
|
|
|
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi
|
|
FAQ
Cerca
Lista utenti
Gruppi
Registrati
Profilo
Messaggi privati
Log in
