Newsgroup: it.comp.lang.javascript
Titolo: Form submit con display: none;

Ho un layer impostato con display: none; attraverso un foglio di stile
esterno.
Al caricamento della pagina eseguo:
document.getElementById('LayerID').style.display='block' e il layer appare
correttamente.
Il problema è che nel layer c'è un form con vari campi e non riesco (in IE)
ad inviare il form da tastiera, con il tasto di invio, mentre è ancora
possibile inviarlo cliccando sul pulsante di submit.
Se tolgo dal foglio di stile display: none; tutto funziona correttamente ed
è possibile di nuovo inviare il form anche con il tasto invio (IE)
Qualche suggerimento per aggirare questo bug?
Grazie in anticipo
-- 
:: Massimiliano Mattei
:: Project Leader
:: E.xtranet V.irtual A.pplication
:: 
www.evagroup.net
 :: 
www.commy.biz

 Qualche suggerimento per aggirare questo bug?
Con quale versione di IE? Con IE6 non ho questo tipo di comportamento,
invia correttamente la form.
Alla peggio puoi catturare manualmente il tasto invio ed eseguire il
submit. Qualcosa tipo:
<input type="text" name="txt"
onkeypress="if(event.keyCode==13){this.form.submit();return false}" />
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." (S.H.)

Alla peggio puoi catturare manualmente il tasto..
Ci avevo pensato però mi sembra un pò troppo macchinoso, anche perchè i
campi in alcuni form sono parecchi e i form in generale sono veraemente
tanti.


 tanti.
Ma tu vuoi che in qualsiasi testbox venga premuto l'invio questo mandi
direttamente i dati al server? Pensavo solo nell'ultimo.
Nel tuo caso puoi trappare l'onkeypress dell'intera form; quindi questo
diventa indipendente dal numero di campi che possiedi, ed il codice lo
scrivi una volta sola, non per ogni singolo campo. Per sicurezza verifica
che l'oggetto che ha scatenato l'evento, sia di tipo "input" con attributo
"type" settato a "text".


 "type" settato a "text".
Questa può essere un'idea... vediamo... intanto se poi hai modo di
verificare visto che mi dici che a te funziona lo stesso, mi fai un favore.


Modificata così ed abbinata al form funziona... intanto applico questa per
mantenere la comodità offerta da IE
onkeypress="if(event.keyCode==13){this.submit()};"
Sono comunque curioso di scoprire come mai a te funziona anche nel modo in
cui a me assolutamente non va.. che tra l'altro risulta essere talmente
strano infatti da poter pensare ad un bug di IE


 stesso motivo) il futuro... chissà...
Nell'IT invece io ho imparato a dover sempre essere "un passo avanti", e
non seguire solo il momento. Evidentemente, esperienze diverse. :)


 cui a me assolutamente non va.. 
Secondo me non sei te. Mi spiego: Come ti ho detto, ho cercato di replicare
l'errore con le indicazioni da te fornite. Ovvero:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
">
<html>
<head>
	<title>noname</title>
	<style type="text/css">
		#mylayer{display:none}
	</style>
	<script type="text/javascript">
		onload=function(){
			document.getElementById("mylayer").style.display="block";
		}
	</script>
</head>
<body>
	<div id="mylayer">
		<form>
			<input type="text" name="txt" />
			<input type="submit" />
		</form>
	</div>
</body>
</html>
E non mi da' il comportamento da te indicato. Quindi credo che si tratti di
condizioni complesse, ovvero sono ci sono piu' variabili in gioco..
probabilmente ci sono elementi nella tua pagina che assieme danno questo
tipo di comportamento.. Non e' solo un discorso di display o meno.


>> Quindi credo che si tratti di condizioni complesse...  ....Non e' solo un
discorso di display o meno.
Sicuramente è così... strano però perchè poi se in realtà elimino dal foglio
di stile display: none; allora tutto funziona come deve... mistero.
Comunque grazie per il tempo che mi hai dedicato.


padrone" e' un po' contrario a questa filosofia, non trovi?
In realtà io non la vedo come un "supportare" qualcosa che non è standard,
ma semmai come "non inibire" una comodità che il browsere (oltretutto
attualmente più utilizzato) può offrire, che in questo caso è l'invio di un
form da tastiera, in altri potrebbe essere il completamento automatico dei
form, ecc.
Visto che queste funzionalità ci sono e non hanno bisogno di essere
supportate ne di codice proprietario, in realtà si tratta solo di aggirare
un bug che le invalida.
Un pò come aggiustare il tiro per l'interpetazione errata del box model in
Explorer 5+
Questo è diverso, secondo me, dal "supportare una cosa che non è standard" e
mi sembra perfettamente integrato con la filosofia cross-browser che cerco
di mantenere.
Una considerazione chè mi è sorta spontanea oggi è che sui newsgroup e
iforum in genere di programmazione ci osno più filosofi che programmatori!
:) Non è strano?
Si entra magari per chiedere un parere su uno script e si finisce per
superare Platone ;)


Un'ultima curiosità...  ho visto che oggi hai effettuato il login da GPRS
come mi hai detto... io non ho modo di farlo per ora... ma visto che il sito
è in XHTML e anche i CSS esterni sono standard, sono curioso di sapere come
viene visualizzato, visto che mi dicevi che era disastroso :)


stato preferibile controllare da che oggetto veniva scatenato l'evento.
Ho fatto un pò di ricerche ma non sono riuscito a trovare niente su come
rintracciare quale elemento abbia scatenato un evento abbinato ad un altro
elemento (il form in questo caso).
L'unica cosa che mi è venuta in mente è di aggiungere all'evento onkeypress
abbinato al form, una funzione che verifichi tutti i campi della pagina (o
al limite solo textarea o select) per stabilire che quello con il "focus"
non sia uno di questi 2 tipi.
Però mi sembra anche questa un pò trobbo laboriosa.
In realtà l'idea di estendere questa funzionalità (del submit da tastiera)
anche ad altri browser, non mi dispiace perchè lavorando su extranet o
intranet dove ci sono inserimenti e ricerche continue è una comodità non da
poco. Una delle cose che mi veniva sempre rimproverata dagli utenti
dell'intranet Zucchetti Formazione ad esempio.
... Se ci fosse un modo di rintracciare quale elemento ha scatenato lìevento
per poi fare verifiche sarebbe meglio, non conosco tanto il DOM da saperlo,
ma così a occhio non mi viene in mente...


 di stile display: none; allora tutto funziona come deve... mistero.
Puo' darsi che faccia da "miccia". Hai provato lo stralcio di codice che ti
ho scritto, per verificare se ti funziona?
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"Questa e' una lezione difficile, ma importante: Cio' che e' stato, e cio'
che sara', non cambia cio' che e'.
Sta a te decidere poi come prendere questa cosa,se logorarsi per un passato
che non puoi cambiare, invece di prendere tutto il bene che il presente ti
offre." ()

:) Non è strano?
Affatto, e' normalissimo :) Tra informatica e filosofia, c'e' una linea
piu' sottile di quanto si possa immaginare.. ad esempio, un mio collega
tedesco nell'azienda in cui lavoro io, e' stato docente di filosofia in
germania per anni, prima di diventare sviluppatore. :)
Ti lascio immaginare come siano le discussioni che si possono avere con
lui. ;)


 viene visualizzato, visto che mi dicevi che era disastroso :)
Non e' disastroso il sito, ne' la sua visualizzazione, del resto uso il
cellulare come modem, quindi ci accedo tramite PC :) Intendevo che accedere
al sito via GPRS era abbastanza disastroso, perche' la connessione e' quel
che e'. Soprattutto se nel contempo stai facendo altre cose :)
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"Questa e' una lezione difficile, ma importante: Cio' che e' stato, e cio'


 Però mi sembra anche questa un pò trobbo laboriosa.
See.. infatti. Anche perche' per verificare che abbia il focus o meno devi
a sua volta fare un altro rigirio. :) A quel punto sarebbe stato
preferibile usare l'onkeypress su tutti i campi.


onkeypress="if(event.keyCode==13){if (event.srcElement.type ==
'text'){this.submit()}};"
Così va... devo aggiungere anche il campo password la dove è presente.
Purtroppo siamo al solito problema. Infatti IE non ne vuole sapere di
event.target, invece Opera 7+ (con il 6 non l'ho provato perchè dovrei
cambiare i dispaly: none; in visibility: hidden; e sono ancora indeciso
perchè non mi piace l'effetto di visibility che mostra comunque prima i
bordi delle tabelle), Mozilla 1.01+, Explorer 5.01+ e Firebird, accettano
senza problemi event.srcElement (Mozilla 0.9 no..)
Credo che per il quieto vivere, lo terrò così... anche innerHTML mi sembra
sia proprietario di IE e invece è letto correttamente da tutti i browser che
ho nominato, compreso Mozilla 0.9 e Opera 6, chissà.. magari li inseriranno
nella prossima definizione standard :)


 ho nominato, compreso Mozilla 0.9 e Opera 6, chissà.. 
Si, perche' gli sviluppatori lo richiesero a gran voce.. Del resto, e'
molto comodo. Ma bisogna stare attenti a come lo si usa. :)
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"Questa e' una lezione difficile, ma importante: Cio' che e' stato, e cio'


La funzione che mi hai scritto va alla grande. Ovviamente ora è preferibile
tenere il tutto in una funzione separata visto che come si dice... l'affare
si sta ingrossando ;)
Grazie ancora per la disponibilità.
PS. Il sito 
www.commy.biz
 che è un demo del prodotto e-commerce che vendo, è
un sistema crossbrowser e multiskin. Ci sono già dentro 4-5 vesti grafiche
abbastanza diverse da loro. Se ti va di fare un giro per curiosare, fai pure
tanto l'accesso di prova che ti ho dato resta li.
Se poi per caso scopri qualche anomalia con browser che io non ho potutto
testare (safari?) fammi sapere.
