Edit

I siti del network HTML.it

• HTML.it
• oneOpenSource
• HTML/XHTML
• CSS
• JavaScript
• PHP
• Grafica
• Web Design
• Marketing e Motori
• Programmazione

Commenti

1

perche’ dici solo esercizio? Questa soluzione non puo’ essere applicata in produzione?

Credo di si, no? A mio parere qualsiasi cosa che puo’ essere ottenuto solo con i CSS e’ 100 volte meglio dell’equivalente javascript: non bisogna caricare librerie, funziona anche quando javascript e’ disattivato, e’ indipendente da problemi generati da altri script ed infine e’ piu semplice da implementare.

Quindi, perche’ no?

# - postato da Andrea - 19 Settembre 2008 - 11:07

2

(io l’ho provato solo su Firefox e Safari)

Hai fatto bene :-) perchè non va nè su explorer 6 e 7.

Per quanto riguarda la questione se è giusto usare i css per questo, se si ha una resa buona perchè no? Il punto principale è però ottenere lo stesso risultato su tutti i browser, altrimenti tanto vale.

# - postato da giovanni battista lenoci - 19 Settembre 2008 - 11:16

3

Concordo sia con Andrea che con Giovanni. L’uso dei CSS è sicuramente meglio del Javascript però, oltre ad esserci le stesse funzionalità, devono anche esserci gli stessi gradi di compatibilità con i browser.

Tuttavia, penso che Javascript spesso sia la via più semplice e indolore per raggiungere certi risultati!

# - postato da Paolo Ferretti - 19 Settembre 2008 - 12:56

4

Purtroppo è (quasi) inutile visto che non funziona con Internet Explorer.

# - postato da Mattia - 19 Settembre 2008 - 12:57

5

è proprio il problema di compatibilità, il limite!

Personalmente sarei felicissimo di usare solo CSS ma fino a quando non si potranno avere gli stessi effetti su tutti i browser… purtroppo rimangono esercizi di stile.

# - postato da Luca - 19 Settembre 2008 - 13:05

6

Si si… ho tralasciato quella premessa: prediligo i css a javascript solo quando l’effetto e’ supportato da tutti i browser.

Anche se poi e’ una cosa “flessibile”. Dipende un po’ dal progetto. Nel senso: secondo me non ha senso appesantire una pagina che normalmente pesa 50kb con 100kb di javascript solo per alcuni abbellimenti grafici. Se ho una alternativa fattibile con solo i css ma magari che non funziona sotto ie5 o opera mi va bene lo stesso, a patto che degradi decentemente.

Mi spiego meglio: poniamo il caso dell’effetto riportato nell’articolo. Se funzionasse con ie6 e 7 ma non con ie5 e magari qualche altro browser minore, preferirei cmq usare questa soluzione: pesa meno, e’ piu veloce e nel caso non sia supportata non compromette cmq la funzionalita’ del form.

# - postato da Andrea - 19 Settembre 2008 - 13:30

7

Bhe sono pienamente d’accordo a meta con Andrea.
Innanzitutto con 100k di javascritp oramai si può creare un sistema operativo, jquery che ti da tutti gli strumenti per fare una cosa del genere pesa 15K.
Per quanto riguarda quello che dici riguardo al perdere l’effetto su vecchi browser sono d’accordo finchè come dici tu (anzi mi spingo oltre) sia almeno supportato internet explorer 7, altrimenti faccio a meno di pensarci.
E’ vero che firefox e safari ci danno più soddisfazione per fare certe cose, ma se poi il mio lavoro viene visto da una minoranza delle persone che visualizzano il sito allora vuol dire che quel plus aggiunto solo per firefox e safari non verrà sicuramente ripagato.
Una precisazione, rendiamoci comunque conto che, come dice Cesare, questo è solo un esercizio per il momento.

# - postato da gianiaz - 19 Settembre 2008 - 13:46

8

Eh… ma vedi che la questione e’ piu articolata?
15kb? Vero… ma compresso e gzippato.

Per esempio io non uso la versione GZIP: non so perche’ ma non mi ha mai dato fiducia al 100% per cui uso sempre la versione compressa e basta. A questo aggiungi che di solito chi usa quegli effettini lo fa usando un plugin che ovviamente, per contemplare tutti i casi possibili, risultano sempre molto ridondanti nel codice. Il risultato e’ che per fare quel giochino del background ti mangi piu di 60/70 kb. Secondo me non ha senso… quando magari con 10 righe di css riesci a ottenere lo stesso risultato con una copertura superiore all’90% dei browser (basta che funzioni su ie6 ie7 e firefox per avvicinarsi).

Poi oh… va molto a gusti personali… non esiste una regola assoluta in questi casi :D

# - postato da Andrea - 19 Settembre 2008 - 14:14

9

ultimamente è una tecnica che sto usando spesso, ma non solo per evidenziare il punto in cui si sta scrivendo ma anche per evidenziare dopo il click i campi ancora da riempire.

# - postato da Francesco - 19 Settembre 2008 - 15:23

10

qualsiasi soluzione non compatibile con il browser utilizzato da 3/4 degli utenti DEVE essere scartata
poi non capisco come si possa testare
su Safari ma non su IE
IE deve essere considerato perché lo usano l’80% degli utenti punto

# - postato da Mik - 19 Settembre 2008 - 15:53

11

Mi sembra che nessuno abbia sostenuto il contrario…

# - postato da Andrea - 19 Settembre 2008 - 19:27

12

Andrea si ma leggo troppo spesso dagli opinion maker del web frasi del tipo “l’ho testata su tutti i browser tranne IE” o commenti denigratori nei suoi confronti.

Semplicemente perché questo alla lunga orienta i programmatori a trascurare explorer quindi a creare siti inacessibili alla stragrande maggioranza degli utenti, e ne vedo in giro.
Usano solo Firefox e manco se ne accorgono

# - postato da Mik - 19 Settembre 2008 - 22:14

13

@Mik
Meno siti per Explorer ci sono = maggiore diffusione di browser compatibili con gli standards ci saranno = siti migliori e avanzati = maggiormente accessibili = minore tempi di sviluppo (leggi debugging) = maggiore guadagno per noi sviluppatori
Fatto questo *piccolo* incipit, volevo parlarvi proprio di un’idea di usabilità di cui parlavamo con un amico proprio a proposito del context higlighting. Pensavamo di utilizzarlo per aumentare l’usabilità del form nella validazione del campo “on the fly”. Per cui se scrivo la mia email con “tizio@ caio.semp” o una data che a me serve come 20/9/08 “20/09/08″ il campo sarà evidenziato in rosso. Eviterò tabs, shift+tabs, click del mouse superflui, avrò maggiore comprensione e minore *rompimento* nel visitatore. Da questo punto di vista non lo considerei solo un *esercizio* di stile. Che ne pensate? (ps, se doveste usarlo in questo modo, quotatemi nel codice… :P )

# - postato da Giuseppe Caruso - 20 Settembre 2008 - 00:57

14

Giuseppe agli utenti non interessano ste guerre di religione, standard no standard

ce ne freghiamo dell’accessibilità del 75% degli utenti, e poi ci andiamo a preoccupare di fare siti accessibili per lo 0,x% dei non vendenti prendendo degli accorgimenti che Jaws, lo screen reader utilizzato da quasi tutti i non vedenti, ignora, e ne ha risolto i problemi in modo migliore e a suo modo

questa è la finta accessibilità dei bollini, quella reale è: prendi explorer, jaws, ecc. e vedi come si comportano.

fare siti realmente accessibili a tutti, non solo alle minoranze, usabili, rispettosi degli standard e compatibili con tutti i browser più recenti è possibilissimo, non farli in nome della crociata anti-micosoft è cacciare gli utenti dal sito, quegli utenti che dovrebbero essere la nostra prima preoccupazione.
sono loro che, direttamente o indirettamente, ci danno da vivere, noi lavoriamo per loro.

# - postato da Mik - 20 Settembre 2008 - 13:26

15

Concordo pienamente con mik, anche perché se con i siti ci devi mangiare ….
Per la questione pro e contro JS sono d’acordo che è meglio, molto meglio il CSS e che se jquery è solo di 15K non vuol dire proprio nulla, dato che ciò che conta è la complessità dell’elaborazione e della memoria occupata per farlo; non tutti hanno in ogni situazione HAL9000 per navigare su Internet.
Poi si deve anche pensare alla versione del JS che magari è troppo recente e quindi certi browser comunque non agirebbero come ci si aspetterebbe.
Quindi converrebbe tirare fuori i vecchi e cari onmousexxxx e farsi a manetta qualche piccola soluzione, in fondo non stiamo mica parlando di chissà quale complesso calcolo :-)

M.

# - postato da Marco GRAZIA - 22 Settembre 2008 - 10:02

16

@Giuseppe: parlando di accessibilità, evidenziare una parola o un campo per colore è sbagliato perché molta gente non riconosce quel colore o non vede affatto, è una regola di base dell’accessibilità.
Normalmente si mette un simbolo, un asterisco, in quest’ottica cercare qualcosa di diverso come l’evidenziazione tramite JS/CSS è un passo avanti anche in funzione di una grafica migliore e più accattivante, che non guasta mai.
Poi la questione dei browser compatibili attraverso l’uso in specifico solo di questi ultimi è una battaglia vecchia e già persa da tempo, specie ora che Mozilla ha deciso di mettere alcuni elementi propri di HTML5 all’interno della versione di FF 3.1
Insomma si è ritornati a prima delle lotte per avere un riconoscimento degli standard, a quando cioè Netscape usava codice HTML che Internet Explorer non aveva, il rischio presente è quello del grande ritorno della guerra dei browser.
Ciò che conviene fare non è l’uso di un solo browser, dato che comunque non è la tua scelta a influenzare quella del client, ma parlare contro la tecnica “idiota” passami il termine di “imbellettare” il proprio programma con l’uso di elementi non standardizzati e come nel caso specifico non rilasciati dal W3C ma ancora in Draft solo per stare un passo avanti agli altri.

M.

# - postato da Marco GRAZIA - 22 Settembre 2008 - 10:33

17

@ MIK:

finora non ho mai avuto l’occasione di trovare un solo sito che funzioni perfettamente bene con firefox e male con explorer. Avendo solo linux a casa spesso e volentieri volano imprecazioni per quelli che pensano solo all’80 o al 99.x percento dei possibili visitatori. E non parlo di blog di appassionati di firefox. Servizi come la prenotazione di un posto al cinema non possono essere pensati per solo perchi ha explorer ( il cinema è solo un esempio fra tanti ). Questo è il punto.

Se trovi un sito che vada bene su firefox e non su explorer fammi sapere.

Per quanto riguarda questa tecnica, concordo con i primi due pareri, di Andrea e Giovanni.

# - postato da Paolo - 22 Settembre 2008 - 22:41

18

@Marco GRAZIA
Forse hai frainteso quello che dicevo, io ho risposto solo all’obiezione che le librerie pesano centinaia di kbyte.

Poi che certi effetti possano essere pesanti per browser vecchi, posso essere d’accordo, ma mi sembra un esagerazione parlare di computer super potenti per queste operazioni.
I framework js inoltre aggiungono una compatibilità che con il puro javascript è più laborioso fare (lasciamo perdere l’onmouseover).
Io agli albori di ajax mi ero scritto una funzioncina per fare le chiamate e dovevo gestire diversamente la cosa tra firefox ed explorer, e non ero neppure sicuro che funzionasse con tutti i browser, con jquery non mi pongo il problema perchè c’è una lista di compatibilità.
E scusa tanto se ignoro Netscape 4 o Explorer 5 o Firefox 1.
Ok stare dietro agli utenti, infatti evidenziavo proprio il problema che la suddetta tecnica non funziona con explorer, ma a tutto c’è un limite :-)
@Andrea
non capisco i tuoi dubbi sulla versione gzippata, io la uso tranquillamente e come me migliaia di programmatori nel mondo, quindi mi chiedo quale sia il tuo dubbio.
Io comprimo e metto in un unico file tutti i miei js e i tempi di download diminuiscono drasticamente.

# - postato da gianiaz - 23 Settembre 2008 - 12:04

19

Da un altro blog sono entrato in questo specifico post, ed ho letto i commenti. Uhm… vediamo un pò….

Paolo,
tu dici che “finora non hai mai avuto l’occasione di trovare un solo sito che funzioni perfettamente bene con firefox e male con explorer”, beh allora si può solo rispondere che o non hai guardato bene o sei di parte. Perchè per fare il primo esempio che mi viene in mente, saprai benissimo che il padding e il margin vengono calcolati in modo diverso da IE e Firefox. Quindi se tu testi un sito solo su uno dei due browsers l’altro sicuramente sarà incasinato.

Vedo siti che nel footer scrivono: testato su Firefox! Usate Firefox! Insomma come si faceva prima con IE. Se era sbagliato prima è sbagliato anche adesso, no?

Inoltre non è che Firefox legga meglio, è che Firefox legge in modo diverso e più cose, e questo è decisamente diverso e non necessariamente indicativo di browser migliore, perchè se i nuovi tags non li conosce nessuno o se questi tags sono del tutto inutili… ok Firefox leggerà più cose, ma saranno cose inutili. :-)

—

Giuseppe Caruso,
IE è un browser “strano” perchè riesce a trasformare in pagina internet anche codici “non completi”, infatti sono tantissimi i siti amatoriali creati da persone con pochissima esperienza che realizzano paginette buone su IE e incasinate su Firefox. Questo perchè? Perchè devi essere più bravo per far siti visibili su Firefox. Ed invece spesso leggo persone (come te) che scrivono (o fanno intendere) che è più facile fare siti con Firefox. Insomma, altra posizione di parte e poco obiettiva. :-)
Non è il browser a rendere il sito accessibile, ma i codici usati per creare la paginetta. Se sei un bravo sviluppatore il sito è accessibile, se non lo sei, non è colpa del browser. :-)

Firefox ha tanti plug-in per gli sviluppatori, giusto? Io, però, non ho bisogno di questi plug-in. Questo significa che sono più bravo di chi invece li utilizza? :-)

—

Gianiaz,
ma quando parli di riduzione dei tempi di download ti riferisci al tuo pc, giusto? No perchè ti suggerisco di fare un test usando un pc vecchiotto (che in tanti usano). Ah, io sono uno di quei “pochi” sviluppatori che vive tranquillo lo stesso senza usare jquery. :-)

Alle basi dell’accessibilità c’è che un linguaggio come javascript non deve essere utilizzato per creare funzioni indispensabili in un sito, perchè se uno lo disabilita o utilizza un dispositivo che non fa uso di javascript come fa? Esce dal sito?

—

Questa cosa dello scrivere continuamente che è meglio quel browser o quell’altro browser è inutile. E’ una battaglia inutile perchè metà della popolazione italiana il pc non l’ha neanche mai acceso. Dell’altra metà eliminiano quelli che lo usano per giocare offline o per lavorare offline. Della restante parte di chi usa il pc anche per navigare in internet, eliminiano quelli che semplicemente fanno ricerche o chattano. A queste persone non frega nulla di usare un altro browsers, ed alcune non sanno nemmeno che esiste un altro browser.

Chi usa più browsers? Quelli che fanno i siti, quelli che stanno incollati al pc dalla mattina alla sera, e quelli che c’hanno l’amico esperto che suggerisce di usare un altro browsers o un altro sistema operativo. Poca robbbba insomma.

—

Per quanto riguarda invece l’accessibilità, com’è stato già scritto, alla base c’è il non veicolare le informazioni solo tramite il colore, quindi la tecnica utilizzata e spiegata in questo post non è accessibile oltre che non utilizzabile sul browser più usato dalla stragrande maggioranza delle persone.
Poi non so voi, ma io con i form tradizionali senza colori e altre stupidaggini simili mi sono sempre trovato bene, li ho sempre “capiti”, fortunatamente non sono ancora diventato così rimbabito d’aver bisogno dei colori e credo sia così anche per gli altri, visto che fin’ora non è stato necessario far uso dei colori. :-)

Con javascript si possono fare tante cose, ma le cose inutili mettiamole da parte, eh.

# - postato da Dadan - 23 Settembre 2008 - 13:30

20

Non vorrei, sinceramente, alimentare nessuna diatriba tra fazioni. Ma chi sviluppa, seriamente, semanticamente e su un editor di testi (nel senso che sa cosa sta scrivendo prima di fare un anteprima) e non su un editor WYSIWYG siti Internet, sa che è notevolmente più semplice sviluppare per Browsers aderenti agli standards che per IE6.
Io non sviluppo siti per i soliti Firefox, Safari, etc. Io sviluppo siti Internet per come vanno sviluppati. Corretta interpretazione del Box model, nessun margine flottato raddoppiato, .png rappresentate per come meritano, niente apparizioni/sparizioni di contenuto (Peekaboo! ;) )… Browsers come Firefox e Safari interpretano il mio codice per come so che deve essere interpretato, IE6 no. Non è un opinione di parte, è un dato di fatto riconosciuto dalla comunità di sviluppatori.
Per quanto riguarda l’accessibilità, non ha niente a che vedere con i browsers. Solo che non dover usare div contenitori e div contenuti, etc. mi porterebbe a creare codice più leggibile e semantico. Mi scuso per la mancanza di chiarezza sopra.
Insieme ai colori, poi, è chiaro, che andranno usate delle icone per le persone che soffrano di cecità ai colori, ma ricordo che sono disturbi che non permettono di riconoscere alcune tonalità di colori su altre, ma un rosso, scuro su bianco è ugualmente visibile per contrasto.
L’utilizzo dei plugin per firefox, poi, avrebbe bisogno di un post a parte, che farò, per conoscere la vostra opinione in proposito.

# - postato da Giuseppe Caruso - 23 Settembre 2008 - 14:18

21

Dadan, stiamo parlando di evidenziare una label, non di confermare l’ordine di un carrello elettronico con js.

Inoltre ognuno di noi ha a che fare con il cliente che chiede i giochini web 2.0, dobbiamo attenerci allo standard, programmare per tutti i browser possibili, ma ad un certo punto bisogna raggiungere un compromesso, se vuoi un sito web con acrocchi ajax sai subito che ti stai rivolgendo ad un pubblico che vuole e probabilmente ha gli strumenti per vederli.

Altrimenti sviluppiamo per lynx e buonanotte.

# - postato da gianiaz - 23 Settembre 2008 - 14:28

22

@paolo

non ho dati statistici al riguardo, riporto la mia esperienza di navigazione e programmazione,
in genere trovo che explorer sia più flessibile e tollerante di firefox,
per la sua migliore gestione dei piccoli errori, e in genere si vede meglio,
però con explorer è più frequente la casistica dell’inacessibilità al contenuto.
in sintesi ed estremizzando il concetto: con explorer o si vede e si vede benissimo,
oppure si vede malissimo o niente, senza mezze misure

eccoti un esempio: tutti gli articoli de “il giornale” non riesco a leggerli su explorer 7
perché coperti dal modulo di registrazione
http://www.ilgiornale.it/a.pic.....?ID=292892

altro errore che trovo in giro è che per un errore javascript mi appare un alert
e subito dopo la pagina del sito diventa bianca.

volano imprecazioni per quelli che pensano solo all’80 o al 99.x percento dei possibili visitatori

se non ti basta un sito ottimizzato addirittura per il 99.x dei visitatori, ok allora
ritorniamo a fare i siti in stile anni ‘90 perché c’è qualcuno che si collega da browser vecchissimi o sperimentali?

in parte sono d’accordo con te, mentre la micosoft, mozilla, … si sono impegnate
ad assicurare la retrocompatibilità, per cui loro browser supportano varie versioni di html, xhtml, css, javascript da quelle vecchie fino alle più recenti
dall’altra parte il w3c e tanti guru dell’HTML, pure su questo blog, bollano come fuori standard o deprecati tanti tag e tante tecniche, per cui devi scegliere fra:

- fare siti compatibili pure con i browser vecchi
- essere un “bravo” programmatore rispettoso degli standard

qualunque sia la tua scelta avrai sempre qualcuno che ti bolla come bravo e altri come pessimo

# - postato da Mik - 23 Settembre 2008 - 21:03

23

@ Dadan:
non parlavo di resa grafica/css (anche se si vede male non mi interessa, quello che conta è ottenere il servizio ed i contenuti) ma di effettive funzionalità javascript che impediscono il funzionamento perchè i programmatori si sono soffermati solo sul browser IE con il testing.
In ogni caso io non sono di parte, ma preferisco notevolmente firefox ed inoltre il mio concetto di web è semplicità ed accessibilità, come cerco di fare sul mio sito, dove non ho il minimo javascript e dove TUTTI i browser usufruiscono dei contenuti indipendentemente dalla resa grafica css che è per mia stessa ammissione e volontà limitata a firefox, opera, lynx, chrome, IE7 senza retro-compatibilità (pigrizia mia :D ).

@ MIK
a parte che in fondo in fondo la pensiamo allo stesso modo, non vedo che grossi problemi ci siano a fare siti che siano compatibili con i vecchi browser e rispettare gli standard.
Per quanto riguarda i browser, l’esempio che hai citato l’avevo incontrato e lo ritengo legato al fatto che ie7 è uscito dopo la realizzazione di quel sito e quindi è possibile che la resa non sia stata verificata a dovere. Ma come ha detto giustamente @ Giuseppe Caruso:

Browsers come Firefox e Safari interpretano il mio codice per come so che deve essere interpretato, IE6 no. Non è un opinione di parte, è un dato di fatto riconosciuto dalla comunità di sviluppatori

Ma il punto è proprio questo: IE per quanto tollerante sia agli errori non segue gli standard nello stesso modo in cui lo fanno gli altri browsers. Per questo, secondo me, favorire lo sviluppo pro-IE piuttosto che lo sviluppo pro-Standards è assolutamente negativo.

# - postato da Paolo - 23 Settembre 2008 - 23:51

24

@paolo

non vedo che grossi problemi ci siano a fare siti che siano compatibili con i vecchi browser e rispettare gli standard.

esempio, per il deprecato tag xmp, sottostimato ma x me molto utile, non c’è alcuna alternativa compatibile con tutti i browser e che faccia lo stesso suo identico lavoro: mostrami l’HTML così com’è
oppure per l’inserimento di flash/file multimediali, che bisogna usare applet, object, e in futuro video
ecc. ecc.

favorire lo sviluppo pro-IE piuttosto che lo sviluppo pro-Standards è assolutamente negativo.

io non voglio favorire lo sviluppo di IE, ma nemmeno sfavorirlo, non è una mia scelta, IE è un tramite, fra il mio sito e gli utenti, spetta a loro la scelta.

poi la solita scusa “si ma IE lo usano in tanti perché è già installato” credo valga solo fino ad un certo punto, perché quando vogliono, si riescono ad arrangiare, installando e imparando tutto a perfezione

anche io uso prevalentemente explorer (e firefox solo quando mi servono le sue extension), perché è più veloce e gradevole, e come utente che sia (non aderente ma) PIU’ aderente agli standard w3c non mi interessa

e invece che alla microsoft, io punterei le critiche verso il w3c, che spesso e volentieri stabilisce regole per me prive di ogni logica, e con il supporto di tanti web developer

a me pare che questo sia dovuto ad atteggiamento quasi da “casta”, che tende a burocratizzare e complicare inutilmente il settore

così come gli avvocati pensano di trarre beneficio dalla numerosità e complessità delle leggi, pure gli sviluppatori credono che uno sviluppo molto più complesso vada a loro beneficio, quando invece il progresso dovrebbe renderci tutti in grado di fare le stesse cose in minor tempo e con migliori risultati x tutti

# - postato da Mik - 24 Settembre 2008 - 01:05

25

Non puoi sostituire il tag “xmp” con il tag “pre”.

# - postato da Mattia - 24 Settembre 2008 - 08:05

26

Ops, il commento di prima doveva finire con un punto di domanda, non con un punto.

# - postato da Mattia - 24 Settembre 2008 - 08:05

27

no pre fa solo una piccola parte di quello che fa xmp, per esempio con pre non visualizzi i tag

per ottenere un xmp, dentro al pre dovresti fare tutta una serie di sostituzioni da ai caratteri speciali, e pur facendo le sostituzioni non sempre si ottiene lo stesso risultato

xmp fa la stessa cosa del cdata negli xml, che non è per niente deprecato e strautilizzato, essendo in quasi tutti i feed rss

xmp può essere utile per:
mostrare il codice html, prevenire attacchi XSS, velocizzare il rendering e la visualizzazione di pagine molto lunghe ed evitando che il browser si impalli (x esempio io lo uso per visualizzare i logfiles e filtrarli)

lo hanno deprecato perché lo ritengono un tag di fomattazione, beh potevano renderlo semantico e mantenerlo, dandogli il significato semantico: quello che segue è un codice html

# - postato da Mik - 24 Settembre 2008 - 09:30

28

@Mik
In sostituzione del tag xmp dovresti usare il tag pre.
Il tag pre sta per PREformatted, un tag che ti permette di mantenere la formattazione che dai al testo come spazi, tabulature, etc.
Se poi devi mostrare del codice e vuoi mantenerne la formattazione, dovresti nidificare un tag code in un tag pre effettuando l’escaping del codice. Per esempio, se volessi visualizzare il testo di questo commento, scriveresti:

<pre>
<code>
&lt;p&gt;
In sostituzione del tag &lt;i&gt;xmp&lt;/i&gt; &lt;em&gt; dovresti&lt;/em&gt;
usare il tag &lt;i&gt;pre&lt;/i&gt;.
Il tag &lt;i&gt;pre&lt;/i&gt; sta per &lt;b&gt;PRE&lt;/b&gt;formatted,
un tag che ti permette di
mantenere la formattazione che dai al testo come spazi, tabulature, etc.
Se poi devi mostrare del codice e vuoi mantenerne la formattazione,
dovresti nidificare un tag &lt;i&gt;code&lt;/i&gt; in un tag &lt;i&gt;pre&lt;/i&gt;
effettuando l’escaping del codice. Per esempio, se volessi visualizzare il testo
di questo commento, scriveresti:
&lt;/p&gt;
</code>
</pre>

e otterresti:


<p>
In sostituzione del tag <i>xmp</i> <em> dovresti</em>
usare il tag <i>pre</i>.
Il tag <i>pre</i> sta per <b>PRE</b>formatted,
un tag che ti permette di
mantenere la formattazione che dai al testo come spazi, tabulature, etc.
Se poi devi mostrare del codice e vuoi mantenerne la formattazione,
dovresti nidificare un tag <i>code</i> in un tag <i>pre</i>
effettuando l'escaping del codice. Per esempio, se volessi visualizzare il testo
di questo commento, scirveresti:
</p>


Ora, come vedi, sia il tag pre che il tag code sono tags semantici.
Hanno un significato e vanno usati con cognizione di causa. Capisco che sembri una perdita di tempo ma è come usare bene i congiuntivi, per ozio non si usano più comunemente ma il linguaggio ne guadagnerebbe in chiarezza e significato se si usassero correntemente.
Per agevolare il lavoro, esistono online (o, per chi ha Mac OS X, dei widgets o lo stesso TextMate) che effettuano l’escaping dei caratteri in un click.
Chiedo scusa per l’off topic.

# - postato da Giuseppe Caruso - 24 Settembre 2008 - 12:48

29

giuseppe so benissimo che per simulare il tag xmp occorre usare il pre e l’escaping, tant’è che se rileggi il mio commento l’ho scritto, e siccome non hai capito pure il resto, è inutile che te lo ribadisca, o aggiunga cose che dopo tu mi ripeti convinto di insegnarmele

# - postato da Mik - 24 Settembre 2008 - 17:18

30

@gianniaz: prova ad aprire questa pagina con un Intel II con 64mega di RAM ed NT4 con IE6 prima e poi capirai di cosa parlo, per la cronaca mi ci vogliono 35 secondi per aprirlo, chi lo usa?
A parte io in ufficio, un sacco di gente che conosco personalmente.
Detto ciò: Giuseppe usare <CODE> per del testo comune non rispetta la semantica, CODE serve per mostrare del codice non per fare l’escaping, sempre parlando di semantica :-)

M.

# - postato da Marco GRAZIA - 27 Settembre 2008 - 10:34

31

@Marco GRAZIA
Ciao Marco,
dove mi hai visto usare il tag code per del testo “comune”? Cosa intendi per testo comune?
@Mik
Ti chiedo scusa, non era mia intenzione insegnare niente a nessuno. Ti stavo esponendo in che modo io uso il tag code. Tra l’altro non lo uso per simulare il tag xmp ma lo uso per visualizzare “porzioni di codice, anche html” come prevede la specifica .
Ma siamo off-topic, creerò un post appositamente per parlarne, con la solita atmosfera di confronto e scambio di opinioni tra amici e colleghi che amiamo mantenere in Edit. :)

# - postato da Giuseppe Caruso - 27 Settembre 2008 - 12:38

Inserisci il tuo commento:

Nome (campo obbligatorio):

Indirizzo email (campo obbligatorio):

Il tuo sito:

Commento (puoi usare i seguenti tag HTML per formattare il testo -
a href, b, i, br/, p, strong, em, ul, ol, li, blockquote, pre):

 

Anteprima del commento

Lasciare vuoto questo campo!!!

Avvisami via e-mail della presenza di nuovi commenti