Newsgroup: it.comp.lang.javascript
Titolo: [OT] Menu a "tab" con css

Se ne č parlato e m'č venuto lo sfizio di provare a farne uno. Non badate
alla grafica, io e le arti figurative siamo su pianeti distanti anni luce
:)
Se qualcuno ha voglia, perň, mi piacerebbe conoscere i problemi che
sicuramente ci saranno nei browser che non posso testare, come IE/Mac o
Safari (e tanti altri). Inoltre, non capisco bene perché non funge su IE5
(tra il menu e il contenuto vi č un margine esagerato).
Ecco comunque i link necessari, se qualcuno vuole dare un occhio:
pagina: 
http://tinyurl.com/f54ze
css: 
http://tinyurl.com/f54ze/test.css
js: 
http://tinyurl.com/f54ze/test.js
-- 
Nando [?]
Apostolo della Prova

 (tra il menu e il contenuto vi è un margine esagerato).
Su IE5/Mac, come vedi, le cose non cambiano.
-- 
mailto: y = i
----------------------------------------
Vivo nel terrore di non essere frainteso 
(Oscar Wilde)

 Su IE5/Mac, come vedi, le cose non cambiano.
Già. Non ho ancora capito perché :-(


 Su IE5/Mac, come vedi, le cose non cambiano.
Boh... pare che sia riuscito ad aggiustare, anche se non ho capito a fondo
i motivi. Quando hai qualche minuto da perdere, ti andrebbe di dare un
occhio con ie/mac e dirmi se anche lě funziona? Senza impegno, se e quando
ti va :)


 occhio con ie/mac e dirmi se anche lì funziona?
Un paio di istantanee al volo:
uggc://
jjj.pngnefv.vg/anaqb/VR_Trarenyr.wct
uggc://
jjj.pngnefv.vg/anaqb/VR_Fgehzragv.wct


 Un paio di istantanee al volo:
LOL vabbè, evidentemente i problemi che ha IE/win sono diversi da quelli di
IE/mac... grazie ancora per la pazienza e la cortesia :)


 alla grafica, io e le arti figurative siamo su pianeti distanti anni luce
[cut]
Ok, vediamo di evolverci...
Ho un paio di pagine piuttosto ingarbugliate che mi piacerebbe provare con 
il layout solo in CSS.
Domanda: esiste qualche applicativo in grado di prendere una pagina 
esistente e trasformarla automaticamente in una impaginata a CSS?

 Ecco comunque i link necessari, se qualcuno vuole dare un occhio:
Non ho avuto tempo/modo di fare alcun test, mi dispiace, ma ho cmq visto
rapidissimamente il codice js e di markup (non quello css), e mi
domandavo: visto che, comunque, usi javascript, perché utilizzare codice
di markup ridondante?
Capirei se i "tab" fossero unicamente realizzati tramite css e xhtml,
allora avrebbe senso; ma se javascript è indispensabile per il suo
funzionamento, puoi anche utilizzare quest'ultimo per evitare di
scrivere tag "formalmente" inutili.
Mi riferisco al fatto che hai, per ogni tab, un tag li, span e a.
Un conto è un tag in più per evitare codice complicato, un conto è "n"
tag in più messi in quel modo.
Non so, a mio avviso potresti bilanciare un po' di più la cosa. Poi non
so, ripeto.. Non ho visto tutto il codice né fatto gli adeguati test,
quindi prendi questo suggerimento per quel che è.
-- 
"When you have eliminated the impossible, whatever remains, 
however improbable, must be the truth." 

 di markup ridondante?
No, javascript non è indispensabile: l'ho usato in quella pagina di test
"per sfizio" ma non per "realizzare" il layout; in quest'ottica il markup
non è poi troppo ridondante: presenta solo un elemento superfluo (lo span).
Il problema è che non funzia con IE/Mac e non so perché :)


 "per sfizio" ma non per "realizzare" il layout; 
Indispensabile per il funzionamento, non per il layout.
-- 
.ZER0//sign
"When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." (S.H.)

 Indispensabile per il funzionamento, non per il layout.
Ma no :)


 Ma no :)
Mhm? Non capisco: se io disabilito javascript non funziona più una cippa,
questo itendevo.
E senza js perde la sua funzione primaria, a prescindere dal fatto che
abbia un layout o meno di un certo tipo, è del tutto inutile.
E già che sussiste questa condizione, e ci sono molti tag ridondanti -
diverso sarebbe nel caso di uno solo - , potresti utilizzare js per rendere
il codice di markup più snello e pulito.
Inoltre, dato che fai uso di anchor, opterei per verificare in fase di
onload se nell'url è presente: in questo modo è possibile impostare
direttamente una tab se uno ci accede "direttamente" (ovvero se scrivo
nella locatio bar "
http://www.nare.it/prove/tabbed/#strumenti
").
Sempre legato al discorso anchor, *non* avrei optato per xhtml 1.1: usando
il transitional al suo posto, avevi il vantaggio di poter usare
effettivamente gli anchor, impostando l'attributo "name" su un tag "a".
Questo avrebbe reso il "widget tab" un minimo utile anche su quei browser
che non vengono supportati (vedasi Netscape 4.x, browser testuali, etc).
P.S.
Sinceramente non capisco come mai il transitional è bistrattato da alcuni;
attualmente è la miglior DTD in circolazione, soprattutto in virtù delle
capacità reali del browser, dell'interpretazione che hanno del codice
XHTML, e della retrocompatibilità. E sempre di linguaggio XML wellformed si
tratta.
Tanto poi con XHTMl 2.0 cambierà nuovamente tutto. :)


 Tanto poi con XHTMl 2.0 cambierà nuovamente tutto. :)
Aiuto :-S


 Aiuto :-S
Motivo in più per restare sul transitional finché la fase "di transizione" non
sarà stata effettuata. :)
-- 
"Your sin is beyond the grace of God" ~ Ky Kiske

 strict o l.1.
"Sfizio", l'ho detto... Mi diverte recitare la parte del "rigoroso" :)


 "Sfizio", l'ho detto... Mi diverte recitare la parte del "rigoroso" :)
Se questo esser rigoroso portasse vantaggi presenti o futuri, lo capirei..
sarà che non ne vedo il senso: Siamo ancora in una fase di transizione, si può
dire che XHTML 1.1 sia "nato morto".
In pratica ti escludi tutta una serie di possibilità, per essere "rigoroso",
senza alcun vantaggio pratico: sarebbe come se tu decidessi di scrivere
attualmente codice javascript compatibile da jscript 3 in avanti, o CSS e
layout compatibili con Netscape 4.
Ti limiti da solo. Capirei se tu avessi un cliente che vuole assolutamente il
bollino "XHTML 1.1" sul proprio sito web perché è carino, colorato, e fa figo.


 :)
Eh ma lo voglio io il bollino, ché fa figo :-P
Cmq... ho capito cosa intendi, il tuo discorso fila. Se mai capiterà che io
faccia qualcosa sul serio, credo che mi affiderò al transitional.


 Eh ma lo voglio io il bollino, ché fa figo :-P
Ah dì, allora come non detto. :P


 	q:target{
Ehm... beh, sě, questo proprio mi manca... insieme a tanti altri :-S


 Ehm... beh, sì, questo proprio mi manca... insieme a tanti altri :-S
Sono tutte cose scritte e ben documentate, eh. :)


 Bada bene, per rialzata io intendo proprio "rialzata" in senso di "altezza".
Ah no, allora no :)


 Ah no, allora no :)
E lo so :)


 E lo so :)
E allora vafancù :)


 E allora vafancù :)
Sono zoppo, ma ancora ci vedo bene, e avevo visto che non era rialzata. Per
questo lo sapevo che "allora no" :P


 che "prepararsi al peggio" è un modo per "non rischiare mai"?
Mi riferivo alla paura dell'insuccesso che porta a non provarci nemmeno.


 Mi riferivo alla paura dell'insuccesso che porta a non provarci nemmeno.
Ah okay. Per me sono due cose diverse. "Pensare al peggio" è associato più a
un qualcosa che deve accadere, e quindi ad un'azione già intrapresa ("Oddio,
l'esame l'ho fatto da schifo, mi bocceranno, mi bocceranno, lo so già!"); per
quello non capivo bene il riferimento.


 ha scritto:

Sì, infatti generalmente è così... quando il pensare al peggio diviene
"patologico", però, si inizia a farlo a priori: si crede che tutto andrà
male prima ancora di intraprendere alcuna azione ("Oddio! Quest'esame è
difficilissimo... non ce la farò mai!" - e non inizi neanche a studiare).
Parlo da esperto del settore, ovviamente :)
